MrJoltCola wrote:My impression was that the target for compilers should be a yet non-existent abstract syntax tree. Though I'm somewhat confused about the distinction between parse trees and AST.At 03:21 AM 2/25/2005, Leopold Toetsch wrote:
MrJoltCola <[EMAIL PROTECTED]> wrote:
> I feel that this feature is for higher level languages.
[ snip ]
> ... PIR is for compilers, not people,
PIR and PAST could be considered as being just some languages. Why don't they take the some route, and generate an AST that gets compiled into PBC?
However most compilers I have seen so far are generating PIR and go from there.
Text mode IR is easier to debug with the naked eye than an AST.
ASTs are great if you have supporting tools to browse the tree, dump things out and
translate things back to IR. Virtually all compilers start with an IR and mature
into AST usage, but many successful compilers are built with completely
separate layers. See Muchnicks's work at Sun Microsystems. He has been
the main influence on me as a compiler writer.
PIR is foremost Parrot's primary assembly language. If it were for compiles only, it wouldn't have needed "a = b + c" in the first place, the "add" opcode is doing the same.
It filled a need at the time I wrote it, because there was pretty much
nothing else to write code in except PASM and Jako. It was supposed
to be a thin layer (register allocation and instruction choosing and subs) over PASM.
It is certainly possible to write code in PIR. But it is even more certain that this is no fun. Adding HERE documents remedies an immediate need, especially for playing with compilers and test scripts.
I agree. Why not write a pre-processor that will handles things like this and then
merge them forwards towards a front-end compiler rather than backwards into the
mess of IMCC? Trust me, I know the IMCC code, and it is BAD BAD BAD. And
I fully share the blame with Leo and Angel, bless their hearts. :)
> Nowadays we have a hoard of little toy compilers.
Which language of that hoard should be promoted to become THE standard language for writing test scripts and the Parrot standard library?
PIR is too hard on people, and a scripting language like Ruby, Perl or Python is propably to hard on Parrot.
It propably shouldn't a newly invented language either, because all language designers are having fun with designing Perl6.
You echo my feelings, PIR is too hard on people, and I feel that Parrot's growth suffers
for it, not because of PIR, but because that is all we use. I'm appalled that 3 years after I submitted IMCC
to the project, everyone is still writing in PIR. Parrot need's its own version of "C" or "C#" to empower
more people to contribute. If every new feature for Parrot is thought of in terms of PIR & IMCC, then IMCC
will just become more of a tangled mess that nobody wants to touch, and high-level development will continue
to drag as it has for years.
How about ECMAScript? It has an specification, it has objects and no pointers.
No complaints from me, I don't vote much anyway, but I have strong feelings regarding this project.
The mixing of the VM team and the compiler team is a mistake. It is a problem for commercial
development, much less open-source. One pumpking making decisions for such a wide scope doesn't
leave much room for alternate points of view and unimpeded movement. This is why I urged Dan
long ago to form a parrot-compilers list and split the project into separate decision making teams.
Speaking of Dan, where is he?
-Melvin
