Nick Name <nick.name(a)inwind.it> wrote:
> On Thu, 23 Jan 2003 15:38:31 -0600
> Jon Cast <jcast(a)ou.edu> 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
