On Aug-26, Leopold Toetsch wrote: > Steve Fink wrote: > > >I can store some global counter that makes it generate different sub > >names each time, but that seems a bit hackish given that I don't really > >want the subroutine to be globally visible anyway; I'm just using one so > >that I can use PIR's support for handling return values. > > I don't think its hackish. And you might want to keep the compiled regex > around for later (and repeated) invocation.
I certainly do, but I can always do that by remembering the PMC returned from the compile op myself. > Visibility is another issue though. You could mangle[1] the subroutine > name or use a distinct namespace, which might reduce the possibility of > name collisions. > > leo > > .sub @regex_at_foo_imc_line_4711 # e.g. > .end Yes, this illustrates what I was really getting at. My compiler can certainly take a subroutine name (or file and line number, or whatever) to use to generate the code with, but what is the proper way to pass that infomation in through the compile op? I can just stick it in some register, but it seems like there ought to be some standard-ish way of passing parameters to compilers. Which then makes me wonder why compile is done as an opcode rather than a method invocation on the return value of compreg. I see that for Compiler and NCI PMCs, that's exactly what it does, but for anything else it does the Parrot_runops_fromc_args_save thing; couldn't that be somehow exposed separately so that the compile op goes away? My only complaint about C<compile> is that it isn't transparent how to use it, whereas I am comfortable with invoking things and following the calling conventions.
