On Aug-30, Dan Sugalski wrote: > I've been watching this thread with some bemusement -- I've got to > admit, I don't see the problem here. > > I'm not sure what the point of passing in parameters to the > compilation is. (Not that I don't see the point of having changeable > settings for compilers, but that's something separate) The interface > is simple on purpose -- in most cases either there *are* no > parameters possible (Perl's eval and its equivalent in other > languages) or there's no reasonable way to know what the parameters > are (Perl's eval evaluating code of a different language). The syntax > just isn't there to have them, and is really unlikely to ever > materialize, so there's little point in putting in parameters to the > compilation. In those cases where the programmer may know what to > change, they can tweak any external knobs the compiler module might > have programmatically.
I understand that perspective, but I guess I'm thinking about embedded compilers somewhat differently. For example, consider a regex compiler. It needs to be able to compile embedded code in whatever the host language is. In fact, it needs to be able to switch back and forth freely between the regex compile and the host language compile, and the compilation of the inner language might need to be tailored to fit into whatever the regex compiler needs. Maybe that's a simple as saying "don't provide a main()", in which case it can be done by having two C<compreg> registration strings for the same language. But you have to get the name of that language into the regex compiler in the first place. (Ok, you might be able to avoid that in this particular case by making the regex compiler into a coroutine, but I don't want to get too caught up in one particular example.) And the compiler needs to be reentrant, for the cases where the language within the regex rule invokes another regex match. I mention that only to say that you can't just set properties on the PMC returned from C<compreg>, because that PMC will be shared during reentrant calls. You could always clone it and then configure it, I suppose. Anyway, I'm just trying to come up with situations where compilers need to know more than just the language they're compiling, and especially cases where you want different configuration for every compile. Another example of this would be if your regex syntax involved binding hypothetical variables (or something similar), and the inner language needed to know at compile time which variables had been defined at that point. I'm sure I could come up with workarounds for all of these issues, but I was expecting that much of the usefulness of Parrot would be in mixing together (and nesting) several languages in one program, and it seems like in many cases nested compiles are going to need to communicate nontrivial amounts of information. I'm okay with things if the answer is "don't do that" -- meaning if you need complex cases like this, then forget about C<compile> and do everything with straight subroutines or whatever else -- but I would like to understand the intent of the C<compile> op better so I can forget about trying to make my stuff fit into its mold if what I'm doing is just different. > The whole "name for the function I'm compiling" thing isn't an issue > either, or at least it shouldn't be. The code being compiled is > implicitly a subroutine -- you don't have to have code that reads: > > .sub foo_1234423_some_random_text > . > . > . > .end > > and go look for 'foo12 34423_some_random_text' in a namespace > somewhere. Just leave out the .sub/.end (they should be implied) and > the returned PMC is a sub PMC for your nicely anonymous sub. Which is > fine, and as it should be. That would work fine for me. The current state also works ok since overriding is allowed, but it feels wrong to construct a sub with a specific name and then disavow all knowledge of that name even though it's been registered in some global table. Leo's @ANON implementation of your scheme works great for me (I have no problem wrapping that around my code.) All this does raise the question of garbage collection for packfile objects; is there any? Both my current day job project and (I'm guessing) mod_perl both hope the answer is "yes". :-)
