Re: What will the Perl6 code name be?

[Gerrit Haase]

> 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?

[Jerrad Pierce]

>> > 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-Oriented Language
which should then be PERLOOL

b) It's not object oriente, it allows object oriented syntax, but it is not
OO.

--
#!/usr/bin/perl -nl
BEGIN{($,,$0)=("\040",21);@F=(sub{tr[a-zA-Z][n-za-mN-ZA-M];print;});
$_="Gnxr 1-3 ng n gvzr, gur ynfg bar vf cbvfba.";&{$F[0]};sub t{*t=sub{};
return if rand()<.5;$_="Vg'f abg lbhe ghea lrg, abj tb.";&{$F[0]};$_=0;}
sub v{print map sprintf('%c', 2**7-2**2),(1 .. $0);}&v;}{$_++;$_--;$_||=4;
if($_>>2||($_<<2>12)){$_="Vainyvq ragel";&{$F[0]};last;}&t;$0-=$_;$_="Lbh jva";
die(&{$F[0]}) if !($0-1);$0-=$0%2?$0>2?2:1:$0<=5?$0>2?3:1:rand>.5?1:3;
$_="V jva";die(&{$F[0]}) if !($0-1>1);}&v __END__ http://pthbb.org/
MOTD on Sweetmorn, the 4th of The Aftermath, in the YOLD 3166:

"A pessimist is a man who looks both ways when he's crossing a one-way street."

RE: renaming local to "hold"

[Garrett Goebel]

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 phone call,
> while you do something else with your ear.

'Hold' is nice and succinct.

I kind of like 'ersatz' too. And the idea of 'vicarious' variables...

Here are some other possibilities:

interim
heretofore
supplant
permute
transpose

RE: renaming local to "hold"

[Jerrad Pierce]

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#(like filehandles with flags)


--
#!/usr/bin/perl -nl
BEGIN{($,,$0)=("\040",21);@F=(sub{tr[a-zA-Z][n-za-mN-ZA-M];print;});
$_="Gnxr 1-3 ng n gvzr, gur ynfg bar vf cbvfba.";&{$F[0]};sub t{*t=sub{};
return if rand()<.5;$_="Vg'f abg lbhe ghea lrg, abj tb.";&{$F[0]};$_=0;}
sub v{print map sprintf('%c', 2**7-2**2),(1 .. $0);}&v;}{$_++;$_--;$_||=4;
if($_>>2||($_<<2>12)){$_="Vainyvq ragel";&{$F[0]};last;}&t;$0-=$_;$_="Lbh jva";
die(&{$F[0]}) if !($0-1);$0-=$0%2?$0>2?2:1:$0<=5?$0>2?3:1:rand>.5?1:3;
$_="V jva";die(&{$F[0]}) if !($0-1>1);}&v __END__ http://pthbb.org/
MOTD on Sweetmorn, the 4th of The Aftermath, in the YOLD 3166:

"A pessimist is a man who looks both ways when he's crossing a one-way street."

Re: What will the Perl6 code name be?

[Gerrit Haase]

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 Language Object-Oriented Language
>  which should then be PERLOOL
> 
> b) It's not object oriente, it allows object oriented syntax, but it
> is not OO.

Perl, which allows object oriented syntax, written in C++ language,

PWAOOSWIC++L,

;-)
- gph -

-- 
Gerrit Peter Haase

Re: What will the Perl6 code name be?

[Simon Cozens]

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 someone loses an eye.
 Then it's a sport!

Re: What will the Perl6 code name be?

[Dan Sugalski]

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 overnight?

Got me. I'd planned on us writing perl 6 in INTERCAL. (Or SNOBOL, I'm still 
undecided... :)

Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: What will the Perl6 code name be?

[Simon Cozens]

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 I owned the M$ division that built Lookout
and SexChange, I'd trade it for a dog, and then I'd shoot
the dog. - Mike Andrews, asr.

Re: What will the Perl6 code name be?

[Jerrad Pierce]

>> 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).

