Nathan said:
> As the language isn't finished, and implementation hasn't begun, there
> doesn't seem to be much point in my making up answers to those
> questions :-)

My point is that I want the answers to these questions to be "yes".
So I think that *now* is the right time, before the language 
and implementation are frozen, 
to attempt to influence you and Dan et al. to influence
Larry et al. to design the language so that the answers can be yes.

Steve

> -----Original Message-----
> From: Nathan Torkington [mailto:[EMAIL PROTECTED]]
> Sent: Monday, October 22, 2001 2:49 PM
> To: [EMAIL PROTECTED]
> Subject: [Boston.pm] Re: Parrot and .Net and Java and migration from
> Perl 5
> 
> 
> 
> [forwarded submission from a non-member address -- rjk]
> 
> 
> From: Nathan Torkington <[EMAIL PROTECTED]>
> Date: Mon, 22 Oct 2001 12:31:50 -0600
> Subject: Re: Parrot and .Net and Java and migration from Perl 5
> To: Boston Perl Mongers <[EMAIL PROTECTED]>
> 
> Steve Tolkin writes:
> > Q1.  Will there be a reasonable subset of Perl 6 
> > that can run *safely* in .Net?  I might be willing,
> > even happy, to live with restrictions such as:
> > must type all variable, must not use eval string, etc.
> > 
> > Q2. Can Perl 6 run unsafe in .Net?  
> > 
> > Q3. Can Perl 6 emit Java bytes codes, e.g. *.class files?
> 
> Perl 6 is the language.  Larry's still working on it, and until he's
> done and we write a compiler for it, it doesn't exist.  You can see
> the work in progress by reading the Apocalypses and Exegeses at
> http://www.perl.com/
> 
> As the language isn't finished, and implementation hasn't begun, there
> doesn't seem to be much point in my making up answers to those
> questions :-) We fully expect that people will turn Perl 6 into .NET
> managed code and Java bytecodes, but without a complete (or even
> near-complete) language spec those people haven't had a chance to
> write that code.
> 
> > Q4.  At previous talk Dan explained that Parrot used a register 
> > model rather than a stack model, to permit generating more
> > efficient machine code.  (Most hardware uses registers,
> > not stack.)  However both .Net and Java use a stack model.
> > I suspect this is a cased where the famous principle
> > of "worse is better" applies.  
> > http://www.jwz.org/doc/worse-is-better.html
> > Briefly: It is better to be compatible than to be 
> technically better.
> 
> This wasn't a question :-) If you were asking "why did you do this?"
> or "won't this break your compatibility?"  then Dan can answer those.
> 
> Nat
> 

Reply via email to