[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