Nick Name wrote:

On Thu, 23 Jan 2003 15:38:31 -0600 Jon Cast wrote:

...

...

Another idea: if I allow the list of objects in the panel to be infinite,

...

Sorry, but I'm having difficulty figuring out where you'd get an infinite list of objects to put in the panel. I suspect any solution is going to depend on how the list of objects is put together.

It could be any lazy list, potentially infinite (and I would not like to evaluate it).

So we're not talking about an actually infinite list, just an I'd-rather-not-evaluate-it list. That makes things clearer (in particular, it is /possible/ to evaluate the whole thing, if necessary). The reason I think this a good thing is it occurs to me that if you want to map an IO action run for its side-effects (e.g. ``play every file'') to every element in the list, you're going to have to compute out the whole thing anyway, so there's no great harm done in pre-computing every element so you can get the list of elements. OTOH, if you want to say ``give me a new panel with every element derived from the elements in this panel by this transformation'' (either pure or IO), you want the result to still be lazy. So, you have to compute the list of allowed transformations /without/ touching every element. As you've predicted, this requires that you be conservative about what operations are offered. I would store a list of types, or a filter for such a list, with every panel. Panels generated lazily would have to be conservative (see below), but perhaps once the last panel element was computed you could re-create the type list from the actual values. Of course, this leads to the FAQ entry: Q. Why does the list of operations on a panel sometimes grow 3 times as long once I've looked at the last item? But that may be an acceptable price to pay (assuming somebody figures out an answer that'll be understandable by the average user). In any case, once you've got the list of possible types, you can take the transformers/actions for each type and compute the intersection.

An example is a "find" function, wich returns a lazy list with the use of unsafeInterleaveIO.

It would be useful to see the actual first N files as objects into the "panel" or desktop area, or list, anything visual, and then be able to obtain, for example, the filtered list of all the "sound files", which would still be a lazy list.

In this case, I would attach a (possibly empty) list of new constraints to each filter. For example, if you had a class SoundObject, and a function isSoundObject, I would represent the filter as (isSoundObject, [HasClass "SoundObject"]. Then, when the filter was run, I would add the filter's constraints to the argument's constraints. That way, the system would know that any action available across all sound objects was now available. Maps seem harder, but I'm sure the transformations on constraints could be encoded and used to find the new constraints.

Should the user scroll the panel down with some arrow-like control, the list would get evaluated and the find function would run under control of the user interface.

I am just thinking about what a "lazy functional desktop environment" could mean, trying to figure out some use case.

That sounds like an excellent idea; please don't take anything I say as a discouragement to that project.

Vincenzo

Jon Cast