--
#!/usr/bin/perl -nl
BEGIN{($,,$0)=("\040",21);@F=(sub{tr[a-zA-Z][n-za-mN-ZA-M];print;});
$_="Gnxr 1-3 ng n gvzr, gur ynfg bar vf cbvfba.";&{$F[0]};sub t{*t=sub{};
return if rand()<.5;$_="Vg'f abg lbhe ghea lrg, abj tb.";&{$F[0]};$_=0;}
sub v{print map sprintf('%c', 2**7-2**2),(1 .. $0);}&v;}{$_++;$_--;$_||=4;
if($_>>2||($_<<2>12)){$_="Vainyvq ragel";&{$F[0]};last;}&t;$0-=$_;$_="Lbh jva";
die(&{$F[0]}) if !($0-1);$0-=$0%2?$0>2?2:1:$0<=5?$0>2?3:1:rand>.5?1:3;
$_="V jva";die(&{$F[0]}) if !($0-1>1);}&v __END__ http://pthbb.org/
MOTD on Sweetmorn, the 4th of The Aftermath, in the YOLD 3166:

"A pessimist is a man who looks both ways when he's crossing a one-way street."

Re: What will the Perl6 code name be?

[Dan Sugalski]

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 planning on
>compiling Perl 6 programs to native binaries?

That is one of the scenarios. There are some issues with it for a project 
like this--spitting out binaries directly requires rather more carnal 
knowledge of the OS/processor pair than something like an interpreter or 
C-code-spitter does.

It's likely to be a secondary target, after a 'normal' interpreter. (Though 
if someone comes up with a way to make the platform-dependent bits really 
small and isolated I'm all for it)

Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: What will the Perl6 code name be?

[Simon Cozens]

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 binaries directly requires rather more carnal 
> knowledge of the OS/processor pair than something like an interpreter or 
> C-code-spitter does.

Right, right, but once we've got a nice interface to the op tree - which may
be something like B::, or maybe a low-level C API - we can, and probably
should, encourage people to play with it. 

A C-code-spitter is another kettle of fish altogether; as you know, the
current things like B::C and B::CC spit out a state dump of the op-tree and
then an interpreter. This is cool enough, but it isn't what people want. What
they want is a translator, rather than a compiler, and this is slightly more
tricky. However, due to Nat's terrible influence, he suggested to me at
YAPC::Europe that someone should try writing one.[1] I'm working on something
I'm calling B::Translate for Perl 5 which does just this; it's basically a
variant of B::Deparse which spits out C instead. It's a really tricky job,
which reminds me of all the things I dislike about C, but it's getting there,
slowly. 

[1] He also mentioned that that's the sort of thing ActiveState should pay
someone to do, which I mention on the off-chance someone interesting is
listening. :)

-- 
... though the Japanese must be the most stupid people... I'm sure I
read somewhere that Tokyo has the densest population in the world...
- Gid Holyoake, sdm.

Re: What will the Perl6 code name be?

[Dan Sugalski]

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 one of the scenarios. There are some issues with it for a project
> > like this--spitting out binaries directly requires rather more carnal
> > knowledge of the OS/processor pair than something like an interpreter or
> > C-code-spitter does.
>
>Right, right, but once we've got a nice interface to the op tree - which may
>be something like B::, or maybe a low-level C API - we can, and probably
>should, encourage people to play with it.

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 libraries, and dynamically replaceable. (or 
at least done with a quick relink)

In this case, the native code emitter would replace the execution engine 
and, rather than interpreting the IR passed to it, would instead do X, 
where X is one of emit Java bytecode, emit .NET code, emit an object file, 
or emit an executable. (Or a C source module, or ties into the GEM or GCC 
backends, or something)

>A C-code-spitter is another kettle of fish altogether; as you know, the
>current things like B::C and B::CC spit out a state dump of the op-tree and
>then an interpreter. This is cool enough, but it isn't what people want. What
>they want is a translator, rather than a compiler, and this is slightly more
>tricky. However, due to Nat's terrible influence, he suggested to me at
>YAPC::Europe that someone should try writing one.[1] I'm working on something
>I'm calling B::Translate for Perl 5 which does just this; it's basically a
>variant of B::Deparse which spits out C instead.

What's this piece do that B::C or B::CC don't do? I'm confused here.

