On Wed, 12 Mar 2003 08:41:19 +0000
Axel Simon
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]