develooper Front page | perl.perl5.porters | Postings from January 2018

Re: We need a language design process.

Thread Previous | Thread Next
David Nicol
January 1, 2018 22:35
Re: We need a language design process.
Message ID:
I liked the going-back-to basics "history of p5p" bit.

I've been more or less lurking here since the 20th century; I don't lurk
very well because I share my opinions.

I've always held, and continue to hold, that a well-defined macro language
would be able to take care of having all the various styles (smartmatch and
given/when are for purposes of this argument "styles") co-exist, by
declaring a set of transforms that is so be applied to the current
compilation unit before it gets instantiated into the executable format it
eventually gets instantiated to. So I see macros operating at the same
level as the "peephole optimizer."

Also, I am not aware of a new source of people using Perl 5. It seems like,
and it has seemed this way since, say, 1998, that the "real perl six" is
alive and well and is called Ecmascript. The fact that the New, Cool
features that people (well, me at least) want are available in Node.js
plugins rather than as CPAN modules is a fine evidence that Perl is

Perl is dead, long live Perl!!!!!

But what direction to go in Perl five in Javascript? Rewriting the core
core based on a specification-defined (not implemetation-defined) Perl,
allowing multiple simultaneous implementations? Things like the Inline::
modules seemed to be moving in that direction. Is there Perl in Node? Node
in Perl? Some kind of shim allowing Perl to be loaded browser-side instead
of porting?

Where is the three line invocation required to provide a Perl API to a node
library?  Has someone got that working?


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About