Re: [q-lang-users] Stream constructors

[Albert G. <Dr....@t-...>]

Sean Russell wrote:
> Not really, although I do have a question.  Why is the alternate mark-up 
> (braces instead of brackets) necessary?  Is it aesthetic, or is there some 
> parsing issue that I've missed?

Well, there are different ways to get lazy data structures in an eager 
FPL, but the fact of the matter is that in an eager language you will 
*always* need some kind of special markup to distinguish suspensions 
from ordinary expressions. Leaving the syntactic sugar and 
implementation issues aside, you can think of lists and streams being 
defined in Q by:

type List = const list_nil, list_cons X Xs;
type Stream = special const stream_nil, stream_cons X Xs;

So lists and streams are really different data types in Q and need 
different syntaxes because that's the only way that the interpreter can 
know which kind of object to create.

There are other ways to handle lazy evaluation in a strict FPL. E.g., in 
the ML dialect Alice you'd use an explicit suspension created with `lazy 
(<expr>)'. IMHO Q's notion of special forms has its advantages because 
it allows both macro-like functions and lazy data structures to be 
handled in a uniform way. And you don't have to write `lazy' all the 
time, because once you've declared your special forms the interpreter 
knows where and when suspensions need to be created without any further ado.

> Explicitness is nice, but not having the lists and streams share syntax means 
> that you won't be able to re-use library functions that operate on lists.

That's true, and it's why there is a standard library module stream.q 
which extends all the usual list operations to streams. I think that 
this strict separation actually has its advantages, because lists and 
streams are quite different beasts on the algorithmic level. An 
efficient list algorithm might be completely unusable for streams 
because it's too strict, and, vice versa, an algorithm tailored for 
streams (considering non-strictness requirements) might be quite 
inefficient for lists.

OTOH, if your algorithm can be expressed in terms of the standard 
list+stream stuff like fold, map, zip etc. then chances are good that it 
can be used with both lists and streams without ever having to worry 
whether it's a list or stream that you are working with. But that still 
relies on that (some of) the basic list operations are optimized on the 
specific data structure at hand.

Albert

-- 
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email:  Dr....@t-..., ag...@mu...
WWW:    http://www.musikinformatik.uni-mainz.de/ag