Re: [q-lang-users] Q and Aardappel

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

jc...@re... wrote:
> AA handles this by treating if-then-else as syntactic sugar for its
> local rules [...]

But Q has conditional rules, not conditional expressions. I'm afraid 
that these cannot be handled in a similar manner.

Nevertheless, I think that a combination of specificity and textual 
ordering might be useful. I put it on the TODO list and if I have the 
time, I'll implement it in an experimental version of the interpreter.

> I would have no problems with disallowing local rules in special
> forms altogether.  I think that would also eliminate your problem with
> implementation as well, although I am not sure I understand it.

I dislike such a solution which introduces arbitrary restrictions on the 
form of the rules. :(

Maybe I didn't explain the problem well enough. Surely there are some 
non-trivial implementation problems to be solved. But the main problem I 
see with local rules is that, unless you put severe restrictions on the 
form of the rules, the notion of a normal form is not well-defined any 
more. Maybe this is a better example:

foo X = bar X where bar X = X+1;

Now the question is, is `bar a' a normal form? You cannot answer this 
because it depends on the particular rewriting sequence. If you start 
out with bar a then the term is irreducible. If you start out with foo 
a, then it is not, because foo a => bar a => a+1. So even if you start 
out with a confluent and terminating rewriting system, you cannot decide 
equality using just rewriting any more. IMHO, this is a bad feature in a 
language based on term rewriting.

OTOH, the local rules allowed in Aardappel are more restricted, namely 
rules of the form f ... = ... where f is a new function symbol. That's a 
fairly arbitrary restriction in a general term rewriting language. Of 
course it eliminates the semantic difficulties (and also most of the 
implementation difficulties I see) because the local function symbol 
cannot be used outside the rule where it is defined.

In fact, Aardappel's construction for translating local rules to global 
ones (p. 65) is an idiom in Q. Whenever you need a local function, you 
introduce a (global) private function instead which takes the variables 
it needs from the other definition as extra arguments. I must admit that 
this is inconvenient. Kind of the same restriction you have in C (no 
nested functions).

So it all boils down to the question whether syntactic sugar should be 
provided to support this idiom in Q. I tend to dislike it, because of 
the arbitrary restrictions on the form of the local rules. Also, I would 
probably have to break backwards compatibility once more. Any other 
opinions? Suggestions for the syntax?

> But in general
> I think they are the Right Thing from the viewpoint of encapsulation;
> they allow you to simplify "deep and hairy" rules.

That I agree to. :)

> Also, unifying
> local variables, conditionals, and functional arguments is aesthetically
> attractive.  See the thesis pp. 48-50.

It's certainly nice to derive all of these from a more basic language 
feature. But I don't think that the way you deal with functional 
arguments in Aardappel is very straightforward. Curried function 
applications are much more convenient, and you get closures for free. 
Just compare the Aardappel definition of the scale function on p. 50 
with the following equivalent Q code (where the scale function takes the 
list as its 2nd argument):

scale N = map (*N);

> The thesis pp. 13-21 and pp. 51-57 are more eloquent than I can be on
> the virtues of Linda-style concurrency and its applicability to tree
> rewriting.

I haven't taken a deeper look at this yet, but from what I've read, it 
appears to me that it wouldn't be too difficult to write a little Q 
script which implements the basic Linda operations (minus the syntactic 
sugar that Aardappel offers) in terms of Q's POSIX thread operations. 
Have you tried that already?

Cheers,
Albert

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