At 09:49 PM 8/20/2002 -0700, Sean O'Rourke wrote: >This is what you'll need. It uses dlopen(), and is likely Bad in a number >of other ways, but if you're on a fairly normal UNIX, it should allow imcc >to grok what P6C produces for regexes. Sean, I'm replying publicly because I'd like to hear other opinions than mine, yours, Angel's and Leopold's. I still prefer infix notation to prefix notation for an intermediate language. 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. I do realize imcc needs a lot of work (it was just a toy), and I haven't had the time to put into it, for example, a proper code generator like BURG, but I would prefer that people to give me convincing arguments on the syntax issue. What I have heard is, "Why make imcc use a different syntax, it requires people to learn a Parrot assembler _and_ imcc." My answer: 1) People in general don't need to learn either; compiler writers might. 2) If imcc merges toward Parrot syntax, it simply diverges from the next platform we attempt to target that is not similar to Parrot. 3) imcc will, by definition, have different syntax because it supports higher level constructs (if statements, call, subs, classes, etc.) I'm still for what we talked about, where any imcc directive uses a leading '.' and the rest of the ops are passed through; with the primary exemption being those ops like set, add, etc. that have more common infix version like: a = 1 b = a + 1 All other ops could be looked up from libparrot as I think your patch attempts to do. Then we can provide enough metadata so the compiler can know enough to do correct optimization on "pass-through" Parrot ops. -Melvin