On Sun, Oct 29, 2000 at 01:36:48PM +, David Grove wrote:
> ana: no, not having, none, anti
> phalis: ...
It's the front part of your helmet which protects your nose.
--
"He was a modest, good-humored boy. It was Oxford that made him insufferable."
Tad McClellan <[EMAIL PROTECTED]> wrote:
>
>
> Sorry to mention the code name thing again, I thought the
> whole endeavor rather silly.
>
> But I just stumbled upon the dictionary definition below, so
> I submit it for due (mis)consideration:
>
>
> pearly everlasting:
>
>n. A rhi
Oh my, Thaddeus is posting again...
>Sorry to mention the code name thing again, I thought the whole
>endeavor rather silly.
I rather think *you* are more silly. And mean, conceited and small.
Remember Ajdin Brandic. How you *wasted* the time of hundreds
of people trying to prove how
Sorry to mention the code name thing again, I thought the
whole endeavor rather silly.
But I just stumbled upon the dictionary definition below, so
I submit it for due (mis)consideration:
pearly everlasting:
n. A rhizomatous plant (Anaphalis margaritacea) with
long-lasting whitish flo
> "AS" == Ariel Scolnicov <[EMAIL PROTECTED]> writes:
AS> Another advantage of a TIL that you seem to lose by compiling Perl to
AS> it is the ease of defining new words. Forth-like systems are
AS> programmed by compiling myriads of very small "words", in gradually
AS> increasing levels. Per
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 bits the folks upstairs from me u
> "JP" == John Porter <[EMAIL PROTECTED]> writes:
JP> Uri Guttman wrote:
>> if i want TIL and lose builtin overloading, that is
>> a fine tradeoff to me.
JP> No, no, no! That is one of the things that absolutely must be
JP> fixed in the next major version of Perl!
i was referrin
Uri Guttman wrote:
> if i want TIL and lose builtin overloading, that is
> a fine tradeoff to me.
No, no, no! That is one of the things that absolutely must be
fixed in the next major version of Perl!
--
John Porter
At 01:10 PM 10/24/00 +0200, Philip Newton wrote:
>On 23 Oct 2000, at 15:40, Peter Scott wrote:
> > What about introducing a pragma which either (a) promises not to use such
> > things, or (b) throws an exception if the program does use such
> constructs,
> > and say "if you want your programs to
On 23 Oct 2000, at 15:40, Peter Scott wrote:
> At 09:54 PM 10/23/00 +0100, Simon Cozens wrote:
> >On Mon, Oct 23, 2000 at 04:38:12PM -0400, Dan Sugalski wrote:
> > > Runtime string eval, do, and require are a serious pain in the butt.
> > > They're the one set of things that'll force a real inter
Ariel Scolnicov <[EMAIL PROTECTED]> writes:
[ A bunch of stuff ]
Er, chaps, not wishing to tread on Skud's moderatorial toes and all,
but shouldn't all this be in perl6-internals?
Reply-To: set.
--
Piers
On Mon, Oct 23, 2000 at 08:27:52PM -0400, Dan Sugalski wrote:
> 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
Uri Guttman <[EMAIL PROTECTED]> writes:
> > "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
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
> "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
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
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
> "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
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
> "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
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
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
> "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.
> "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
> "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
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
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
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
> "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
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,
> "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
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
> "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
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
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
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
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
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
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
> "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
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.
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
> "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
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
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
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:
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
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
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.
>
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
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
>> 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).
--
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
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*
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
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
>> > 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-
> 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
Jerrad Pierce wrote:
>
> What about Hexane? Arthropod (or some insect)?
Hmmm "anthracite" ?
--
John Porter
>How about the traditional birthstone for the 6th month (June)? That would
>be Alexandrite. This has the added advantage of being named after Tsar
>Alexander I, who, like Perl, was ruler over a vast domain.
Ha ha ha, obscure pun
http://www.birthstones.com/stone_jun.html
However come perl
How about the traditional birthstone for the 6th month (June)? That would
be Alexandrite. This has the added advantage of being named after Tsar
Alexander I, who, like Perl, was ruler over a vast domain.
61 matches
Mail list logo
