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 is a but, it should > supply the infrastructure to generate _all_ possible .pasm code.
If the point is that every feature of parrot should be exposed in imcc's ui, then that sounds reasonable, since the converse would be that some features of parrot are hidden. But obversely, parrot does not exist to supply features to imcc alone, it is meant to be targeted by many languages/compilers. I.e. "imcc is not the only path to parrot", and part of the design is to allow specially designed ops to exist for the support of specific 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 don't think we should mandate. Certainly it was not the original intention. > Melvin, Sean's patch is not agaist imcc's syntax, it _extends_ the > syntax with badly needed pasm syntax. There a currently 261 basic ops > variating to a total of 844 different ops, why should imcc all implement > _all_ and still permanently changing ops mow. > > I personally like imcc's syntax, it's a lot more readable compared to pasm. 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 blithely. But I don't see imcc mentioned in the PDD's. Heck, pasm itself is little more than a "possible variation"; the PDD's strongly imply that the perl6 compiler will compile directly to parrot bytecode. -- John Douglas Porter
