Front page | perl.perl5.porters |
Postings from January 2018
Re: We need a language design process.
Thread Previous
|
Thread Next
From:
David Nicol
Date:
January 8, 2018 17:19
Subject:
Re: We need a language design process.
Message ID:
CAFwScO9Wn70cNgpQ3aSzE--p4paNJebPv-JGxGuGUtKFYOFmhw@mail.gmail.com
On Mon, Jan 8, 2018 at 5:49 AM, Dave Mitchell <davem@iabyn.com> wrote:
> On Sun, Jan 07, 2018 at 04:01:25PM -0600, David Nicol wrote:
> > It seemed like a possible way forward would be to ditch YACC entirely and
> > restate the actual language parsing in Perl
>
> Rewriting the perl parser in perl would involve a massive slowdown in
> compile time.
>
> --
> Diplomacy is telling someone to go to hell in such a way that they'll
> look forward to the trip
>
The last thing I want to do here is to have another shouting match with Mr.
Mitchell. He is absolutely correct. The devil is in the details and I'm
choosing to ignore the details.
That said, ...
While "Rewriting the perl parser in perl would involve a massive slowdown
in compile time" is true, it's a straw man irrelevant to the "correct
first, then fast" thought experiment about grouping syntax commonalities
with macros, the possible results of which would then get rolled back into
the grammar.
perly.y currently gets compiled into a compiler, involving data structures
concerned with lexing and parsing. Somehow gaining control over those data
structures -- allowing them to be more dynamic, via some well-formed
mutation operators that reduce the obvious fragility letting them change
entails -- but leaving the operation of that system alone as much as
possible -- might lose some sneaky automated optimizations, but the
resulting slowdown shouldn't be "massive" and might not be measurable at
all.
AIUI at a high level perl compilation (of one compilation unit, like the
operation eval-string ) works like so:
SOURCE -> A -> LEXING -> B -> PARSING -> C -> OPTIMIZING -> D ->
HAVE_AN_OP_TREE
"Source filtering" operates at point A and is fragile.
A macro system would operate at point B or C and would be able to (within a
limited scope) modify the LEXING and PARSING engines, by introducing new
features or overriding existing features with lexically scoped alternatives.
Allowing override going back to point A would enable the possibilitiy of
features that are simply not possible with a LALR(1) parser, when such are
desired. This is of course possible with source filtering, except for the
fragility -- in order to have a robust source filter, you have to
reimplement some non-trivial amount of lexing and parsing in order to
correctly and reliably distinguish between INFIX-DIVISION-OPERATOR and
PREFIX-BEGIN-REGULAR-EXPRESSION-MATCH-OPERATOR for instance.
see https://en.wikipedia.org/wiki/LALR_parser
The ideal API hooks might appear as token streams that can be subscribed to
-- the subscription mechanism would be more subtle than simply NEW KEYWORD
which is what Devel::Declare seemed to promise -- perhaps a combination of
a keyword and a parser state, which implies an API to parser state, that
is, yacc run-time internals.
Providing APIs into the later points would facilitate using perl op trees
as compilation targets for other things -- a whole realm of possibility
that as far as I know nobody is doing. That is, I'm not aware of anyone
ever creating a Ruby or Python or Javascript front end that emits perl ops,
or anything else aside from Perl that compiles a source to the
representation described at
https://github.com/Perl/perl5/blob/blead/regen/opcodes in an interoperable
way. Or alternately, any way to easily alter Perl to use as its compilation
target some other platform-independence abstraction, for instance
https://en.wikipedia.org/wiki/Apache_Portable_Runtime, instead of its own.
Thanks for reading. I hope the above is taken as a sharing of ideas, had
after successfully playing with a small child involving incorporating
different, incompatible, kinds of children's blocks into the same toy
castle, rather than as any kind of complaint or bug report or call to any
specific action beyond imagining some kind of grand, utopian,
interoperability and ease of use. All the blocks are more or less square;
all the blocks remain still when set on a flat surface; regardless of being
made of wood or plastic, they still stack.
--
âno man should be compelled to do what the laws do not require; nor to
refrain from acts which the laws permit.â Calder v. Bull (U.S. 1798)
Thread Previous
|
Thread Next