develooper Front page | perl.perl5.porters | Postings from June 2021

Re: RFC: Multiple-alias syntax for for

Thread Previous | Thread Next
From:
Nicholas Clark
Date:
June 14, 2021 14:38
Subject:
Re: RFC: Multiple-alias syntax for for
Message ID:
20210614143830.GT16703@etla.org
On Mon, Jun 14, 2021 at 08:51:20AM -0500, David Nicol wrote:
> On Mon, Jun 14, 2021 at 4:22 AM Nicholas Clark <nick@ccl4.org> wrote:
> 
> >
> > I don't think that we have any way to emulate this syntax for earlier
> > Perls. I don't have any feel for what sort of API we would need to add to
> > the parser to make it possible in the future, and whether any API we could
> > add would be fragile and tightly coupled to the exact current
> > implementation.
> >
> 
> 
> this, like most all syntax extension proposals, could be done with a robust
> macro system which would hook the "for" keyword and own the parser for a
> few tokens.

I appreciate that you're trying to make helpful suggestions, but that level
of detail is "obviously true" without giving any idea about how to implement
it. For getting to a working solution, it's about as useful as jokingly
observing that "any sufficiently advanced technology is indistinguishable
from magic". (Which, sometimes, is what the perl internals feel like.)

"macro system" - yes, sure, what one seems to need is a way to be able to
tag each keyword with "actually, don't use the regular parser here, call
me instead". So with that in place, when the parser gets to a keyword and
it's `for` it takes the "have a macro override path"

But what's down that path? Really, if we do that, we need to have a
*complete* *re-implementation* of the parsing of `for` (all the way to the
end of any `continue` block), so that we can then make arbitrary other
changes (eg, add an optional `else` block to `for` blocks).

Which means that we need a complete and correct parser. For that version of
perl. For *each* and *every* version of perl that we want to "polyfill"
back to. Because Perl C parser code changes between each release. Which
means

1) either our CPAN module has to ship copies of each and every parser
2) or we actually then have to re-write the parser so that it itself is
   implemented as a macro system internally. So our "new syntax" module can
   just change the macros.


Either way would be hard. Rewriting the parser - well, the lexer code is C
code. The grammar *is* a grammar, sure, but it's *compiled* to fixed C
data structures by bison, and we put *that* C into git. And that C is
compiled to fixed data structures at build time. We couldn't change Perl's
parser to be "runtime malleable" with macros (in any generic way) without
completely rewriting it *not* to use bison.


And *that* level of detail for a thought experiment might be useful. But
that's not what you wrote. And hence why it's actually not that helpful
to suggest generic broad concept ideas, particularly when the folks who
say that they are stuck have a heck of a lot more experience of the evil
horrors of the internals than you do. (You are lucky. You have no scars.)

>             As to aliases instead of copies, it seems it would rely on
> lexical aliasing unless the macro system was outputting to a deeper level
> than a miniperl.

That's really actually not a problem. The C internals throw pointers to SVs
around. Aliasing and binding are trivial at the C level.

Different runtime behaviour is easy (enough) with custom OPs.

It's not really the way that you assumed that it was. The problem is really
the parser, not the runtime.

Nicholas Clark

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About