I'm going to YAPC

[Chip Salzenberg]

On Thu, May 30, 2013 at 6:58 PM, Reini Urban <reini.urban at gmail.com> wrote:

>
> On May 30, 2013, at 8:42 PM, Chip Salzenberg <rev.chip at gmail.com> wrote:
>
> > I'll be at YAPC 2013.  Reports of my staying home were greatly
> exaggerated.  (By me, but don't let that confuse you.)
> >
> > I'm hoping for a design-a-thon aspect to the hackathon time.  *Not*
> language design, mind.  High-level bikeshedding about sigils and regexes
> must be left behind, or at least left for later.  The various
> reimplementation projects in play aren't tied to those things.  The
> questions at hand lay in *how* to implement things, with no handwaving
> allowed, and looking at the consequences of those decisions.  I'm thinking
> whiteboards, coffee, and determination.  With those, all kinds of neat
> things might happen ... and they probably will.
> >
> > I suppose I'll attend a talk or too as well, as long as I'm there.  :)
> >
>
> What?
> And I seriously thought of proposing making the scalar $ sigil optional.
> It looks bad and is only needed within strings. functions are scalars also,
> so treat them as such.
> Bleach the beast. ruby had a point.
>
> if (b) { a = 12 }
> elsif (b) { a = 14 }
> else { a = sub{ 1 } }
> print a;



A sigil-free mutation of Perl would be a good language, to be sure.
 Perhaps not really Perl, but still good.  :)  But as I'm sure you'll
agree, it's easy to mechanically translate between the two dialects, which
renders it fundamentally uninteresting to VM hackers.  And as such I hope
never to have to talk about it in Austin.

What I think we *do* want to talk about are the dimensions of VM
implementation:  The major issue that can't be avoided is semantics.  What
*are* the translation failure points moving among Perl 5, other Perl
dialects (present and proposed), various candidate VMs, and even other
dynamic languages?  Where do square pegs meet round holes, and can we round
the pegs, square the holes, or just get a bigger hammer?  What's fun *and*
useful?

For one example subject:

It sounds good to target Perl 5 on JavaScript until you realize that all of
"perldoc perlre" has to work.  Anyone planning to reimplement just PCRE in
JS, let alone the full Perl regex engine with (?{}) and (?{{}}) ?  Would
anyone want to *use* it?  Anyone?  Bueller?  Also, JS uses UCS-2, not even
UTF-16.  Planning to toss the whole swash database into that perl.js?  IMO,
proper Unicode support is impractical on JS.  And who wants to retrofit the
user code that assumes timely DESTROY when JS has no destructor calls?  Not
looking good to me.  Most of these issues are also bad enough in Java to
make it a hostile environment for Perl.  What have I missed?

Here's another:

I would prefer a Perl VM that doesn't use references (RVs) in the Perl 5
sense, but works more like every other dynamic language where there are no
separate values called "references" because all general-purpose values can
be used by reference[*], though with escapes for efficiency (unboxing).  A
Perl VM without RVs is a much better Perl VM: it's simpler, and it's a lot
more compatible with non-Perl data models.  It might even host Perl 6-ish
languages without huge pain.  AFAICT, the only place RVs are user-visible
and persistent and non-fakeable is in references to scalars, e.g. \$a and
\\$a, which can be special-cased.  Is my imagination good enough?  I think
XS compatibility can be kept as well.  It's not like we can afford to keep
revealing our real full API to XS code anyway.  That leads to hardening of
the implementation.  So XS will be a fakery level going forward.

Here's a third:

Working complex systems always evolve from earlier working systems.  So I
think the best C-family VM in the future of Perl is likely to be a stepwise
evolution from Camel perl.  Maybe the steps will be big!  But it's a matter
of steps.  In the end we may have changed both the handle and the head, but
it'll be the same axe.

Here's a fourth:

What parsing technologies are suitable for Perl?  Can we crib something
from Parrot land?  *Should* we?  Personally I'd love to parse Perl with a
Boost Spirit grammar, and I probably will, but extending it would be
somewhat more work than using a grammar itself build on the Perl VM's
dynamic nature ... though again, we must be sure not to slow down parsing
to the point it's not fun to use.  So, a C++ parser may have a limited
lifetime; but if that's the case, how did we get this far with perly.y?

So many interesting questions, so little time.

[*] sometimes the value references are faked, e.g. V8 Number, but that's
actually good; it shows that faked references can work.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/yapc/attachments/20130530/e4234dca/attachment.html>