Re: What will the Perl6 code name be?

> Jerrad Pierce wrote: > > > > What about Hexane? Arthropod (or some insect)? > > Hmmm "anthracite" ? Hi there, i think it should have a meaning, s.th. like pool would be nice with the meaning: perl object-oriented language ;-) - gph - -- Gerrit Peter Haase

Re: What will the Perl6 code name be?

>> > What about Hexane? Arthropod (or some insect)? These do habve meaning, Hexane is a six carbon hydocarbon. Anthropods(esp. insects) have six legs... >perl object-oriented language horrible! a) you're using an acronym within an acronym: Practical Extraction and Report Language Object-

RE: renaming local to "hold"

From: David L. Nicol [mailto:[EMAIL PROTECTED]] > > I think pitching renames for "local" is at least as worthwhile > as pitching code names. How about "Hold?" It isn't listed in > Blackstone's RFC 19, and it focuses on the restore-later > aspects -- put that variable on hold, like it is a phon

RE: renaming local to "hold"

How about: scratch #doesn't really imply what it's doing overload#accurate, kinda long though some might say this is good dup/duplicate #nasty for the compiler, and perhaps for the newbies, #but dup'ing var's makes sense, esp. from the C stance clone/mycopy

Re: What will the Perl6 code name be?

Hi Jerrad, > >> > What about Hexane? Arthropod (or some insect)? > These do habve meaning, Hexane is a six carbon hydocarbon. > Anthropods(esp. insects) have six legs... > > >perl object-oriented language > horrible! > > a) you're using an acronym within an acronym: > Practical Extraction and

Re: What will the Perl6 code name be?

On Mon, Oct 23, 2000 at 07:44:15PM +0200, Gerrit Haase wrote: > Perl, which allows object oriented syntax, written in C++ language, ^^ Did I miss something, or did the world go *totally* gaga overnight? -- It's all fun and games until som

Re: What will the Perl6 code name be?

At 07:37 PM 10/23/00 +0100, Simon Cozens wrote: >On Mon, Oct 23, 2000 at 07:44:15PM +0200, Gerrit Haase wrote: > > Perl, which allows object oriented syntax, written in C++ language, > ^^ >Did I miss something, or did the world go *totally*

Re: What will the Perl6 code name be?

On Mon, Oct 23, 2000 at 02:39:14PM -0400, Dan Sugalski wrote: > Got me. I'd planned on us writing perl 6 in INTERCAL. PLEASE LET'S NOT GO THAT WAY Incidentally, and just to try and raise the tone a little, are we planning on compiling Perl 6 programs to native binaries? -- These days, if

Re: What will the Perl6 code name be?

>> Perl, which allows object oriented syntax, written in C++ language, ^^ >Did I miss something, or did the world go *totally* gaga overnight? I think he's referring to Topaz. All together now: Topaz is dead, Topaz never was (public). --

Re: What will the Perl6 code name be?

At 07:47 PM 10/23/00 +0100, Simon Cozens wrote: >On Mon, Oct 23, 2000 at 02:39:14PM -0400, Dan Sugalski wrote: > > Got me. I'd planned on us writing perl 6 in INTERCAL. > > PLEASE LET'S NOT GO THAT WAY A... you're no fun! :) >Incidentally, and just to try and raise the tone a little, are

Re: What will the Perl6 code name be?

On Mon, Oct 23, 2000 at 02:51:40PM -0400, Dan Sugalski wrote: > > PLEASE LET'S NOT GO THAT WAY > A... you're no fun! :) I am, but nurse says I'm not allowed to write INTERCAL any more. > That is one of the scenarios. There are some issues with it for a project > like this--spitting out

Re: What will the Perl6 code name be?

At 08:18 PM 10/23/00 +0100, Simon Cozens wrote: >On Mon, Oct 23, 2000 at 02:51:40PM -0400, Dan Sugalski wrote: > > > PLEASE LET'S NOT GO THAT WAY > > A... you're no fun! :) > >I am, but nurse says I'm not allowed to write INTERCAL any more. Well, maybe we can do it in befunge instead. >

Re: What will the Perl6 code name be?