>It's a really tricky job,
>which reminds me of all the things I dislike about C, but it's getting there,
>slowly.

I find it easier to keep in mind the things I do like about C. A much 
shorter list. :)



Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: What will the Perl6 code name be?

[Simon Cozens]

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 shared libraries, and dynamically replaceable. (or 
> at least done with a quick relink)

Yes, yes, yes, yes, yes, yes, yes, yes, yes. Incidentally, I think that's a
good idea.

> (Or a C source module, or ties into the GEM

The Atari ST to my right just perked up.

> What's this piece do that B::C or B::CC don't do? I'm confused here.

It doesn't embed an interpreter. It outputs "native" C.

#!/usr/bin/perl
print "Hello world\n";
  
translates to

int
main (int argc, char **argv)
{

#line 2 "hello.pl"
printf("%s", "Hello world\n");
}
 
-- 
By God I *KNOW* what this network is for, and you can't have it.
- Russ Allbery, http://www.slacker.com/rant.html 

Re: What will the Perl6 code name be?

[John Porter]

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 course.

-- 
John Porter

Standard emoticons apply.

Re: What will the Perl6 code name be?

[Simon Cozens]

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:
"After three days without programming, life becomes meaningless."
-- Geoffrey James, "The Tao of Programming"

Perl6 the platform-dependent bits...

[Garrett Goebel]

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?
(www.cminusminus.org) I realize C-- isn't just immature, its premature...
But there are probably ideas to be gained by sifting through the projects
papers and code.

Garrett

Re: What will the Perl6 code name be?

[John Porter]

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?

[Dan Sugalski]

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 libraries, and dynamically replaceable. (or
> > at least done with a quick relink)
>
>Yes, yes, yes, yes, yes, yes, yes, yes, yes. Incidentally, I think that's a
>good idea.

Really? You seem a little ambivalent.

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. :(

> > (Or a C source module, or ties into the GEM
>
>The Atari ST to my right just perked up.

:) I expect the one I dropped off at the Salvation Army probably did too.

In this case GEM is DEC's compiler back-end for their alpha machines. It's 
a sweet little optimizing back end.

> > What's this piece do that B::C or B::CC don't do? I'm confused here.
>
>It doesn't embed an interpreter. It outputs "native" C.

Yerk. That must make string evals rather fun.

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 into a program.

Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: What will the Perl6 code name be?

[Uri Guttman]

> "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 perl backend would generate
only perl op calls in machine code and thread them togethers. this has
nothing to do with OS threads. we just have a name collision problem.

it is debatable whether this gains any speed (several of us think it
will) and will need benchmarking to verify that.

uri

-- 
Uri Guttman  -  [EMAIL PROTECTED]  --  http://www.sysarch.com
SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting
The Perl Books Page  ---  http://www.sysarch.com/cgi-bin/perl_books
The Best Search Engine on the Net  --  http://www.northernlight.com

Re: What will the Perl6 code name be?

[Simon Cozens]

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 those BEGIN blocks are *supposed* to be instructions
to the compiler.

> 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 into a program.

*nodnod*. This is really tricky; if there's no eval in the program, we can
make all sorts of interesting optimizations: forego the whole SV process, and
just use ints and char*s and whatever. If there's an eval, you've got to throw
everything back into Perl-space, embed an interpreter, and all that jazz. Yes,
it sucks hard. But Perl *is* an interpreted language, like it or not.

-- 
"Jesus ate my mouse" or some similar banality.
-- Megahal (trained on asr), 1998-11-06

Re: What will the Perl6 code name be?

[Simon Cozens]

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.
-- David Jones

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

[Uri Guttman]

> "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
around. 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.

this was called threaded code in the old days and some compilers
generated that as it made code generation very simple. you don't have to
generate all the code for each possible op and deal with the full set of
machine instructions. TIL is slower than fully compiled code but is
should be faster than fully interpreted code if done correctly. also the
code generator can be created very quickly and could even be
partly/fully table driven for each backend architecture.

other benefits are it will just plugin to the replaceable back end dan
is fancying. adding new architectures should be not too difficult once a
few are done. this can be done later on after other compiler parts are
in place and stable.

most agreed TIL is a worthwhile goal but not the highest priority. as
long as clean hooks are there for backend plugins and the perl op api is
very simple and clean, generating TIL will not be too difficult. when
there arises an itch for more speed and compiling to an architecture is
useful, TIL will be the scratcher.

uri

-- 
Uri Guttman  -  [EMAIL PROTECTED]  --  http://www.sysarch.com
SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting
The Perl Books Page  ---  http://www.sysarch.com/cgi-bin/perl_books
The Best Search Engine on the Net  --  http://www.northernlight.com

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

[Adam Turoff]

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 around though.

> 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.

So you're talking about using a Forth style compiler to thread the
opcodes together.

Unfortunately, there's a slight problem with that:
*main::localtime = \&replacement;
memoize("factorial");

Once you've threaded the sub calls together, you've lost the indirection.

There's a discussion that Larry started this weekend on -internals.
Specifically:

  Date: Mon, 23 Oct 2000 08:45:39 -0700 (PDT)
  From: Larry Wall <[EMAIL PROTECTED]>
  Message-Id: <[EMAIL PROTECTED]>
  To: [EMAIL PROTECTED] (Adam Turoff)
  Cc: Larry Wall <[EMAIL PROTECTED]>, [EMAIL PROTECTED], [EMAIL PROTECTED]
  Subject: Re: Threaded Perl bytecode (was: Re: stackless python)
  In-Reply-To: <[EMAIL PROTECTED]>
   (from Adam Turoff on Sun, 22 Oct 2000 20:10:34 -0400)
  Sender: [EMAIL PROTECTED]
  Status: RO
  Content-Length: 364
  Lines: 9
  
  Adam Turoff writes:
  : If Perl bytecode were to become threaded, it would be rather troublesome.
  
  Wasn't actually suggesting it, though similar issues also arise for
  compiling down to efficient C, JVM, or C# IL.  Optimizing for Least
  Surprise means different things in different contexts, but I'd hate
  for Perl 6 to be astonishingly slow at anything...  :-)
  
  Larry
  
Hope this helps.

Z.

Re: What will the Perl6 code name be?

[Peter Scott]

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 BEGIN blocks very far. :(
>
>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 :-)

> > 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 into a 
> program.
>
>*nodnod*. This is really tricky; if there's no eval in the program, we can
>make all sorts of interesting optimizations: forego the whole SV process, and
>just use ints and char*s and whatever. If there's an eval, you've got to throw
>everything back into Perl-space, embed an interpreter, and all that jazz.

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 be compilable (or compile to 
something a heck of a lot lighter), say 'use strict "compilation"' or 
whatever"?

--
Peter Scott
Pacific Systems Design Technologies

Re: What will the Perl6 code name be?

[Simon Cozens]

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 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 be compilable (or compile to 
> something a heck of a lot lighter), say 'use strict "compilation"' or 
> whatever"?

Why bother? We can tell if such a thing is going to be introduced from the op
tree. It only matters when we want to compile things, and I'm guessing that's
going to be the minority of cases. When Joe Random writes his one-liner, I
don't want to interfere with him.

-- 
If God had a beard, he'd be a UNIX programmer.

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

[Simon Cozens]

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 .NET. Why?

-- 
Do you associate ST JOHN'S with addiction to ASIA FILE?
- Henry Braun is Oxford Zippy

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

[Dan Sugalski]

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 glue code in between them.
>
>OK, you're re-inventing .NET.

No, we're re-inventing wheels *far* older than that... :-P

>Why?

Well, it's potentially faster for one thing. Besides losing the runops loop 
(or whatever replaces it) which is good, it means the program now lives in 
I space instead of D space, which may get us better cache usage. Rather 
than the perl program sharing the D cache with real data, it shares the I 
cache with the rest of the program, which can be good. (or bad, depending)

It also means that, since the program is a 'real' executable (for some 
value of real) we could potentially freeze it off to disk in some way, 
getting an executable. This may help reduce memory usage if we can get 
modules in a state where the perl code's actually a shared library, which'd 
be rather keen.

Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: What will the Perl6 code name be?

[Dan Sugalski]

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 shock. This isn't Perl 5 any more, Toto.

Yeah, but we haven't changed things *that* much. At least not without an 
edict from Larry.

Besides, instructions to the compiler are executable code pretty much by 
definition, so I don't see what sort of limits we could place on them. 
They'll have to allow general code execution, since many of those compiler 
hints are conditional module loading.

Generally, though, I'm not inclined to hand anything off to the optimizer 
until after all the BEGIN blocks have been run. Sure it may mean a 
semi-populated symbol table and various independent scopes hanging around 
for subs, but we're going to need to handle that anyway, so I don't see it 
as a big deal.

> > 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 be compilable (or compile to
> > something a heck of a lot lighter), say 'use strict "compilation"' or
> > whatever"?
>
>Why bother? We can tell if such a thing is going to be introduced from the op
>tree. It only matters when we want to compile things, and I'm guessing that's
>going to be the minority of cases. When Joe Random writes his one-liner, I
>don't want to interfere with him.

Neither do I, but I think you'll find a lot of those programs will want to 
be fed through the optimizer as best as possible. Sure some might be only a 
dozen lines or so, but I'd be happy to pay 10 seconds to shave off one msec 
an iteration of some loops. Optionally (and off by default) of course, but 
don't dismiss heavy optimizations on tiny programs. Granted I may be in the 
minority, running one-liners over 100M+ files, but a lot of perl code's 
bigger than that.

A lot of the tiny programs aren't all that tiny, either. Ten lines isn't 
much unless one of them's "use CGI;" or "use Net::FTP". And there are huge 
gobs of those.

Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

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

[Uri Guttman]

> "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 minimal stack glue code in between them.

  SC> OK, you're re-inventing .NET. Why?

more likely .NET is reinventing TIL which is a very old technology. i am
not the only one who supports this idea so don't pin it all on me. it is
a good compromise between pure interpretation and pure compilation.

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. then you can
overload the entry with a user supplied sub. there could be a sub table
for every execution thread which solves that problem as well.  now
making sure that op ids can fit into a table is an issue especially if
hundreds of subs are added in user code. but this can be worked out.

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.

uri

-- 
Uri Guttman  -  [EMAIL PROTECTED]  --  http://www.sysarch.com
SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting
The Perl Books Page  ---  http://www.sysarch.com/cgi-bin/perl_books
The Best Search Engine on the Net  --  http://www.northernlight.com

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

[Dan Sugalski]

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 5, and saw a rather 
significant performance hit. ~20% IIRC, but the numbers are in the p5p 
archives somewhere.


Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

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

[Uri Guttman]

> "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 routine calls
  >> > are to perl ops with just the minimal stack glue code in between them.
  >> 
  >> OK, you're re-inventing .NET.

  DS> No, we're re-inventing wheels *far* older than that... :-P

see, there are advantages to being an old fart. we can remember further
back what crap we are reinventing this time around the wheelhouse.

remember mainframes with centralized everything, then mini computers
which decentralized, and workstations and pc's which decentralized
fully. now the trend is back to centralization as in app servers and
back end server farms, etc.

inline threaded code is something whose time has come again.

:-)

