Nick Name wrote: <snip>

Ok, this is clear. I am still not sure of how to decide the type to give to the "extracted" object.

This is fairly easy if you have a finite number of possible types; you can use typeOf to determine which type you have, and then do a case analysis to use the particular type typeOf says you have. Another alternative is to write your operations to take Dynamic. If all of the functions you want to apply have some ``no action'' return value nop (say, they all return IO () with nop = return ()), and they all take monomorphic arguments, (maybe nop f . fromDynamic) will perform f on Dynamics of appropriate type.

In the graphical interface, any object should have a menu saying on its top row: "Text file" or "Applet" (depending from the type of the object) and then a list of operations.

This should happen even when the object is inside the panel-list, (so maybe a panel would be a list of untyped "objects" with an attribute of type [Operation]).

I wouldn't attach a list of operations to each /object/; I should think the list of operations wouldn't change across the type, and in any case you would want to allow the user to dynamically load new operations. So, I would attach a list of named operations of type (Dynamic -> Result) to each type, and offer the operations for a given type to the user.

But, to fully exploit the power of a "functionally-programmed" desktop, the interface should allow the user to map an operation onto all the objects of the panel; in this case the allowed operations should be those that all the object share.

This is fairly easy if you name the operations; then you can use that to compute the intersection of the operations for all the types. If you don't name the operations, then of course the problem becomes undecidable.

This is what I think, however I can't realize the connection between the haskell type system and what I wish to have. Can someone lead me to a clearer vision of the topic?

Vincenzo

Jon Cast