[GUI] Re: Events and finalizers

Nick Name nick.name@inwind.it
Wed, 12 Mar 2003 10:30:39 +0100


On Wed, 12 Mar 2003 08:41:19 +0000
Axel Simon <A.Simon@ukc.ac.uk> wrote:

> Having looked at the Haskell files 

wich are full of errors, I have to do full disclosure even if people is
kind :) I wrote 'em quickly to submit here, but I'll do surely better.

> you sent around some time ago, me
>  thinks that such a unified event/syncronization/stream library is too
>  high level for the CGA. In case a) it can be implemented on top of
>  the callback approach then we/you should be able to define a separate
>  library (ok, I said that before) which can be part of a Common GUI
>  Library (i.e. libraries which work with the CGA).

I said that too. I am going to implement it as a separate library.

>  In case b), that it
>  has to be interweaved with the API itself, then it will make it hard
>  for high level libraries to use the CGA since they have to match the
>  concurrency model of your approach.

I don't like forcing people to do something. Streams don't require
concurrency, they take advantage of it. An eventual library written by
me can separate things that need preemption in a different module. 
> But there are so many other approaches
>  that never really caught on which is why we don't want a high-level
>  solution.

I repeat for the last time, that streams are not an high-level approach.
 
Please, notice that you, to avoid streams, are USING MONADS! Streams and
monads are not really at a different level, IMHO, but they are two
different solutions to the same problem, wich is: how to get
nondeterminism inside a lazy functional language, and I have noticed, as
others, that the ability to mix streams and monads give more expressive
power than using just one of them.

> I know you don't force the user to use your abstractions
>  which contrasts with high-level approaches like Fudgets, Fran, etc,
>  but that should mean that the library can be an addition to the core.

It will not be in the core, this has already been stated. 

== Important note:
It may be that I don't succeed in doing my work; believe me, it's even
probable. It may well be that my work is not well-made, and that you
won't be interested in using it.

In that case, this does not mean that stream are not useful, or are to
be better studied. It just mean *I* am not able to generalize, and in
that case, I hope you will take the library of HTk, wich is already well
studied, or the Ports library from M.C., adapt it to this standard
haskell GUI and make it available as a module in the standard
distribution.==

I repeat for the last time, lazy lists are one of the fundamental data
structures in a lazy language; it's necessary to have them, not because
I say so, but because people USE them today. So remember this when
you'll be done with the core. Streams are *not* an alternative to Fran.
They are just a convenient wrapper over an all monadic program.

Just notice the following functions in the base libraries: getContents,
hGetContents, readFile, getChanContents, and (newStdGen >>= return .
randoms).

These are common patterns wich are useful in everyday life of an haskell
programmer.

I *absolutely* don't want to be polemic, or to impose a personal view. I
am just worried about the future of haskell, wich includes a standard
GUI. This has to be clear, or I'll seem a troll.

Vincenzo





-- 
Scopriti essere umano e in quanto tale persona banale e non speciale
a cui Dio concede gesti assai banali. D'ora in poi quello sei tu.
[Marlene Kuntz]