I should have made clearer what I meant with "run time checking or code optimization..."
I only commented on the "or code optimisation" aspect.
you mentioned JIT-compiler, the old Panther mentions a C-converter
There's an active project to JIT-compile Perl. The library uses some kind of byte code, not C.
To avoid further misunderstandings I'm thinking about little snippets, embedded for time-critical loops
I don't see how this matters.
something like "abc".$i can't simply be translated to (concat "abc" i)
Sure it can. That's exactly what Perl does. You just didn't define concat properly if you want Perl semantics. It should be doing stringify(get_magic()) on its args.
But you're not trying to get Perl semantics according to what you said before, so I don't see why this is a problem. This entire problem only exists if you try to reimplement Perl semantics rather than just adopting its syntax.
elisp using Perl syntax:
"abc".stringify($i)
elisp generated:
concat( "abc" stringify(i) )
But if I could give the compiler a static hint that $i is an integer, I could make pl-concat a macro which generates the appropriate code at compile time.
That's exactly what my post discusses. I used addition since you said my Integer, but the same applies to concat.
1 padsv[$x] -> 2 2 padsv[$y] -> 3 3 concat_if_overloaded -> 11 if overloaded, 4 otherwise 4 swap_stack[0,1] -> 5 5 get_magic -> 6 6 stringify -> 7 7 swap_stack[0,1] -> 8 8 get_magic -> 9 9 stringify -> 10 10 concat_prestringified -> 11
Unfortunately I can't read out of the opcodes if $i was explicitly declared as of TYPE integer
Remember that I recommended a parser, not an opcode visitor.
Note: I don't know any version of Lisp.
Update: Moved a paragraph.
In reply to Re^3: my TYPE EXPR ?
by ikegami
in thread my TYPE EXPR ?
by LanX
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |