[GUI] RE: GUI Library Task Force

[Simon Peyton-Jones]

[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=20
think about it.  There is lots more tutorial material about the
design than our short paper.

Simon