Re: [q-lang-users] Matching with special constructors

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

Albert Graef wrote:
> Specifically, the pattern matcher, when trying to match 
> a pattern inside a suspended argument, should evaluate that argument 
> recursively before proceeding.

I should clarify this: "a pattern inside a suspended argument" only 
refers to subexpressions of *non-special toplevel arguments of the lhs 
pattern* here. E.g., if you have something like:

special foo X; special bar X Y;
foo (bar (gnu X) Y) = ...;

then the special argument of foo should _not_ be evaluated by the 
pattern matcher before matching against bar (gnu X) Y. Nor should any of 
the subexpressions (like the first argument of bar) be evaluated by the 
pattern matcher.

OTOH, if you have something like:

private foo X; special bar X Y;
foo (bar (gnu X) Y) = ...;

where bar acts as a special constructor in the _non-special_ argument of 
foo, then the pattern matcher, when it comes to consider the subpattern 
gnu X, will first evaluate the first argument of bar before proceeding 
with the matching process.

Yes, I know that this sounds a bit confusing, but the restriction to 
non-special toplevel args is necessary so that the special forms 
themselves still have full control on where and when their arguments are 
evaluated. Otherwise special forms like lambda would stop working.

There are some other hairy implementation issues related to the proposed 
change of the pattern matcher which I didn't even mention yet. (Yann, 
you opened a can of worms there. ;-) In particular, the pattern matcher 
is also used when building special argument terms, to make an informed 
decision about which parts of a suspension actually need to be evaluated 
later (without this optimization, special forms are so slow that they're 
essentially unusable). This "quick reducibility checker" will have to be 
adapted, too, so that it can handle "irrefutable" matches where 
suspensions protected by special constructors are involved.

Talking about irrefitable matches, another question is whether Q should 
also support Clean/Haskell style lazy patterns, see e.g. Section 4.4 at 
http://www.haskell.org/tutorial/patterns.html. While these look like a 
kind of hack to me, they do allow more succint representations of 
certain algorithms. Do any of the seasoned Haskell programmers on this 
list miss them at all in Q?

Well, I'm still pretty confident that there are no real roadblocks on 
the way to the new pattern matching code, only a bit of "blood, sweat 
and tears". ;-) Hopefully cvs will be back up soon so that I can start 
working on this...

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