On Sep-20, Dan Sugalski wrote: > > Now, the issue is how to actually build a compiler. Right now a > compiler is a simple thing -- it's a method hanging off the __invoke > vtable slot of the PMC. I'm not sure I like that, as it seems really, > really hackish. Hacks are inevitable, of course, but it seems a bit > early for that. (We ought to at least wait until we do a beta > freeze...) On the other hand it does make a certain amount of sense > -- it's a compilation subroutine we're getting, so we ought to invoke > it, and I can certainly live with that. > > Time to weigh in with opinions, questions, and whatnot. There's not > much reason to JFDI and make the decisions final, so weigh away and > we'll just nail it all down on wednesday.
My preference, as I've stated before, is to leave compilers as invoke-able PMCs -- and further, I think that compilers will sometimes be coroutines, or return multiple continuations, or play other such tricks available via C<invoke> (if appropriate for what they do). Which is easy if you forget about compilation as being something special, but instead just say it's invocable and thereby inherit all of the PIR syntactic sugar for Subs. On the other hand, that opinion assumes that compilers are used in the funky ways that I am thinking of, which involves a lot of switching between languages, using other languages' facilities for implementing pieces of your language, etc. If Parrot is primarily going to be mixing languages by having one language call another's libraries, then I can see some utility in having a separate C<compile> op, even if its only purpose is to explicitly declare that compilers must take only a single string and produce a callable PMC, and no more. (Though I wonder if you might want sometimes use a filename rather than a string-containing-enormous-chunk-of-code). Screwballs like me would then make our languages compiled via a different mechanism, and we wouldn't play in the same sandbox as "regular" compilers. However, then we'd need to decide whether those types of compilers should be registered via compreg, or whether anything registered via compreg is required to do something meaningful when invoked with a single string argument containing code (or whatever C<compile> ends up doing; that's just what it does now.) A question: when last we talked about this, you mentioned that you didn't envision it being useful for compilers to take arguments. I think you were only talking about configuration, but in any case, what sorts of mechanisms do you feel are appropriate for setting options, pointing to libraries or include paths, etc? Also, is Parrot supposed to provide a rich enough set of core functionality that compilers will never need to communicate directly with the "host" language? As a simple example, say you have an embedded language that wants to add a new local variable. Parrot has pads for this purpose, but what if you need to specify some sort of rich type information or register it with some host language-specific registry singleton of some sort? I don't know if these sorts of things are useful, but they're easily within the scope of imagination. :-)
