Re: [q-lang-users] Polynomial module.

[Rob H. <hub...@gm...>]

Hello Albert,

Thanks for the information...

On 31/10/06, Albert Graef <Dr....@t-...> wrote:
> Hi Rob,
>
> I'm redirecting this to the list so that we can discuss it here. I tend
> to agree that this problem calls for a general solution which also
> adresses the weirdness of lambda reported in Eddie's recent post.
>
> Rob Hubbard wrote:
> > If you run polynomial.q with --pedantic, you may notice the message
> >    Warning polynomial.q, line 722: undeclared variable symbol `Y'
> > which comes from my use of your sieve:
> >    sieve {X|Xs} = {X|sieve {Y:Y in Xs,Y mod X<>0}};
> > I think I've seen similar warnings for lambdas.
> > Is that a bug? From a recent posting on the mailing list, I understand
> > that such variables are not bound as they would be with a 'real' lambda,
> > but could the warnings on such 'pseudo-bound' variables be suppressed?
>
> It's not a bug, but a misfeature, or a wart if you prefer. Currently
> there is no way for the interpreter to distinguish the "pseudo bindings"
> performed by lambda and list/stream comprehensions from ordinary uses of
> free variables. Therefore right now the only way to get rid of those
> --pedantic warnings is to explicitly declare the symbols as free
> variables (because that's just what they are, as far as the interpreter
> is concerned). You can also do that with embedded "var" keywords in the
> definitions.

I understand.

I would like to use inline "var"s. Unfortunately, that might then hide
another undeclared symbol elsewhere in my script.

One option is to "postfix" any free variable with the name of the
function definition containing it.
For example:
    sieve {X|Xs} = {X|sieve {Y_sieve: Y_sieve in Xs, Y_sieve mod X<>0}};

The "workaround" I've opted for is to have an explicit
    var FreeVar;
early in my *.q file, and to use that in all contexts where the
variable is intentionally free.

(Similarly, if more that one was needed anywhere, I could use
    var FreeVar1;
    var FreeVar2;
    //and so on...
)

> But the warnings are only a symptom, not the real cause. Having
> meditated about this some more, I think that it might be useful if the
> interpreter was able to deal with variable bindings performed by special
> forms like lambda and listof/streamof. But this needs some new kind of
> "variable scoping" declarations for special forms, and I haven't found a
> general solution for that yet. Of course I could hardwire the desired
> custom scoping rules for lambda and comprehensions into the interpreter,
> but that's not a real solution, because the programmer may wish to
> derive his own special forms from these, or create his own
> variable-binding special forms from scratch.
>
> So what we need are some special directives which tell the interpreter
> which parameters of a special form bind variables and which other
> parameters the scope of these variables extends to. Something like this:
>
> public special lambda __bind__ X __scope__ Y;
>
> Unfortunately, such a simple construct won't do the trick for
> listof/streamof, since these actually perform their bindings in the "in"
> clauses, so the lexical scoping rules would be rather complicated in
> this case. And such a feature might also wreak havoc on the ability to
> treat lambdas as ordinary expressions which can be constructed and
> manipulated at runtime.
>
> Any ideas, anyone? I don't recall seeing anything like this in any other
> programming language, but Q is also rather unusual in that it allows the
> programmer to define his own special forms (apart from the macro
> facilities of Lisp, but these are compile-time only).

I'm not sufficiently competent in Q to offer any good suggestions yet
I'm afraid. However, I can see that what is needed is a way to bound
the scope of a free variable or "var" declaration.

Perhaps something along the lines of

    var Y in
    sieve {X|Xs} = {X|sieve {Y:Y in Xs,Y mod X<>0}};

would be a possible approach.

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

Thanks,
Rob.