uri

-- 
Uri Guttman  -  [EMAIL PROTECTED]  --  http://www.sysarch.com
SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting
The Perl Books Page  ---  http://www.sysarch.com/cgi-bin/perl_books
The Best Search Engine on the Net  --  http://www.northernlight.com

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

[Simon Cozens]

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 any sense of the word, true?

I mean, given three-address code, I find anything equally difficult to
generate. 

I don't see anything that distinguishes this from the ordinary process of
generating code with a runtime library and a stack.

-- 
DEC diagnostics would run on a dead whale.
-- Mel Ferentz

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

[Uri Guttman]

> "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 code id.

  DS> FWIW, this isn't all that fast. I tried it with perl 5, and saw a rather 
  DS> significant performance hit. ~20% IIRC, but the numbers are in the p5p 
  DS> archives somewhere.

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. the TIL speedup over
pure interpretation might win that back and more. we have much
prototyping and testing to do. we have to design all the hooks in early
so we have a clean architecture and then we can implement TIL and other
backends (direct to c, etc.) with no major problems.

uri

-- 
Uri Guttman  -  [EMAIL PROTECTED]  --  http://www.sysarch.com
SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting
The Perl Books Page  ---  http://www.sysarch.com/cgi-bin/perl_books
The Best Search Engine on the Net  --  http://www.northernlight.com

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

