Re: [q-lang-users] New 'where' syntax

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

Keith Trenton wrote:
> Cool. OTOH, I'm still waiting for syntax to support the new 'when' and 'what if' clauses...

LOL. I guess that we'll get those when the first 64 qubit quantum
computers arrive. ;-)

More seriously, the Haskell programmers among you probably noted that
the new syntax looks almost like Haskell's guarded equations (including
Peyton-Jones' pattern guards), except that it's a tad more verbose (and,
of course, in Q the qualifiers are processed from right to left rather
than from left to right). E.g., here's the example taken from
http://research.microsoft.com/~simonpj/Haskell/guards.html:

  clunky env var1 var1
   | Just val1 <- lookup env var1
   , Just val2 <- lookup env var2
   = val1 + val2
  ...other equations for clunky...

In Q this definition can now be written as follows:

  clunky ENV VAR1 VAR1
   where just VAL1 = lookup ENV VAR1,
     just VAL2 = lookup ENV VAR2:
   = VAL1 + VAL2;
  ...other equations for clunky...

(Of course you could already define 'clunky' that way with a rhs
qualifier ever since Q got its 'where' clauses, but the new syntax
matches Haskell's more closely.)

All in all, I think that the new syntax looks pretty nice, and the
ability to mix lhs with rhs qualifiers allows you to handle the most
common usage cases without having to resort to some kind of nested "case
structures" which tend to be harder to read (YMMV, of course).

--

Another side note, and request for comments about "qualifier" vs.
"guard": AFAICS, the term "qualifier", which I use as an umbrella term
for both 'if' and 'where' clauses, is one of the few remaining original
"Q'isms" in the manual. Maybe the term "guard" would be more
common/appropriate there? And should I better use "guarded equations"
instead of "conditional equations"? (This latter term actually comes
from term rewriting theory, so it's not my invention.)

Yes, I'm old enough to still remember the fate of Algol 68 whose
designers made up all kinds of weird names for common things. ;-) Of
course, mathematicians tend to invent their own jargon as they need it,
but I realize that if there's a well-established term for a certain
notion then it should be used to avoid confusion.

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