Re: RFCs (Re: Ideas that need RFCs?)
David L. Nicol wrote: > > RFC: It's all exception handling. I imagine the core syntax description > as a set of catch clauses. Every token generates a "TOKEN-$whatever" > exception, which is caught according to the current situation. How's > that for a general paradigm? These things can be overloaded as needed to > implement Macros, variant syntaces, variant semantics, and so on. "All flow control will implemented as longjumps." -- John Porter
Re: RFCs (Re: Ideas that need RFCs?)
"Bryan C. Warnock" wrote: > > On Fri, 18 Aug 2000, David L. Nicol wrote: > > There will Be No Perl7 > > Of course not. Odd numbers are the development releases. The next > Perl after 6 will be 8. So maybe the reference implementation should be written in perl 4. Did perl 4 have references? Doing all codrefs in terms of eval'ing strings would be a PITA. > Seriously, while a worthwhile goal, this is rather short-sighted. > The industry and the world will continue to change in spite (or > because!) of our efforts here. We can make it easier for the users to > adapt, but Perl will need to continue to evolve, as well. So we write in full access to internals, and capable macro and redefining languages, making perl6 a framework you can build anything into even easier than perl5 is a framework you can build anything in to. Perl5 was the experimentation period for threading and OO syntaces, now we've played with them for a while, we can write in programmatic access to on-the-fly parser modification and then the language becomes customary. Further releases of the standard would be modifications to the parser rules or the clarification engine, rather than rewrites. Language = Framework + Parser-rules + Clarification-engine Parser-rules can be rewritten with certain reserved macros, allowing use intercal2000; to cause the remainder of the program to be interpreted as intercal, for instance, And if the Clarification-engine is aware of everything that is not explicitly hidden from it, or if it can be pulled out and completely replaced, that not only makes translating into different languages a real breeze, it allows subroutines to be genuinely on the same footing as builtins, instead of just seeming that way. -- David Nicol 816.235.1187 [EMAIL PROTECTED] Does despair.com sell a discordian calendar?
Re: RFCs (Re: Ideas that need RFCs?)
On Fri, Aug 18, 2000 at 05:22:17PM -0500, David L. Nicol wrote: >RFC: Perl6 is Final. There will Be No Perl7 >RFC: Everything is Accessible and Mutable >RFC: The perl6 reference implementation, no matter how slow it is, >will be written in perl5, in some kind of well defined virtual machine. >RFC: It's all exception handling. >RFC: Implemnentation: Unified containers are trees of storage nodes, >and we do our own memory management with them >RFC: Garbage collection: We keep reference counting, with a big >node pool, occasionally defragment it if we can, to free the top of it. Almost all of these are internals fodder, not language topics. David, could you re-post this list to -internals and take discussion over there, please? K. -- Kirrily Robert -- <[EMAIL PROTECTED]> -- http://netizen.com.au/ Open Source development, consulting and solutions Level 10, 500 Collins St, Melbourne VIC 3000 Phone: +61 3 9614 0949 Fax: +61 3 9614 0948 Mobile: +61 410 664 994
Re: RFCs (Re: Ideas that need RFCs?)
Nathan Torkington wrote: > > David L. Nicol writes: > > RFC: Perl6 is Final. There will Be No Perl7 > > > > We declare that our framework willbe so flexiblke > > that anything can be done with it and there will be no penalty > > for something being in-core opposed to out-of-core and so on. > > Bad idea. You can't make anything infinitely customizable without > making it an infinitely slow bitch. Genericity costs. I say we make > the best perl6 we can, and let the inevitable perl7 take care of > itself. I think David's point is that C and several other languages have standardized on a syntax and common development/library model. It's not perfect, but it's stable. >From this standpoint, I think it's a very worthwhile goal. Every Perl release can't require a massive relearning and rewriting of the language. Perl 6 is sort of our "last chance" to change major interface stuff. Adding new features is a different issue. Obviously subsequent releases will continue to evolve. But I do think this is the last one where we can literally "take the gloves off" and redo everything. Otherwise, Perl will get a really bad reputation for being unstable, and it will deserve it. Perl 5 is already very stable externally, so any big user-visible changes will have to be obviously worthwhile in Perl 6. Most users won't tolerate Perl 7, 8, 9, and 10 continuing to break all their past scripts except minorly (I know I won't). This is definitely one aspect of "making things easy" that's a very important one. Especially as the number of Perl programs continues to explode exponentially. -Nate
Re: RFCs (Re: Ideas that need RFCs?)
Nathan Wiger writes:
> Anyone RFC'ing this yet?
I could RFC it in vague terms, but I'm waiting to see how things
like interfaces turn out.
> Which reminds, anyone gonna RFC the rumored death of typeglobs? :-)
I figured that as Larry had used it as an example of things that were
up for grabs in perl6, he was already assumed to be thinking of it.
Then again, if the RFC actually thought through the current uses of
typeglobs and could show how to preserve that functionality, it
would be useful.
It's always the edge cases that need thinking through. Any idiot (hi,
that's me!) can RFC the obvious ("write lvalue subs so that they're
passed the rvalue") but it's the edge cases ("and what about mutators
and other non-assignment lvalues, fool?") that require the thought
and are what make a great RFC (Damian's) not a crappy one (mine).
Nat
Re: RFCs (Re: Ideas that need RFCs?)
Nathan Torkington wrote: > > Exporter is pure Perl, but > I'd love to see its functionality moved into the core (or, indeed, > replaced by a general compile-time interface setup with separate > runtime execution semantics) for speed reasons. Anyone RFC'ing this yet? This time I'm *not* volunteering, but just pointing out one that could be missed. Seems like this has lots of dependencies on what happens with lexical/dynamic variables, symbol tables and typeglobs. Which reminds, anyone gonna RFC the rumored death of typeglobs? :-) -Nate
Re: RFCs (Re: Ideas that need RFCs?)
Jeremy Howard wrote: > > > Steve Fink writes: > > > And both those examples apply to the underpinnings. Ok, maybe I have an > > > unusually broad definition of the word "underpinnings". Think "anything > > > that can't be done with a pure perl module". > > > Say "anything that can't be done *fast*enough* with a pure perl module" and > you're closer. Right. What he said. Or maybe add "cleanly enough" too. And "easily enough". Or maybe just "anything that wouldn't be better done as a pure perl module." After all, we're shooting for better than "easy things possible, hard things barely possible."
Re: RFCs (Re: Ideas that need RFCs?)
> Steve Fink writes: > > And both those examples apply to the underpinnings. Ok, maybe I have an > > unusually broad definition of the word "underpinnings". Think "anything > > that can't be done with a pure perl module". > Say "anything that can't be done *fast*enough* with a pure perl module" and you're closer. For instance, many issues discussed on perl6-language-data are already doable with a pure Perl module, but not efficiently enough for data crunching. The trick here is to find the minimal core language and implementation changes required to support pure Perl versions of the majority of the language needs.
Re: RFCs (Re: Ideas that need RFCs?)
On Fri, 18 Aug 2000, David L. Nicol wrote: > There will Be No Perl7 Of course not. Odd numbers are the development releases. The next Perl after 6 will be 8. Seriously, while a worthwhile goal, this is rather short-sighted. The industry and the world will continue to change in spite (or because!) of our efforts here. We can make it easier for the users to adapt, but Perl will need to continue to evolve, as well. (As spoken by a one-eyebrow, knuckle-dragging Neanderthal) -- Bryan C. Warnock ([EMAIL PROTECTED])
Re: RFCs (Re: Ideas that need RFCs?)
Steve Fink writes: > And both those examples apply to the underpinnings. Ok, maybe I have an > unusually broad definition of the word "underpinnings". Think "anything > that can't be done with a pure perl module". I'm not wild about that metric, either. Exporter is pure Perl, but I'd love to see its functionality moved into the core (or, indeed, replaced by a general compile-time interface setup with separate runtime execution semantics) for speed reasons. > My message was *encouraging* RFCs And once again we're in violent agreement :-) Sorry for any confusion, Nat
Re: RFCs (Re: Ideas that need RFCs?)
David L. Nicol writes: > RFC: Perl6 is Final. There will Be No Perl7 > > We declare that our framework willbe so flexiblke > that anything can be done with it and there will be no penalty > for something being in-core opposed to out-of-core and so on. Bad idea. You can't make anything infinitely customizable without making it an infinitely slow bitch. Genericity costs. I say we make the best perl6 we can, and let the inevitable perl7 take care of itself. Of course we don't want to be too locked in, but neither do we want to be too flexible (IMHO). This is, of course, inherent in the word "too". > RFC: The perl6 reference implementation, no matter how slow it is, > will be written in perl5, in some kind of well defined virtual machine. > It should be possible do Data::Dumper out a emulated perl6 instance > and load it into another and there you are, except the file handles > are all confused (unless you've got a way-fancy OS that can cope with > such things) Aye aye aye. I'd like to see proposed language features prototyped or emulated in perl5. But I'm unconvinced that implementing perl6 first in perl5 is going to win us much more than a big delay. You're going to find correct threading and signals hard to emulate on a system with broken threading and signals, though. > RFC: It's all exception handling. I imagine the core syntax description > as a set of catch clauses. Every token generates a "TOKEN-$whatever" > exception, which is caught according to the current situation. How's > that for a general paradigm? These things can be overloaded as needed to > implement Macros, variant syntaces, variant semantics, and so on. My first reaction is "wouldn't that be slow?" Nat
Re: RFCs (Re: Ideas that need RFCs?)
Here's my RFC todo list which I am dropping like a good mensch on the occasion of Friday Evening. RFC: Perl6 is Final. There will Be No Perl7 We declare that our framework willbe so flexiblke that anything can be done with it and there will be no penalty for something being in-core opposed to out-of-core and so on. RFC: Everything is Accessible and Mutable From tokenizing up. See below for how to pull this off. At least, the core core core of what's left is just a smidgen larger than FORTH. Like, FORTH plus data structures plus exceptions plus garbage collection. RFC: The perl6 reference implementation, no matter how slow it is, will be written in perl5, in some kind of well defined virtual machine. It should be possible do Data::Dumper out a emulated perl6 instance and load it into another and there you are, except the file handles are all confused (unless you've got a way-fancy OS that can cope with such things) RFC: It's all exception handling. I imagine the core syntax description as a set of catch clauses. Every token generates a "TOKEN-$whatever" exception, which is caught according to the current situation. How's that for a general paradigm? These things can be overloaded as needed to implement Macros, variant syntaces, variant semantics, and so on. RFC: Implemnentation: Unified containers are trees of storage nodes, and we do our own memory management with them RFC: Garbage collection: We keep reference counting, with a big node pool, occasionally defragment it if we can, to free the top of it. Have a nice weekend. Nathan Torkington wrote: > > Steve Fink writes: > > We are NOT here to construct a radically better language. We are here to > > design the underpinnings of one. > > Perhaps. And by "perhaps", I mean "no". > > We're here to say what we'd like to see in the next version of Perl. > These can be big things (currying) or small (hashes returned by > functions instead of long lists). We're giving input to Larry, who > will then design the language. We are just telling Larry what we > would like, and why (i.e., which itch it would scratch). > > > If you have an idea that will "add value" to Perl6 but can just as > > well be done after the groundwork for the language has been laid > > out, then please do not write up an RFC on it. It'll just distract. > > I completely disagree. If you want something in Perl, now's the time > to ask. We're going to have to nail down the language so people can > begin writing grammars, data structures, regex engines, and so on. > There's no such thing as a small change if that change comes *after* > people have begun coding. That's called "feature creep", as I'm sure > you know. > > So I want to encourage people to submit RFCs. Yes, there are a lot of > them. That's Larry's problem, not ours. It's one problem he's glad > to have, I'm sure. > > Nat -- David Nicol 816.235.1187 [EMAIL PROTECTED] Does despair.com sell a discordian calendar?
Re: RFCs (Re: Ideas that need RFCs?)
Nathan Torkington wrote: > > Steve Fink writes: > > We are NOT here to construct a radically better language. We are here to > > design the underpinnings of one. > > Perhaps. And by "perhaps", I mean "no". > > We're here to say what we'd like to see in the next version of Perl. > These can be big things (currying) or small (hashes returned by > functions instead of long lists). We're giving input to Larry, who > will then design the language. We are just telling Larry what we > would like, and why (i.e., which itch it would scratch). And both those examples apply to the underpinnings. Ok, maybe I have an unusually broad definition of the word "underpinnings". Think "anything that can't be done with a pure perl module". > > If you have an idea that will "add value" to Perl6 but can just as > > well be done after the groundwork for the language has been laid > > out, then please do not write up an RFC on it. It'll just distract. > > I completely disagree. If you want something in Perl, now's the time > to ask. We're going to have to nail down the language so people can > begin writing grammars, data structures, regex engines, and so on. > There's no such thing as a small change if that change comes *after* > people have begun coding. That's called "feature creep", as I'm sure > you know. Which is why I wrote the rest of that paragraph, saying that people should write RFCs for anything that requires, or might require, changes in the Perl6 language. My message was *encouraging* RFCs; I was disagreeing with a message discouraging them. You happened to quote the two sentences where I was agreeing that not all RFCs need to be brought up just now, if the change they propose would still be possible after the Perl6 core was set in stone (namely, you could just write a module to do that using "existing" primitives at no significant loss in performance or clarity. Which usually implies that you could do it today in Perl5, but nobody's bothered to.) > So I want to encourage people to submit RFCs. Yes, there are a lot of > them. That's Larry's problem, not ours. It's one problem he's glad > to have, I'm sure. I agree. At least, to the extent possible without having Larry's brain sitting in front of me in a jar, and I'm pretty sure this one is somebody else's.
Re: RFCs (Re: Ideas that need RFCs?)
Nathan Torkington writes: : Steve Fink writes: : > We are NOT here to construct a radically better language. We are here to : > design the underpinnings of one. : : Perhaps. And by "perhaps", I mean "no". : : We're here to say what we'd like to see in the next version of Perl. : These can be big things (currying) or small (hashes returned by : functions instead of long lists). We're giving input to Larry, who : will then design the language. We are just telling Larry what we : would like, and why (i.e., which itch it would scratch). And my current role is to turn everybody's view upside-down by pointing out that currying is a small thing if you have the right hooks between the lexer and the parser, while returning hashes instead of long lists is a big thing if it implies the unification of object and hash notations. How exactly do you "slice" an object, currently? : > If you have an idea that will "add value" to Perl6 but can just as : > well be done after the groundwork for the language has been laid : > out, then please do not write up an RFC on it. It'll just distract. : : I completely disagree. If you want something in Perl, now's the time : to ask. We're going to have to nail down the language so people can : begin writing grammars, data structures, regex engines, and so on. : There's no such thing as a small change if that change comes *after* : people have begun coding. That's called "feature creep", as I'm sure : you know. I don't mind "small" RFCs. I expect some number of them will be end up being classified as: "Should be implemented in terms of X later." But that doesn't mean they don't encode real desires. : So I want to encourage people to submit RFCs. Yes, there are a lot of : them. That's Larry's problem, not ours. It's one problem he's glad : to have, I'm sure. Number 5 is alive! Not disassemble! Need more input! Larry
RFCs (Re: Ideas that need RFCs?)
Steve Fink writes: > We are NOT here to construct a radically better language. We are here to > design the underpinnings of one. Perhaps. And by "perhaps", I mean "no". We're here to say what we'd like to see in the next version of Perl. These can be big things (currying) or small (hashes returned by functions instead of long lists). We're giving input to Larry, who will then design the language. We are just telling Larry what we would like, and why (i.e., which itch it would scratch). > If you have an idea that will "add value" to Perl6 but can just as > well be done after the groundwork for the language has been laid > out, then please do not write up an RFC on it. It'll just distract. I completely disagree. If you want something in Perl, now's the time to ask. We're going to have to nail down the language so people can begin writing grammars, data structures, regex engines, and so on. There's no such thing as a small change if that change comes *after* people have begun coding. That's called "feature creep", as I'm sure you know. So I want to encourage people to submit RFCs. Yes, there are a lot of them. That's Larry's problem, not ours. It's one problem he's glad to have, I'm sure. Nat