[Adam Turoff]

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 you've gone through the effort
to thread it in the first place.

If you're going to have indirect lookups, keep it localized.  Adding
the "simple dispatch table" is adding more instructions (and memory
fetches, and cache flushes) where they're not needed, making the
optimization run slower than what it was trying to optimize.

Perl is just too dynamic to use threaded bytecode out of the box.

I'm with Dan.  Make it an optional runtime for everyone who *chooses*
to live within the confines of threaded bytecode.  It shouldn't be the
default runtime model because it is too broken.

Remember what Knuth said: premature optimization is the root of all evil.

Z.

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

[Dan Sugalski]

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 fast
>   >> with just an indexed lookup based on the op code id.
>
>   DS> FWIW, this isn't all that fast. I tried it with perl 5, and saw a 
> rather
>   DS> significant performance hit. ~20% IIRC, but the numbers are in the p5p
>   DS> archives somewhere.
>
>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. If the ultimate result's faster than what we have now then it's 
OK, but if it's not, then I don't think we should do it unless the language 
design documents require it. (And I hope they don't...)

We can't slow down, no matter what it might buy us.


Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

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

[Dan Sugalski]

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 generate than fully compiled
> > code.
>
>Is this actually, in any sense of the word, true?

Yup.

>I mean, given three-address code, I find anything equally difficult to
>generate.

Code generation's reasonably simple. Since what you're doing is really very 
repetitive, you can get by with some chunks of boilerplate with some fillin 
blanks. Sure it's just a set of calls into the perl interpreter pretty much 
identical to what you get after a run through B::C, but that does work.

As for speed, going this way means we toss the loop, which is good. Loops 
are wasted overhead for what we want to be doing.

>I don't see anything that distinguishes this from the ordinary process of
>generating code with a runtime library and a stack.

There isn't, much.

Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

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

[Uri Guttman]

> "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 to generate than fully compiled
  >> code.

  SC> Is this actually, in any sense of the word, true?

yes it is true. i have worked on compilers and debugged both the
generated inline code and runtime calls code. a full compiler generates
mountains of code to do basic operations in any combination. and
optimizing machine code is very architecture specific. debugging the
runtime call code was much simpler. the machine level api was defined
and you just had to get that right and pass in arguments cleanly. the
inline code generation took much more work to write and to debug.

i would not tackle a true code generation project. i would have no
qualms about working on a TIL code generation project. they are worlds
apart in complexity.

TIL code is almost template driven. here is the code to setup a scalar
arg, to set up a hash arg, here is the op code function call template,
etc. you just fill in the constants and offsets in the proper slots in
the code and you're done. you can't even code + inline, just the call to
the plus op code function.

  SC> I don't see anything that distinguishes this from the ordinary process of
  SC> generating code with a runtime library and a stack.

as dan has said, you move the code out of data space and caching. it
will generally run faster than pure interpreting and have a simpler code
generator.

it has the kind of tradeoffs i like. you get more bang for less coding
effort. a true compiler is much harder to create. 

and remember it is not critical path but it should be addressed in the
architecture of the backend subsystem. with dan liking it, i doubt that
it will be forgotten. if he does forget it, i will poke him with a soft
cushion a lot.

uri

-- 
Uri Guttman  -  [EMAIL PROTECTED]  --  http://www.sysarch.com
SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting
The Perl Books Page  ---  http://www.sysarch.com/cgi-bin/perl_books
The Best Search Engine on the Net  --  http://www.northernlight.com

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

[Uri Guttman]

> "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 default. the default perl mode
MUST be compile and interpret on the run. all other backends are
optional and may carry signifigant restrictions.

  AT> Remember what Knuth said: premature optimization is the root of
  AT> all evil.

how true that is. i will backoff the dispatch tables until we get to
that actual code.

uri

-- 
Uri Guttman  -  [EMAIL PROTECTED]  --  http://www.sysarch.com
SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting
The Perl Books Page  ---  http://www.sysarch.com/cgi-bin/perl_books
The Best Search Engine on the Net  --  http://www.northernlight.com

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

[Uri Guttman]

> "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 us not vote one way or
another on any low level design. we should spec out the needs of these
overlapping areas (process threads, TIL, dispatch loop and tables, back
end API, etc.) and figure out what we can do and where to restrictions
need to be applied. it i want TIL and lose builtin overloading, that is
a fine tradeoff to me. i doubt i would ever overload a builtin but who
knows the future with out using PSI::ESP?

uri

-- 
Uri Guttman  -  [EMAIL PROTECTED]  --  http://www.sysarch.com
SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting
The Perl Books Page  ---  http://www.sysarch.com/cgi-bin/perl_books
The Best Search Engine on the Net  --  http://www.northernlight.com

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

[Russ Allbery]

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 Python.

> the TIL speedup over pure interpretation might win that back and
> more.

If that's true, that's a different ballgame of course.

If at all possible, Perl 6 should be *faster* than Perl 5.  Perl is
already too slow IMO.

-- 
Russ Allbery ([EMAIL PROTECTED]) 

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

[Nathan Torkington]

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 enough to
move the speed from "too slow" to "acceptable", and all they did was
deobjectify the design.

Nat

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

[Uri Guttman]

> "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 company that had to rewrite most of their OO code because
  NT> it was the bottleneck in their application.  The rewrite was
  NT> enough to move the speed from "too slow" to "acceptable", and all
  NT> they did was deobjectify the design.

that is a fine decision if speed is critical. others use OO to speed
developmemt at a cost of runtime speed. i have worked on projects which
have had one of those as the higher priority as i am sure many of us
have.

uri

-- 
Uri Guttman  -  [EMAIL PROTECTED]  --  http://www.sysarch.com
SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting
The Perl Books Page  ---  http://www.sysarch.com/cgi-bin/perl_books
The Best Search Engine on the Net  --  http://www.northernlight.com

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

[Dan Sugalski]

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 application.  The rewrite was enough to
>move the speed from "too slow" to "acceptable", and all they did was
>deobjectify the design.

The speed of perl's OO is more than a little important to me at the moment, 
and I don't even *write* OO code. :)

What I'd really like is for us to put together a list of benchmark (though 
not Benchmark) programs and sample inputs for them if they need some. I'd 
also like to get what we can consider reasonable percentage speedup targets 
for perl 6. (No sneaky asking for perl to rip through a file faster than a 
drive can read the data... :-) We can choose the version of perl 5 we want 
to use as a reference, and go from there. We may not make our targets, but 
at least we'll have something to shoot for, and a rough measure of whether 
we're going in the right direction.

