Re: Parsing perl 5 with perl 6 (was Re: Larry's Apocalypse 1)
On Tue, 17 Apr 2001, Tim Bunce wrote: [...] That beautiful code will be beautifully _open_ to _external_ extensions. And that is how I imagine that Perl 5 support should be implemented. Exactly. I am pretty sure that already at the meeting in Monterey someone suggested that Perl5 should be the first test of the language extension mechanism. - ask -- ask bjoern hansen, http://ask.netcetera.dk/ !try; do();
Re: Parsing perl 5 with perl 6 (was Re: Larry's Apocalypse 1)
On Mon, Apr 16, 2001 at 02:49:07PM -0500, Jarkko Hietaniemi wrote: I don't get it. The first and foremost duty of Perl 6 is to parse and execute Perl 6. If it doesn't, it's not Perl 6. I will call this the Prime Directive. Great, but don't loose sight of the fact that a key feature of "Perl 6", as far as Larry's sketched it out, is the ability to dynamically alter the parser in both dramatic and subtle ways. Following your lead, I will call this the Prime Language Feature :) People seem to think that telling Perl 5 apart from Perl 6 is trivial. My reading of Larry's comments is that it will be _made_ trivial at the file scope level. If the file doesn't start with Perl 6 thingy then it's Perl 5. Period. Truly detecting Perl5ness is hard: you will have to in essence replicate the Perl 5 parsing, and we all know the amount of hair in that code. We really want to include such a hairball in our new beautiful code? My reading of Larry's comments is that it won't be "in" our ``new beautiful code''? [Umm, pride before a fall?] That beautiful code will be beautifully _open_ to _external_ extensions. And that is how I imagine that Perl 5 support should be implemented. The parser is, ooops, the parsers are (plural) going to be in perl, remember. Thinking about the 5-6 migration and coexistence is good and useful, but since that doesn't advance the Prime Directive, I disagree. thinking about it *too* much now or fighting over the niggly details is somewhat wasted effort. Now this I agree with. It's quite staggering how much hot air has been generated from Larry's first significant outline. Much of it missing, or casually disregarding, key points of deep or subtle meaning. I'm reminded of the long threads about bignum support that seemed to be lost in the details of _a_ bignum implementation rather than focusing on the design of a generic type extension mechanism that would then enable multiple bignum implementations to coexist. Tim.
Re: Parsing perl 5 with perl 6 (was Re: Larry's Apocalypse 1)
Tim Bunce wrote: If the file doesn't start with Perl 6 thingy then it's Perl 5. Period. To mandate the impossible is to mandate failure. "Nothing can parse perl like Perl." Why is that? My reading of Larry's comments is that it won't be "in" our "new beautiful code". [Umm, pride before a fall?] I'd say yes... but whose pride, really? And whose fall? the parsers are going to be in perl, remember. Sorry, Tim, I must have missed that. Reference, please? It's quite staggering how much hot air has been generated from Larry's first significant outline. Much of it missing, or casually disregarding, key points of deep or subtle meaning. Lofty ideals often must make way for practical realities. -- John Porter Any technology distinguishable from magic is insufficiently advanced.
Re: Parsing perl 5 with perl 6 (was Re: Larry's Apocalypse 1)
On Tue, Apr 17, 2001 at 09:23:56AM -0400, John Porter wrote: "Nothing can parse perl like Perl." Just saying it doesn't make it true, you know. -- Keep the number of passes in a compiler to a minimum. -- D. Gries
Re: Parsing perl 5 with perl 6 (was Re: Larry's Apocalypse 1)
Dan Sugalski writes: : At 10:16 AM 4/17/2001 +0100, Tim Bunce wrote: : On Mon, Apr 16, 2001 at 02:49:07PM -0500, Jarkko Hietaniemi wrote: : People seem to think that telling Perl 5 apart from Perl 6 is trivial. : : My reading of Larry's comments is that it will be _made_ trivial at the : file scope level. If the file doesn't start with Perl 6 thingy then : it's Perl 5. Period. : : I think you (and we) are reading too much into the comments around this. : They're all in the "RFC 16: Keep default Perl free of constraints such as : warnings and strict" section. I've been reading them as setting perl's : default warning and stricture levels, but that's not necessarily the intent. Well, it was in A1 because it addressed large issues, some of which I punted on. In particular, the degree of stricture in the main program when we know it's Perl 6. : As for default perl 5-ishness, while there's language that says we assume : perl 5, there's also a paragraph in there that says having to declare we're : really perl 6 sucks, too. I think it's going to turn out pretty easy to distinguish Perl 5 from Perl 6 (the standard dialect). Consider that in Perl 6, modules might not be imported with "use". Instead, they will might well be declared with "my" and "our" to indicate whether you want the module definition to be scoped to your current package or your current lexical scope. So a Perl 6 program that wanted to invoke the "bad" pragma might start out: my bad; :-) We know the use syntax has to change anyway to deal better with versioning and aliasing, so we might as well break it correctly. We may end up with aliased modules looking like this: my http is Foo::Bar::Http:GSAR:3.0.1 args... As for what we currently do with "use", I'm not sure the exact syntax yet, but since "use" currently imports ordinary modules to the package space, the p526 translator might turn non-pragmas into some kind of an "our" declaration. Anyway, just some more ballistic ideas to randomize all your eyeballs. Larry
Re: Parsing perl 5 with perl 6 (was Re: Larry's Apocalypse 1)
On Tue, Apr 17, 2001 at 09:23:56AM -0400, John Porter wrote: Tim Bunce wrote: If the file doesn't start with Perl 6 thingy then it's Perl 5. Period. To mandate the impossible is to mandate failure. "Nothing can parse perl like Perl." Why is that? Because perl has a bunch of special conditions/extensions. And of course I wouldn't expect any first generation of perl6 to handle them correctly. But second generations, third generations should be able to handle them effectively. The goal would be to make the multi-parserness of perl6 as robust as possible. And we've got the biggest regression test for this as we could possibly imagine: most CPAN modules have inbuilt regression tests that could be used to see how well the perl6-perl5 translation is doing. the parsers are going to be in perl, remember. Sorry, Tim, I must have missed that. Reference, please? I remember Larry saying that too. I would say it with a caveat, though - I would make the 'parser' perl(5 at first) that generates C and that was usable both to compile perl and to use in perl6. That way you could say: load python-syntax; in the front of your scripts as pragma, where 'python-syntax' is a perl module that first time round, or on changes, generates c, autocompiles itself, and loads itself like XS does currently. And you could use the same method inside of perl to do the internal perl5/perl6 switch - a function could return the syntax in a given code block used (perl5 or perl6) and then pass the text to the appropriate parser (which could theoretically follow the same autocompile/autoload rules up above). Having two mechanisms to do this - one parser to handle the 'parse perl' case and another to handle the 'add additional syntax' case is not what we want in perl6 IMO. But that's exactly what we have right now - byacc generated source for perl, and a perl5 module Parse::RecDescent, to use in perl scripts. And anybody who uses both byacc and Parse::RecDescent knows which one is the easier to use, by an order of magnitude. Ed
Re: Parsing perl 5 with perl 6 (was Re: Larry's Apocalypse 1)
On Mon, Apr 16, 2001 at 12:11:41PM -0400, Dan Sugalski wrote: I hereby declare that a package declaration at the front of a file unambiguously indicates you are parsing Perl 5 code. ^^^ Grand. To play devil's advocate here for a moment, that doesn't mean that perl 6 will parse *cough* -- "The Write Many, Read Never drive. For those people that don't know their system has a /dev/null already." - Rik Steenwinkel on Exabyte drives, ASR
Re: Parsing perl 5 with perl 6 (was Re: Larry's Apocalypse 1)
At 05:20 PM 4/16/2001 +0100, Simon Cozens wrote: On Mon, Apr 16, 2001 at 12:11:41PM -0400, Dan Sugalski wrote: I hereby declare that a package declaration at the front of a file unambiguously indicates you are parsing Perl 5 code. ^^^ Grand. To play devil's advocate here for a moment, that doesn't mean that perl 6 will parse *cough* s/parse/interpret/; Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Parsing perl 5 with perl 6 (was Re: Larry's Apocalypse 1)
On Mon, Apr 16, 2001 at 12:25:15PM -0400, Dan Sugalski wrote: *cough* s/parse/interpret/; Seems a bit of a shame to parse it and then not do anything with it, especially if we're trying to push Perl 6 as a common language runtime for running all sorts of bytecode-compiled languages. :) -- BASH is great, it dumps core and has clear documentation. -Ari Suntioinen
Re: Parsing perl 5 with perl 6 (was Re: Larry's Apocalypse 1)
At 12:11 PM 4/16/01 -0400, Dan Sugalski wrote: There are a number of reasons to *not* claim to parse perl 5 code. *) We won't load any perl 5 XS code *) We won't be getting the corner cases, and perl5 has a *lot*. *) It complicates the interpreter if we need to add code to support things that perl 6 doesn't do. (*ocugh*typegobs*cough*) *) It makes the parser that much more work to write. Even if we switch parser code entirely when going from perl 5 to perl 6 and back, someone still has to write the code in the first place. *) It's even more complexity, which is just that much more stuff we can potentially break *) It sets up the expectation (rightly so, IMNSHO) in the user community that we eat and process all perl 5 code correctly, and we just aren't going to. Despite our best efforts we're not going to. As a very low-tech solution, why not bundle perl 5 *with* perl 6 so that once perl 6 detects that it's been fed perl 5 code, it can send it to the perl 5 compiler/interpreter. Yeah, I know it makes the resulting bundle huge, but at least it separates the tasks of parsing perl5 and perl 6 into independent projects. -- Peter Scott Pacific Systems Design Technologies
Re: Parsing perl 5 with perl 6 (was Re: Larry's Apocalypse 1)
At 09:47 AM 4/16/2001 -0700, Peter Scott wrote: At 12:11 PM 4/16/01 -0400, Dan Sugalski wrote: There are a number of reasons to *not* claim to parse perl 5 code. *) We won't load any perl 5 XS code *) We won't be getting the corner cases, and perl5 has a *lot*. *) It complicates the interpreter if we need to add code to support things that perl 6 doesn't do. (*ocugh*typegobs*cough*) *) It makes the parser that much more work to write. Even if we switch parser code entirely when going from perl 5 to perl 6 and back, someone still has to write the code in the first place. *) It's even more complexity, which is just that much more stuff we can potentially break *) It sets up the expectation (rightly so, IMNSHO) in the user community that we eat and process all perl 5 code correctly, and we just aren't going to. Despite our best efforts we're not going to. As a very low-tech solution, why not bundle perl 5 *with* perl 6 so that once perl 6 detects that it's been fed perl 5 code, it can send it to the perl 5 compiler/interpreter. Besides the size and clunkiness issues, there's another problem. String evals in a perl 5 section of code will expect to be parsed as perl 5, which kinda precludes the whole "compile perl 5 to bytecode and pass it through the p526 converter" solution. Makes mixing and matching perl5 and perl 6 code rather more difficult. :( Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Parsing perl 5 with perl 6 (was Re: Larry's Apocalypse 1)
At 02:33 PM 4/16/01 -0400, Dan Sugalski wrote: At 09:47 AM 4/16/2001 -0700, Peter Scott wrote: As a very low-tech solution, why not bundle perl 5 *with* perl 6 so that once perl 6 detects that it's been fed perl 5 code, it can send it to the perl 5 compiler/interpreter. Besides the size and clunkiness issues, there's another problem. String evals in a perl 5 section of code will expect to be parsed as perl 5, which kinda precludes the whole "compile perl 5 to bytecode and pass it through the p526 converter" solution. Makes mixing and matching perl5 and perl 6 code rather more difficult. :( Er, I don't get it. I'm proposing that if perl 6 determines it's been given perl 5 code, it does "exec perl5 $0". So thereafter it's as though perl 6 never existed as far as that code is concerned; whatever it wants to do should be completely independent of any perl 6 code. I'm bypassing the "compile perl 5 to bytecode and pass it through the p526 converter" solution. I have my doubts as to how well that's going to work with things like XS anyway. Or were you espousing the notion that perl 6 programs should be able to contain sections of perl 5 code? That gives me strange palpitations. -- Peter Scott Pacific Systems Design Technologies
Re: Parsing perl 5 with perl 6 (was Re: Larry's Apocalypse 1)
At 12:19 PM 4/16/2001 -0700, Peter Scott wrote: Or were you espousing the notion that perl 6 programs should be able to contain sections of perl 5 code? That gives me strange palpitations. This is what I've been arguing against. Unless I misunderstand (and it wouldn't be the first time... :) this is what some folks are arguing for, and I very much don't want to go there. Not with perl 6.0.x, at least. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: Parsing perl 5 with perl 6 (was Re: Larry's Apocalypse 1)
Dan Sugalski wrote At 12:19 PM 4/16/2001 -0700, Peter Scott wrote: Or were you espousing the notion that perl 6 programs should be able to contain sections of perl 5 code? That gives me strange palpitations. This is what I've been arguing against. Unless I misunderstand (and it wouldn't be the first time... :) this is what some folks are arguing for, and I very much don't want to go there. Not with perl 6.0.x, at least. But remember the libraries. Do we really want to rewrite all the modules on CPAN? I think the reason for mixing is that it should be possible to use a Perl5 library module with Perl6. And that opens all those cans of worms. We are going to have a mechanism to interface with multiple languages via an upgrated C interface mechanism. Can we find a mechanism for interfacing to Perl (5)? Dave. -- Dave Whipp, Senior Verification Engineer, Fast-Chip inc., 950 Kifer Rd, Sunnyvale, CA. 94086 tel: 408 523 8071; http://www.fast-chip.com Opinions my own; statements of fact may be in error.
Re: Parsing perl 5 with perl 6 (was Re: Larry's Apocalypse 1)
I don't get it. The first and foremost duty of Perl 6 is to parse and execute Perl 6. If it doesn't, it's not Perl 6. I will call this the Prime Directive. I think as the first approximation the implementation of Perl 6 should get that "simple" task right. If it doesn't, all our talk and work has been for nothing and we have failed. People seem to think that telling Perl 5 apart from Perl 6 is trivial. In certain special cases, yes, such as the "module"/"class" versus "package" distinction described by Larry, but in the general case that is not not going to be easy, for example when the difference is more syntatical. Some Perl 5 things will by syntax errors in Perl 6, and vice versa. Truly detecting Perl5ness is hard: you will have to in essence replicate the Perl 5 parsing, and we all know the amount of hair in that code. We really want to include such a hairball in our new beautiful code? Thinking about the 5-6 migration and coexistence is good and useful, but since that doesn't advance the Prime Directive, thinking about it *too* much now or fighting over the niggly details is somewhat wasted effort. -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: Parsing perl 5 with perl 6 (was Re: Larry's Apocalypse 1)
At 02:49 PM 4/16/2001 -0500, Jarkko Hietaniemi wrote: Thinking about the 5-6 migration and coexistence is good and useful, but since that doesn't advance the Prime Directive, thinking about it *too* much now or fighting over the niggly details is somewhat wasted effort. We have been stuck in a sort of Gilbert and Sullivan debate, haven't we? Silly, definitely silly. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Parsing perl 5 with perl 6 (was Re: Larry's Apocalypse 1)
"DS" == Dan Sugalski [EMAIL PROTECTED] writes: DS We have been stuck in a sort of Gilbert and Sullivan debate, DS haven't we? Silly, definitely silly. o/' perl6 is the very model of a modern major interpreter o/' :-) uri -- Uri Guttman - [EMAIL PROTECTED] -- http://www.sysarch.com SYStems ARCHitecture and Stem Development -- http://www.stemsystems.com Learn Advanced Object Oriented Perl from Damian Conway - Boston, July 10-11 Class and Registration info: http://www.sysarch.com/perl/OOP_class.html
Re: Parsing perl 5 with perl 6 (was Re: Larry's Apocalypse 1)
On Mon, Apr 16, 2001 at 12:19:38PM -0700, Peter Scott wrote: Er, I don't get it. I'm proposing that if perl 6 determines it's been given perl 5 code, it does "exec perl5 $0". So thereafter it's as though perl 6 never existed as far as that code is concerned; whatever it wants to do should be completely independent of any perl 6 code. So ... when a "perl6" program uses a "perl5" library, what happens? If we go with Larry's rule that a package declaration unambiguously says you're parsing perl 5, then this situation WILL exist. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
