in reply to Re: NO PERL 6
in thread NO PERL 6

One thing most everyone with objections to Perl 6 seems to overlook is that it will allow the programmer to actively interfere with the parsing and compilation: the Perl 6 grammar will be available as a built-in Perl 6 pattern grammar and we'll be able to work on the underlying Parrot VM level. It may be awkward at first, but so was source filtering in Perl 5, and that has been addressed by way of modules, some of which made it into the 5.8 core.

I am wary indeed of the possibilities for abuse this opens up, much like define macros offer in C, but on the other hand I shiver (with anticipation) to think what the likes of TheDamian will be able to do this way.

In addition, I'm fairly certain that if Perl 6 gets something wrong in a way most of us dislike and which is fixable by way of such low level interaction, then a module or several will sooner or later be written and, if they meet expectations, be widely adopted by the community.

I am, surprise surprise, not 100% satisfied with all of the proposed changes for Perl 6 myself but I quickly got over my fear. For one thing, I realized that many features in Perl 5 must have looked just as bizarre to the Perl 4 crowd, meaning I will likely get used to the "strange" stuff and eventually take them for given. And ever since Apocalypse 5, I'm absolutely optimistic that if there's anything I feel is really awful, I will be able to fix it for myself - the sky is the limit. That, and your imagination.

Makeshifts last the longest.

Replies are listed 'Best First'.
Re: Re^2: NO PERL 6
by pdcawley (Hermit) on Dec 10, 2002 at 08:05 UTC
    It's my understanding that Perl 6's syntax mutation capabilities will be a good deal safer than using C #defines. In fact, I'd argue that the current state of the Perl syntax munging art, Source Filters, are more like C macros than Perl 6 rules will be. Perl 6 rules are so much safer, they take away the need to do your own (possibly fallible) parsing of Perl source code, you just modify the rules at the appropriate level in the grammar and away you go. Also, rule based syntax modification is lexically scoped, which is definitely handy...
[reply]

      I was referring to abuse, not robustness. Like any other form of syntax or semantics alteration (operator overloading comes to mind), there are good reasons to have the opportunity (operator overloading comes to mind), but making use of it just because you can will easily create a maintenance nightmare (operator overloading comes to mind). And operator overloading is a relatively mild form of this. Perl 6 will allow really drastic interventions.

      I am excited about the possibilities, but I hope people use the opportunity carefully. It'll most likely turn out to be one of those things you should not do unless you know why you not.

      Makeshifts last the longest.

[reply]
      Also, rule based syntax modification is lexically scoped, which is definitely handy...

      How exactly is that supposed to work? It seems a bit paradoxical to me. Allowing lexical modification of the parser would have to happen at run-time; the only problem being that run-time is after compile-time :) I was under the impression that the process would be more like:

      1. The code must be in a BEGIN block or be use'd (same thing).
      2. The BEGIN block is parsed, compiled, and run with the current parser.
      3. When it is evident that parser rules are being overwritten, a copy of the parser is made.
      4. Modifications to the parser are actually made on the copy.
      5. When the BEGIN block exits, the modified parser becomes the real parser.
[reply]
        Don't forget that uses are compile-time things. You throw the parser modification code into a module and use it in the block that you want it in effect for. The module then pushes the changes to the parser module out to the user's scope. Then, when the compiler continues on it uses the new parser code.

        Something like the way strict works now, pushing things out to its caller.

[reply]
[d/l]
[select]

In Section Meditations