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
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
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 rhizomatous
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."
"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. Perl code is
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 use
4. faster
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
routine calls
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 a lot of people
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 interpreter
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!
/HO
--
John Porter
"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 referring to ziggy's
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
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
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
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 Report
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* gaga
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
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).
--
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 we
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 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.
That is
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 separate
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 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:
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
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 shared
"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 specific
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
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 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 being hammered
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 those
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.
What
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-inventing
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 stack
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 going to have a
"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 just the
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 perl
"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 return. all the
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, in
"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 based on the op
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
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 calls. it would 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
"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 and simpler
"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 TIL the
"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. so let
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
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 was
"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 know a
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 their
"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 language
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 generated
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 bits the folks
"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
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 could then be
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.
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 7
Jerrad Pierce wrote:
What about Hexane? Arthropod (or some insect)?
Hmmm "anthracite" ?
--
John Porter
58 matches
Mail list logo