On Mon, Oct 23, 2000 at 03:37:02PM -0400, Dan Sugalski wrote: > Well, maybe we can do it in befunge instead. +!+!@@!!! > Oh, without a doubt. I'd actually like to get things building such that the > four main modules--parser, bytecode compiler, optimizer, and execution > engine--are in separat

Re: What will the Perl6 code name be?

Dan Sugalski wrote: > > Well, maybe we can do it in befunge instead. No, you're getting confused. We'd like perl at the *user code level* to look like intercal and befunge. (Hmm... wonder what a "come from" operator in befunge would look like...) But we'll probably *implement* perl in Ada, of

Re: What will the Perl6 code name be?

On Mon, Oct 23, 2000 at 04:03:12PM -0400, John Porter wrote: > But we'll probably *implement* perl in Ada, of course. Bzzt. Ada *used* to be the language that made the world turn. We believe that the world-turning program was rewritten in Perl in 1997. -- Thus spake the master programmer:

Perl6 the platform-dependent bits...

From: Dan Sugalski [mailto:[EMAIL PROTECTED]] > (Though if someone comes up with a way to make the > platform-dependent bits really small and isolated I'm all for it) Hmm... I'm 99.9% ignorant on this subject, but doesn't this relate back to past discussions of C--, the portable assembly language

Re: What will the Perl6 code name be?

Simon Cozens wrote: > > We believe that > the world-turning program was rewritten in Perl in 1997. We do? Huh. What else do we believe? -- John Porter

Re: What will the Perl6 code name be?

At 09:01 PM 10/23/00 +0100, Simon Cozens wrote: >On Mon, Oct 23, 2000 at 03:37:02PM -0400, Dan Sugalski wrote: > > Oh, without a doubt. I'd actually like to get things building such that > the > > four main modules--parser, bytecode compiler, optimizer, and execution > > engine--are in separate s

Re: What will the Perl6 code name be?

> "SC" == Simon Cozens <[EMAIL PROTECTED]> writes: SC> Incidentally, and just to try and raise the tone a little, are we SC> planning on compiling Perl 6 programs to native binaries? that was the subject of threaded inline code (my def of TIL but some other acronyms fit that). a cpu/os s

Re: What will the Perl6 code name be?

On Mon, Oct 23, 2000 at 04:38:12PM -0400, Dan Sugalski wrote: > The one thing that just occurred to me is that we're going to need to > support multiple interpreter targets simultaneously. Having the back-end > emit C source isn't going to get those BEGIN blocks very far. :( Don't forget that t

Re: What will the Perl6 code name be?

On Mon, Oct 23, 2000 at 04:51:24PM -0400, Uri Guttman wrote: > only perl op calls in machine code I can't make this make any sense. Could you try again? -- And it should be the law: If you use the word `paradigm' without knowing what the dictionary says it means, you go to jail. No exceptions.

TIL redux (was Re: What will the Perl6 code name be?)

> "SC" == Simon Cozens <[EMAIL PROTECTED]> writes: SC> On Mon, Oct 23, 2000 at 04:51:24PM -0400, Uri Guttman wrote: >> only perl op calls in machine code SC> I can't make this make any sense. Could you try again? well, you should have been on the lists when this was being hammered aro

Re: TIL redux (was Re: What will the Perl6 code name be?)

On Mon, Oct 23, 2000 at 05:18:15PM -0400, Uri Guttman wrote: > > "SC" == Simon Cozens <[EMAIL PROTECTED]> writes: > SC> I can't make this make any sense. Could you try again? > > well, you should have been on the lists when this was being hammered > around. OK. I don't remember this bein

Re: What will the Perl6 code name be?

At 09:54 PM 10/23/00 +0100, Simon Cozens wrote: >On Mon, Oct 23, 2000 at 04:38:12PM -0400, Dan Sugalski wrote: > > The one thing that just occurred to me is that we're going to need to > > support multiple interpreter targets simultaneously. Having the back-end > > emit C source isn't going to get

Re: What will the Perl6 code name be?

On Mon, Oct 23, 2000 at 03:40:26PM -0700, Peter Scott wrote: > >Don't forget that those BEGIN blocks are *supposed* to be instructions > >to the compiler. > > Er, but a lot of people seem to use them for other things :-) Then they're going to have a shock. This isn't Perl 5 any more, Toto. > Wh

Re: TIL redux (was Re: What will the Perl6 code name be?)

On Mon, Oct 23, 2000 at 05:18:15PM -0400, Uri Guttman wrote: > basically the emitted machine code for TIL is very simplified C > routine calls and their argument setup and return. all the routine calls > are to perl ops with just the minimal stack glue code in between them. OK, you're re-inventin

Re: TIL redux (was Re: What will the Perl6 code name be?)

At 12:48 AM 10/24/00 +0100, Simon Cozens wrote: >On Mon, Oct 23, 2000 at 05:18:15PM -0400, Uri Guttman wrote: > > basically the emitted machine code for TIL is very simplified C > > routine calls and their argument setup and return. all the routine calls > > are to perl ops with just the minimal s

Re: What will the Perl6 code name be?

At 12:33 AM 10/24/00 +0100, Simon Cozens wrote: >On Mon, Oct 23, 2000 at 03:40:26PM -0700, Peter Scott wrote: > > >Don't forget that those BEGIN blocks are *supposed* to be instructions > > >to the compiler. > > > > Er, but a lot of people seem to use them for other things :-) > >Then they're goin

Re: TIL redux (was Re: What will the Perl6 code name be?)

> "SC" == Simon Cozens <[EMAIL PROTECTED]> writes: SC> On Mon, Oct 23, 2000 at 05:18:15PM -0400, Uri Guttman wrote: >> basically the emitted machine code for TIL is very simplified C >> routine calls and their argument setup and return. all the routine calls >> are to perl ops with ju

Re: TIL redux (was Re: What will the Perl6 code name be?)

At 08:33 PM 10/23/00 -0400, Uri Guttman wrote: >as for ziggy's comments on the overload of builtins issue there could be >a simple dispatch table used instead of direct calls. it would be fast >with just an indexed lookup based on the op code id. FWIW, this isn't all that fast. I tried it with pe

Re: TIL redux (was Re: What will the Perl6 code name be?)

> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes: DS> At 12:48 AM 10/24/00 +0100, Simon Cozens wrote: >> On Mon, Oct 23, 2000 at 05:18:15PM -0400, Uri Guttman wrote: >> > basically the emitted machine code for TIL is very simplified C >> > routine calls and their argument setup and r

Re: TIL redux (was Re: What will the Perl6 code name be?)

On Mon, Oct 23, 2000 at 08:33:23PM -0400, Uri Guttman wrote: > so the TIL generated code would still to parameter setup, then an > indirect function call and then result handling. it should still be > faster than an interpreter and simpler to generate than fully compiled > code. Is this actually,

Re: TIL redux (was Re: What will the Perl6 code name be?)

> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes: DS> At 08:33 PM 10/23/00 -0400, Uri Guttman wrote: >> as for ziggy's comments on the overload of builtins issue there could be >> a simple dispatch table used instead of direct calls. it would be fast >> with just an indexed lookup ba

Re: TIL redux (was Re: What will the Perl6 code name be?)

On Mon, Oct 23, 2000 at 08:33:23PM -0400, Uri Guttman wrote: > as for ziggy's comments on the overload of builtins issue there could be > a simple dispatch table used instead of direct calls. I don't think you understand the issue. That's taking great pains to unthread threaded bytecode once yo

Re: TIL redux (was Re: What will the Perl6 code name be?)

At 08:43 PM 10/23/00 -0400, Uri Guttman wrote: > > "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes: > > DS> At 08:33 PM 10/23/00 -0400, Uri Guttman wrote: > >> as for ziggy's comments on the overload of builtins issue there could be > >> a simple dispatch table used instead of direct cal

Re: TIL redux (was Re: What will the Perl6 code name be?)

At 01:38 AM 10/24/00 +0100, Simon Cozens wrote: >On Mon, Oct 23, 2000 at 08:33:23PM -0400, Uri Guttman wrote: > > so the TIL generated code would still to parameter setup, then an > > indirect function call and then result handling. it should still be > > faster than an interpreter and simpler to

Re: TIL redux (was Re: What will the Perl6 code name be?)

> "SC" == Simon Cozens <[EMAIL PROTECTED]> writes: SC> On Mon, Oct 23, 2000 at 08:33:23PM -0400, Uri Guttman wrote: >> so the TIL generated code would still to parameter setup, then an >> indirect function call and then result handling. it should still be >> faster than an interpreter

Re: TIL redux (was Re: What will the Perl6 code name be?)

> "AT" == Adam Turoff <[EMAIL PROTECTED]> writes: AT> I'm with Dan. Make it an optional runtime for everyone who *chooses* AT> to live within the confines of threaded bytecode. It shouldn't be the AT> default runtime model because it is too broken. i never disagreed with not making T

Re: TIL redux (was Re: What will the Perl6 code name be?)

> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes: DS> We can't slow down, no matter what it might buy us. overall i agree. but i use objects much more now and don't think about the runtime cost at all (estimated to be %30). the OO design win for this project makes up for the speed loss.

Re: TIL redux (was Re: What will the Perl6 code name be?)

Uri Guttman <[EMAIL PROTECTED]> writes: > not a good sign but we may need to take the hit to support overloading > any function and supporting TIL and threads. i think a %20 hit to get > those working cleanly might be a decent tradeoff. I don't. I'd find it to be a really good reason to learn P

Re: TIL redux (was Re: What will the Perl6 code name be?)

Uri Guttman writes: > overall i agree. but i use objects much more now and don't think about > the runtime cost at all (estimated to be %30) All the world is not an Uri. I know a company that had to rewrite most of their OO code because it was the bottleneck in their application. The rewrite wa

Re: TIL redux (was Re: What will the Perl6 code name be?)

> "NT" == Nathan Torkington <[EMAIL PROTECTED]> writes: NT> Uri Guttman writes: >> overall i agree. but i use objects much more now and don't think about >> the runtime cost at all (estimated to be %30) NT> All the world is not an Uri. and aren't we all glad about that! :) NT> I

Acceptable speeds (was Re: TIL redux (was Re: What will the Perl6 code name be?))

At 08:26 PM 10/23/00 -0600, Nathan Torkington wrote: >Uri Guttman writes: > > overall i agree. but i use objects much more now and don't think about > > the runtime cost at all (estimated to be %30) > >I know a company that had to rewrite most of their OO code because it >was the bottleneck in the

Re: Acceptable speeds (was Re: TIL redux (was Re: What will the Perl6 code name be?))

> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes: DS> So unless we come up with something concrete, the goals are: DS> 1) A nebulous ~10% faster DS> 2) Faster in the things that annoy Dan the most DS> 3) Faster in the OO bits the folks upstairs from me use 4. faster internal and la

