On Aug-22, Leopold Toetsch wrote: > Steve Fink <[EMAIL PROTECTED]> wrote: > > I am experimenting with registering my own compiler for the "regex" > > language, but the usage is confusing. It seems that the intention is > > that compilers will return a code object that gets invoked, at which > > time it runs until it hits an C<end> opcode. But what if I want to > > return some values from the compiled code? I see the following > > options: > > An Eval object isa Closure. The only difference to a subroutine is IIRC, > that if supports direct jumps out of the evaled code segment via the > inter-segment branch_cs opcode: > > . > . > . > > Thus it should be totally valid to return a Sub or Closure object from > your compiler. The C<invoke> of these two handles the packfile segment > switching. > > > $P0 = compreg "pig-latin" > > $P1 = compile $P0, "eturnray oneay oremay anthay asway assedpay inay" > > $I0 = $P1(41) > > print $I0 # Should print out 42 > > That's fine.
Ok, that makes sense. I didn't realize the relationship between the Eval PMC and Sub. Thanks. So then what is the proper way to return a Sub from the compile op? Right now, I always compile to the same subroutine name "_regex", and fetch it using find_global _regex. This works, even when I compile multiple chunks of regex code. I guess whatever is entering things into the global symbol table is overriding the previous definition, and I grab it out immediately thereafter. But is this safe to rely on, or will it later become an error to override a global subroutine? 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.
