in reply to Re: my TYPE EXPR ?
in thread my TYPE EXPR ?

I should have made clearer what I meant with "run time checking or code optimization..."

"run time checking"

If I'm indexing with $i into an array, its clear that $i should never be a string or a ref.

So flagging the type with  my int $i; could help checking at runtime (or compile-time) if ever something else than an integer was assigned to $i and consequently raising an error. (maybe using a "static" bit)²

"code optimization"

you mentioned JIT-compiler, the old Panther mentions a C-converter (most likely B::CC) to take advantage of it.

To avoid further misunderstandings I'm thinking about little snippets, embedded for time-critical loops, but much easier and intuitive than with XS.

The python community uses cython for this purpose facilitating to embed C-code.

my motivation

I'm writing a little hack emitting elisp snippets out of Perl-Code by translating the optree.

(mainly because I hate writing lisp syntax)

Actually I have to take care for implicit type conversions:

--- example
something like "abc".$i can't simply be translated to (concat "abc" i) because I get a Wrong type argument if $i is a integer.

Sure, this can easily be solved by defining an "perl operator like" function pl-concat which does the needed type conversion. This slows down execution but normally thats not too important in emacs. 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.

Unfortunately I can't read out of the opcodes if $i was explicitly declared as of TYPE integer¹, I have to realize workarounds (e.g naming conventions like $i_INT) to transport this information.

future ???

I could read out of the old panther that this kind of usage was intended and it seems natural. Furthermore the docs read like the old usage of fields is deprecated now.

So what are the plans/use cases for TYPE?

Or is it completely deprecated now?

Cheers Rolf

UPDATES:

¹) Example:

perl -MO=Concise -e '{package int}; my int $y' 8 <@> leave[1 ref] vKP/REFC ->(end) 1 <0> enter ->2 2 <;> nextstate(main 2 -e:1) v:{ ->3 5 <2> leaveloop vK/2 ->6 3 <{> enterloop(next->5 last->5 redo->4) v ->4 4 <0> stub v ->5 6 <;> nextstate(main 2 -e:1) v:{ ->7 7 <0> padsv[$y:2,3] vM/LVINTRO ->8
line 7 doesn't change if write my $y instead.

²) Of course this could be achieved using tie, but much slower and with more verbose code.

Replies are listed 'Best First'.
Re^3: my TYPE EXPR ?
by ikegami (Patriarch) on Apr 21, 2010 at 15:28 UTC

    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.

      Thanks.

      For what I see TYPE is mostly deprectaed and there are no plans to turn it into something useful.

      Sad ...

      ... at least my needs can be covered with attribute handlers as a work around.

      Cheers Rolf

Re^3: my TYPE EXPR ?
by kennethk (Abbot) on Apr 21, 2010 at 14:13 UTC
    To avoid further misunderstandings I'm thinking about little snippets, embedded for time-critical loops, but much easier and intuitive than with XS.

    The python community uses cython for this purpose facilitating to embed C-code.

    And if you want something easier than XS, you can use the Inline family of modules (featuring Inline::C) that will build the XS glue code for you.

      Thanks, I forgot about Inline::C!

      It's for sure great but doesn't go all the way Cython seems to try.

      My idea is to facilitate the migration form Perl to C and vice versa (within the borders of a reasonable intersection of syntax and semantics).

      Cheers Rolf