Re: Acceptable speeds (was Re: TIL redux (was Re: What will the Perl6 code name be?))

On Tue, Oct 24, 2000 at 12:54:51AM -0400, Uri Guttman wrote: > another TIL win is no compile phase and not even a bytecode intepreter > startup phase. TIL code is executed directly and the script is now a > true binary. reverse compilation is still easy due to the template > nature of the generate

Re: Perl6 the platform-dependent bits...

At 03:28 PM 10/23/00 -0500, Garrett Goebel wrote: >From: Dan Sugalski [mailto:[EMAIL PROTECTED]] > > (Though if someone comes up with a way to make the > > platform-dependent bits really small and isolated I'm all for it) > >Hmm... I'm 99.9% ignorant on this subject, but

Re: Acceptable speeds (was Re: TIL redux (was Re: What will the Perl6 code name be?))

At 12:54 AM 10/24/00 -0400, Uri Guttman wrote: > > "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes: > > DS> So unless we come up with something concrete, the goals are: > > DS> 1) A nebulous ~10% faster > DS> 2) Faster in the things that annoy Dan the most > DS> 3) Faster in the OO bit

Re: Acceptable speeds (was Re: TIL redux (was Re: What will the Perl6 code name be?))

> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes: DS> Nope, that's not a win, because it can't happen. There needs to be DS> an intermediate representation that can be run through an DS> optimizer. The output of the optimizer could then be turned into DS> TIL code or run through an I

Re: Acceptable speeds (was Re: TIL redux (was Re: What will the Perl6 code name be?))

At 01:23 AM 10/24/00 -0400, Uri Guttman wrote: > > "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes: > > DS> Nope, that's not a win, because it can't happen. There needs to be > DS> an intermediate representation that can be run through an > DS> optimizer. The output of the optimizer coul