This isn't, FWIW, a shot at premature optimization or anything of the sort. 
(Crocking the perl 6 source to beat the benchmarks, though, is another 
matter entirely... :) What we've got right now is vague "perl is too slow", 
and it is in spots. Without agreed-on goals, though, we're sort of at the 
mercy of whoever writes the optimizer and directs the development. (And I 
should warn everyone that my penchant is for ripping through 
multi-gigabytes of data from either text files or simple databases, 
regexing against it, and spitting it out to a file somewhere. That's where 
my scripts run for hours, and where I care the most, since it affects me 
directly)

So unless we come up with something concrete, the goals are:

1) A nebulous ~10% faster
2) Faster in the things that annoy Dan the most
3) Faster in the OO bits the folks upstairs from me use

I think we can do a bit better than that...

Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

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

[Uri Guttman]

> "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 level I/O (of course driven by AIO. :)
5. faster startup via bytecode and/or TIL
6. Quantum::Superposition::ForReal

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 code.

uri

-- 
Uri Guttman  -  [EMAIL PROTECTED]  --  http://www.sysarch.com
SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting
The Perl Books Page  ---  http://www.sysarch.com/cgi-bin/perl_books
The Best Search Engine on the Net  --  http://www.northernlight.com

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

[Adam Turoff]

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 code.

