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

Re: INP ("imcc's not parrot")

Thread Previous | Thread Next
Sean O'Rourke
August 21, 2002 20:18
Re: INP ("imcc's not parrot")
Message ID:
On Wed, 21 Aug 2002, 'John Porter' wrote:

> Sean O'Rourke wrote:
> > However, if we already have a working register
> > allocator and peephole optimizer, I see little reason to write another.
> Maybe you're taking a very perl6-centric view. (I don't know.)

I usually tend to do so, but I'm not sure that I did in this case.  My
impression was that IMCC would mostly do low-level things for which
there's basically one right way.  Hopefully most language-dependent things
would happen at a higher level.  Unless IMCC's quality/time tradeoff isn't
right for your Tcl compiler (hypothetically speaking, of course...), I'd
be surprised if it didn't suit.  And if it doesn't maybe it should be
changed so it does.  Melvin?

> > > >While imcc is cool and worthy, it probably oughtn't be discussed on
> > > >this list untless/until it is a "blessed" member of the parrot suite.
> >
> > As opposed to the blessed BASIC and Befunge?
> No.  Basic, befunge, et alia exist as "standard proofs of concept"

Sorry if that came off a bit snippy.  I just couldn't resist the

> for HLL compilers targeting parrot.  If y'all want to consider imcc
> as just another member of that class, fine!  But if we tell compiler
> writers "You should target imcc, not parrot directly", then imcc
> is clearly in a class by itself.

I'm not sure this is what we're trying to say.  The message is basically
"every compiler needs to do this, and we have it implemented here".  If
it's useful, IMCC will live and grow.  If not, it will end up being
assimilated by the projects taht use it.

> And no one has suggested that HLL compiler writers shoudl emit
> befunge. Yet.  :-)

Forth, maybe.


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