First impression: Don't go there.

Longer answer:

On Wed, 2002-03-27 at 16:29, Michel J Lambert wrote:
> New syntax is 'qs', aka quote sub, which is similar to q, except that it
> interpolates all of: ${..} @{..} and %{..}
> All subroutines which are interpolated, are interpolated as regular text,
> with no bindings, so that they get lexically scoped in the code they are
> returned as part of.
> Then macros essentially return a string which gets interpolated at the
> call site.
> 
> macro while ($cond, $body) {
>   return qs{
>     GENLABEL:
>     goto ENDLABEL if( ${ $cond } );
>     ${ $body };
>     goto GENLABEL;
>     ENDLABEL:
>   }
> }

Ok, ignoring the fact ${ $body } seems to be wildly non-intuitive syntax
for a single-interpolation, I don't see the value of manipulating macros
as string at all. We have eval for that (eval+anon subs+closures is 99%
of what LISP macros are, and I think that's what you're modeling this
after).

Macros could add something to Perl, but I don't see why having a macro
return a string instead of looking and acting like a subroutine would be
a bad thing. In fact, as I pointed out before, you can do almost all of
the scoping stuff that you would want out of a macro in Perl with the
existing subroutine/code ref syntax and a special property.

Again, that would look like (a third syntax actually, but very similar
to what I suggested before):

        sub uvula($cond,$body) is macro {
                while($cond.()) {
                        $body.();
                }
        }
        uvula cond => sub{$_ = $fh.getlines() }, body => sub{ print; };

There may be some simpler way to construct the call (this should all be
standard Perl6 syntax, I'm not trying to change anything here), but this
overly verbose invocation avoids my having to demonstrate that I'm not
sure how such things are being handled in Perl6 yet.

You just "explode" the code ref so that it does not construct its own
scope (actually, it does, in the same way that braces do, but not to the
extent that subroutines do... I'd have to look at the source to remember
the difference there).

> The ugliness of the symbols is necessary for the more lowlevel macros that
> would compile down to very simple ops, and thus make translation to the
> parrot bytecode that much easier. One additional thing the above need is
> that either GENLABEL and ENDLABEL need to be renamed by qs() so that
> while's within while's don't have problems, or we'd need to follow
> Scheme's example of gensym, which constructs unique symbols.

If labels are lexically scoped, There's no problem here. Of course, you
need to "promote" all lables to the beginning of the enclosing block,
but that's compiler magic, and doesn't violate lexical scoping.



Reply via email to