Hard numbers, please.

Z.

Re: Perl6 the platform-dependent bits...

[Dan Sugalski]

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 doesn't this relate back to 
>past discussions of C--, the portable assembly language? 
>(www.cminusminus.org) I realize C-- isn't just immature, its premature... 
>But there are probably ideas to be gained by sifting through the projects 
>papers and code.

I don't think so--we want perl to generate the executable code directly. If 
we're generating an intermediate language that then gets compiled, we might 
as well use C. (Even though it's rather limited)

I like the idea of returning multiple results in multiple registers. Pity 
nothing on the planet could link to us if we did that... :(

Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

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

[Dan Sugalski]

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 upstairs from me use
>
>4. faster internal and language level I/O (of course driven by AIO. :)
>5. faster startup via bytecode and/or TIL
>6. Quantum::Superposition::ForReal

Those are implementation details, not performance targets. If perl would 
run faster if I hopped up and down on one foot I would. :)

>another TIL win is no compile phase and not even a bytecode intepreter
>startup phase.

Nope, that's not a win, because it can't happen. There needs to be an 
intermediate representation that can be run through an optimizer. The 
output of the optimizer could then be turned into TIL code or run through 
an IR->interpreter stuff translator. (Or Java bytecode, or .NET code, or 
whatever) Any way you go there's a compile 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 code.

Gack. No way. We will *not* use decompilation of machine language code as a 
way to spit out perl source. That's just evil and a waste--we're better off 
not throwing out the info on the source in the first place.

Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

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

[Uri Guttman]

> "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 IR->interpreter stuff translator. (Or
  DS> Java bytecode, or .NET code, or whatever) Any way you go there's a
  DS> compile phase.

