Dan Sugalski wrote:
> The intent ultimately
> is that you hand an AST, and potentially some rules, to IMCC and it
> creates bytecode for you from it.
That's different, then. Then the whole issue of syntax goes away.
Unless the data interchange format is textual; but even then, you'd
want a syn
'John Porter' wrote:
> Brent Dax wrote:
> No; but statements like "imcc MUST provide access to ALL of parrot's
> (still very dynamic) feature set" and discussions of imcc syntax
> naturally lead to questions of imcc's role in the parrot project.
> E.g. "will the perl6 compiler target imcc?"
T
On Jeudi 22 Août 2002 04:59, 'John Porter' wrote :
> And no one
> has suggested that HLL compiler writers shoudl emit befunge.
> Yet. :-)
Since we're talking about this, I have a suggestion... :o)
Jerome
--
[EMAIL PROTECTED]
On Thursday 22 August 2002 01:24, Melvin Smith wrote:
> >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 itsel
At 11:02 PM -0400 8/21/02, 'John Porter' wrote:
>Melvin Smith wrote:
>> Good question. The problem is, there is no one but us to answer
>> that question. Or who are we waiting for?
>
>I'd like to think that Dan would just declare on the matter
>and put it to rest. But what I *really* think is t
At 10:59 PM 8/21/2002 -0400, '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.)
>But as someone who's writing an
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
Melvin Smith wrote:
> Good question. The problem is, there is no one but us to answer
> that question. Or who are we waiting for?
I'd like to think that Dan would just declare on the matter
and put it to rest. But what I *really* think is that Larry,
or at least Damian, might have something very
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.)
But as someone who's writing an Tcl-to-parrot compiler
(for (hypothetical) example), I mig
On Wed, 21 Aug 2002, Melvin Smith wrote:
> At 07:00 PM 8/21/2002 -0400, 'John Porter' wrote:
> >No; but statements like "imcc MUST provide access to ALL of parrot's
> >(still very dynamic) feature set" and discussions of imcc syntax
> >naturally lead to questions of imcc's role in the parrot proje
At 07:00 PM 8/21/2002 -0400, 'John Porter' wrote:
>No; but statements like "imcc MUST provide access to ALL of parrot's
>(still very dynamic) feature set" and discussions of imcc syntax
>naturally lead to questions of imcc's role in the parrot project.
>E.g. "will the perl6 compiler target imcc?"
At 05:44 PM 8/21/2002 -0400, John Porter wrote:
>The outstanding question is, "Is imcc a part of the parrot system?"
>When compiler writers target parrot, do we really want them to target imcc?
>I have a feeling some of you would answer "yes" to that question all too
My answer is "yes", not becau
Brent Dax wrote:
> John Porter:
> # languages. Seems to me that to say that every feature of parrot
> # must be exposed in imcc is to imply that all upper-level
> # languages must go through imcc -- and that's something I
>
> Let me see if I can follow your logic: IMCC gives access to all Pa
John Porter:
# languages. Seems to me that to say that every feature of parrot
# must be exposed in imcc is to imply that all upper-level
# languages must go through imcc -- and that's something I
Let me see if I can follow your logic: IMCC gives access to all Parrot
features, therefore IMCC
Leopold Toetsch wrote:
> > I don't understand why it is so hard to adopt. imcc is supposed to be
> > a step closer to higher level languages, which is why I went that way.
>
> No problem here, it is called _intermediate_ ..., which is a worthful
> step in code generation, but - as always - there
15 matches
Mail list logo