Re: [q-lang-users] The implicit operator in Q

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

John Cowan wrote:
> Today I discovered that (whether intentionally or not, I don't know)
> the Q rule processor will accept rules whose head is a variable.  You can
> write rules like:
> 
> 	X:Num Y:Num = X * Y;

Yes, Q is fairly permissive with respect to the form of the left-hand 
sides of equations. In fact, early versions of the interpreter would 
place no restrictions whatsoever and thus even allow you to have 
equations like "true = false" or "0 = 1" which are now forbidden, to 
keep you from doing something "stupid".

But one could still consider the above behaviour as a misfeature, 
because an equation like "0 Y = Y+1" is forbidden while "X:Num Y = Y+1 
if X=0" works. There are several ways to resolve this inconsistency:

1. forbid a variable as the head element of the toplevel expression on 
the lhs of an equation

2. never reduce a function application with a "const" in the head, even 
if there's a rule which allows this

3. forget about "const" and allow rules with constants in the head (but 
this means that an equation like "0=1;" would be valid Q again)

4. be happy that Q still leaves some dirty tricks to be discovered by 
the master Q programmer ;-)

1+2 seem unnecessarily restrictive to me, while 3 is probably too 
permissive, and it also makes it more difficult to optimize the 
automatic evaluation of suspensions. I'm currently leaning towards 
solution 4, but that might be due to the fact that it's almost 40 degree 
Celsius a.k.a. 100 degrees Fahrenheit over here. ;-)

What do you think?

> ==> [1,2,3] [4,5,6]
> [1,2,3,4,5,6]
> 
> In effect, Q is allowing an implicit (empty) operator in these cases.

Note that this invisible operator is in fact just function application. 
Since expressions in Q are not subject to any typing constraints, 
nothing keeps you from writing something like "0 1" which applies the 
"function" 0 to the "argument" 1.

> This could be a very handy feature when dealing with types that have
> some natural "principal" function of two or more arguments.

Yes, but note that as the algebraic type constructors are usually 
declared "const", they currently cannot occur in the head. E.g., the 
following currently yields an error message:

type BinTree = const bin X Y, ...;

bin X Y Z = ...; // error

In fact, that's the whole point of having "const" function symbols. Of 
course, if you leave away the "const" then the equation becomes legal.

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