slight confusion here. i mean when you run a saved TIL perl program, it
just runs as a binary and so there is no compile phase then. 

  >> 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 code.

  DS> Gack. No way. We will *not* use decompilation of machine language
  DS> code as a way to spit out perl source. That's just evil and a
  DS> waste--we're better off not throwing out the info on the source in
  DS> the first place.

no, i didn't mean it that way. i was think about those who ask for ways
to distribute their perl code as a binary for 'security' reasons. this
TIL code after distribution could easily be uncompiled for the usual
suspect reasons. nothing was meant about using TIL code for anything but
an end product meant to be execute only.

uri

-- 
Uri Guttman  -  [EMAIL PROTECTED]  --  http://www.sysarch.com
SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting
The Perl Books Page  ---  http://www.sysarch.com/cgi-bin/perl_books
The Best Search Engine on the Net  --  http://www.northernlight.com

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

[Dan Sugalski]

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 turned into
>   DS> TIL code or run through an IR->interpreter stuff translator. (Or
>   DS> Java bytecode, or .NET code, or whatever) Any way you go there's a
>   DS> compile phase.
>
>slight confusion here. i mean when you run a saved TIL perl program, it
>just runs as a binary and so there is no compile phase then.

Ah, that's something else entirely. Yeah, that is definitely a win for TILs 
and other methods that compile to real executable code.

>   >> 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 code.
>
>   DS> Gack. No way. We will *not* use decompilation of machine language
>   DS> code as a way to spit out perl source. That's just evil and a
>   DS> waste--we're better off not throwing out the info on the source in
>   DS> the first place.
>
>no, i didn't mean it that way. i was think about those who ask for ways
>to distribute their perl code as a binary for 'security' reasons. this
>TIL code after distribution could easily be uncompiled for the usual
>suspect reasons. nothing was meant about using TIL code for anything but
>an end product meant to be execute only.

Ah. Well, I still think that the intermediate bits should be saved if at 
all possible, but I don't much care if the resulting 'binary' (whether it's 
a real executable, or Java bytecode, or grossly optimized perl bytecode) is 
translatable back to perl source. If some transformation gets a performance 
win but crocks back translation, well, that's too bad. :) Performance wins. 
I'd rather folks not strip out the source-ish bits (they'll get sucky error 
messages that way too) but if they do, well, they do.

Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk