[replying to the GUI list]
I don't have a strong opinion myself -- I'm just advocating a little
careful study, since Clean has a lot of experience. It might be worth
asking Peter Aachten for his advice/ideas. Invite him to join the
list?
| * It integrates facilities for concurrent and distributed
| programming (asynchronous communication via channels). I
| still think, we can keep the GUI API and concurrency as
| two orthogonal features. If you take these features out
| and use IORefs instead of MVars, you are already quite
| close to the model that we currently aim at.
Definitely agree to keep them separate. But I do think the GUI
API should perhaps conceal whether it's using IORefs or MVars,
since in a concurrent system one will certainly want to use the latter.
| * After this, the main difference that remains is the
| representation of GUI components as a vanilla data type
| instead of opaque handles that do not make the structure
| of the components explicit in the types (like the TupLS
| does). From the paper, it wasn't clear to me how useful
| that is for the application programmer.
This is indeed the most significant feature. It has the merit
that there is a data structure that acts as a description of the
GUI, which has some conceptual clarity, for me anyway.
Instead of building up a model in your head, there it is written down
(you can presumably even print it out).
Not so good when the GUI shape is changing -- I wonder how
Clean does that.
Anyway, all I'm not pressing to adopt that model; merely to
think about it. There is lots more tutorial material about the
design than our short paper.
Simon
