develooper Front page | perl.perl6.internals | Postings from July 2002

RE: Tasks for the interested

Thread Previous | Thread Next
Dan Sugalski
July 10, 2002 07:39
RE: Tasks for the interested
Message ID:
At 2:30 PM -0700 7/9/02, John Porter wrote:
>Garrett Goebel wrote:
>>  John Porter wrote:
>>  > Not to beat on Dan (or anyone else), but for the sake of those
>>  [...]
>>  Please don't beat on Dan... ;)
>I'm not!

Nope, he isn't.

Warnings and concerns based on technical merits and past experience 
are *always* in order. (Though I'd prefer people hold off on slamming 
a design that's been decided to be final, unless they're working on 
the implementation--in which case slams based on the realities of the 
situation are definitely warranted)

>  > Parrot isn't Perl. I.e., your Perl-vision blinders are on a tad
>  > tight. It's the first general purpose vm for dynamic languages.
>>  That would make it a first system not second.
>That actually doesn't matter much.  The two systems are very
>similar in many fundamental respects; and the one thing that
>all the designers have in common is perl5.  Remember what
>Larry said: "perl 6 is the community's rewrite".
>That makes perl 6 a "second system" in many respects.

Too many respects. Adding "just one more feature" is amazingly seductive.

This is worse in some ways, since it's got features of both a first 
and a second system.

>  > And with a goal like he'll always have at least one voice
>>  screaming bloat into the one ear, while someone else'll be
>>  asking for support for yet another obscure language feature
>>  in the other.
>I'm just saying that (IMHO) trying to reproduce the behavior
>of even two different virtual machines in parrot would be way
>beyond parrot's purpose.

Absolutely. Which is why we're not going to do that.

These 'add-on' bytecode interpreters don't get any special 
consideration in the core. That means they *can* have:

*) A custom bytecode loader to translate their bytecode format to 
ours, or something we can use
*) As many custom PMC classes as they want
*) Dynamically loaded custom opcode functions

They *don't* get:

*) Changes to fundamental core behaviour (like refcounting garbage collection)

If someone writes one and has a reasonable request, it gets treated 
the same as any other reasonable request--if it fits the current 
design, or can go in without causing problems elsewhere, it will 
probably go in. If not, well, they're out of luck.


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

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About