<div dir="ltr">On Thu, May 30, 2013 at 6:58 PM, Reini Urban <span dir="ltr"><<a href="mailto:reini.urban@gmail.com" target="_blank">reini.urban@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im"><br>
On May 30, 2013, at 8:42 PM, Chip Salzenberg <<a href="mailto:rev.chip@gmail.com">rev.chip@gmail.com</a>> wrote:<br>
<br>
</div><div><div class="h5">> I'll be at YAPC 2013. Reports of my staying home were greatly exaggerated. (By me, but don't let that confuse you.)<br>
><br>
> 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.<br>
><br>
> I suppose I'll attend a talk or too as well, as long as I'm there. :)<br>
><br>
<br>
</div></div>What?<br>
And I seriously thought of proposing making the scalar $ sigil optional.<br>
It looks bad and is only needed within strings. functions are scalars also,<br>
so treat them as such.<br>
Bleach the beast. ruby had a point.<br>
<br>
if (b) { a = 12 }<br>
elsif (b) { a = 14 }<br>
else { a = sub{ 1 } }<br>
print a;</blockquote><div><br></div><div><br></div>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.<div>
<br></div><div>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?</div>
<div><br></div><div>For one example subject:</div><div><br></div><div>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?</div>
<div><br></div><div>Here's another:</div><div><br></div><div>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.</div>
<div><br></div><div>Here's a third:</div><div><br></div><div>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.</div>
<div><br></div><div style>Here's a fourth:</div><div style><br></div><div style>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?</div>
<div style><br></div><div style>So many interesting questions, so little time.</div><div><br></div><div>[*] sometimes the value references are faked, e.g. V8 Number, but that's actually good; it shows that faked references can work. </div>
</div><br></div></div>