Re: [q-lang-users] RFC: Conditional syntax

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

John Cowan wrote:
> I actually prefer Ex. 1 to Ex. 2, because there is nothing lazy here.

Do you mean "lazy" as in "deferred+memoizing" or just "deferred"? If 
it's the former, then you're right (but streams, by default, aren't 
memoizing in Q either). If it's the latter then you're wrong because the 
guards/patterns and the corresponding values need to be deferred until 
they are looked at. The tails of the clause sequence don't have to be 
deferred, with that I agree.

Remember, in Q "special" == "deferred" == "call by name". In Q, there's 
neither a conceptual nor a technical difference between, say, the 
deferred arguments of "defined functions" like (or else) or ifelse on 
the one side and those of "constructors" like (') and cons_stream on the 
other side. That's because there's actually no distinction between 
defined functions and constructors in the first place.

Unfortunately, I got into the habit of using "lazy" synonymous with just 
"special" or "call by name", whereas most of the FP community will 
reserve "lazy" for "deferred+memoizing" a.k.a. "call by need" (which I'd 
call "fully lazy"). Maybe that's the source of the confusion.

Anyway, I'm perfectly happy with option (1), too.

[infinite clause lists]
> Only if we are capable of making infinite decisions, which I at least
> am not.

But you could write a program to generate a potentially infinite (or 
huge) sequence of conditional clauses and then start evaluating it until 
you find a clause that's true. Semi-decision procedures come to my mind. 
Anyway, such (rather esoteric) applications can already be handled using 
stream programming, so there doesn't seem to be a point in supporting 
that directly with cond.

[grouping syntax]
> I agree with this, and I agree that the implied internal objects should
> be tuples in all cases; again, the situation is inherently immutable
> and fixed.

All right, I'm going to implement this and commit it to cvs tonight, 
along with cond/case as described in Ex. (1). Judging from the replies, 
everybody should be happy (or at least not unhappy) with that.

Thanks for all the responses! :)

Cheers,
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