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

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

That should have been

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

below. I forgot the "var". Sorry.

Rob.

On 02/11/06, Rob Hubbard <hub...@gm...> wrote:
> 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.
>