Beefy Boxes and Bandwidth Generously Provided by pair Networks
more useful options
 
PerlMonks  

Context: compile-time vs. run-time

by shmem (Canon)
on Jan 25, 2009 at 15:09 UTC ( #738778=perlquestion: print w/ replies, xml ) Need Help??
shmem has asked for the wisdom of the Perl Monks concerning the following question:

I have been reading kyle's Context tutorial. Now I just wonder - how much of context is compile-time, how much run-time? Has that been discussed yet?

I ask because

perl -le 'my $f = 1; ($f > 0 ? @a : $a ) = ("a", "b", "c")' Assignment to both a list and a scalar at -e line 1, at EOF Execution of -e aborted due to compilation errors.

could be resolved at run-time, which isn't, because it barfs at compile-time. This works, however:

perl -le 'my $f = -1; ($f > 0 ? @a : @b ) = ("a", "b", "c"); print "a: + @a\nb: @b"' a: b: a b c perl -le 'my $f = 1; ($f > 0 ? @a : @b ) = ("a", "b", "c"); print "a: +@a\nb: @b"' a: a b c b:

update: diagnostics tells me that

Execution of -e aborted due to compilation errors (#1)
(F) If you assign to a conditional operator, the 2nd and 3rd arguments
must either both be scalars or both be lists. Otherwise Perl won't
know which context to supply to the right side.

which looks like establishing the context for the RHS is a compile-time thing. Is there such a thing as runtime context resolving, at all?

Comment on Context: compile-time vs. run-time
Select or Download Code
Re: Context: compile-time vs. run-time
by Anonymous Monk on Jan 25, 2009 at 16:17 UTC
    String-eval is the only way to get run-time context resolving.

      If that's the case, it isn't either - since first thing string eval does is to compile.

        I think he means to modify the code to eval.
        eval +($f > 0 ? '@a' : '$a' ) . ' = ("a", "b", "c")';
        But its still runtime for shmem :)
        D:\>cat shmem #!/usr/bin/perl print "Hi, i'm shmem, this is runtime for me\n"; eval "use shmem; its still runtime for shmem\n"; warn $@ if $@; D:\>perl shmem Hi, i'm shmem, this is runtime for me Can't locate shmem.pm in @INC (@INC contains: C:/Perl/lib C:/Perl/site +/lib .) at (eval 1) li ne 1. BEGIN failed--compilation aborted at (eval 1) line 1. D:\> D:\>cat shmem2 #!/usr/bin/perl print "Hi, i'm shmem, this is runtime for me\n"; eval "use CGI; its still runtime for shmem\n"; warn $@ if $@; D:\>perl shmem2 Hi, i'm shmem, this is runtime for me Can't locate object method "its" via package "still" (perhaps you forg +ot to load "still"?) at (eval 1) line 1. D:\>
Re: Context: compile-time vs. run-time
by ikegami (Pope) on Jan 25, 2009 at 16:50 UTC

    At compile-time, the context is set to one of the following:

    • Void
    • Scalar
    • List
    • From subroutine's caller

    An operator cannot control context at run-time. It cannot be any other way because operators are executed after their operands. Consider

    @x = ( f(), g(), h() );

    There are four ops on the RHS of the assignment. In the order they are called, they are:

    1. entersub(f): Calls f and leaves result on the stack
    2. entersub(g): Calls g and leaves result on the stack
    3. entersub(h): Calls h and leaves result on the stack
    4. list: Filters all but the last element off the stack in scalar context. No-op otherwise

    The list operator never has a chance to control the context of its operands since they've already been evaluated by the time the list operator is evaluated.

    That is actually the source of a known bug in Perl. What follows explains it. At compile-time, the contexts in which the above operators are evaluated are set as follows:

    1. entersub(f): List
    2. entersub(g): List
    3. entersub(h): List
    4. list: List [*]

    And it works well. It also works well in scalar context:

    $x = ( f(), g(), h() );
    1. entersub(f): Void
    2. entersub(g): Void
    3. entersub(h): Scalar
    4. list: Scalar

    And in void context:

    ( f(), g(), h() ); 1;
    1. entersub(f): Void
    2. entersub(g): Void
    3. entersub(h): Void
    4. list: Void

    And now we're left with the fourth case:

    sub { ( f(), g(), h() ) }
    1. entersub(f): From subroutine's caller
    2. entersub(g): From subroutine's caller
    3. entersub(h): From subroutine's caller
    4. list: From subroutine's caller

    If we call the subroutine as

    @x = sub { ( f(), g(), h() ) }->();

    then all's fine:

    1. entersub(f): From subroutine's caller: List
    2. entersub(g): From subroutine's caller: List
    3. entersub(h): From subroutine's caller: List
    4. list: From subroutine's caller: List

    But if we call the subroutine as

    $x = sub { ( f(), g(), h() ) }->();

    we have a bug!

    1. entersub(f): From subroutine's caller: Scalar: should be void!
    2. entersub(g): From subroutine's caller: Scalar: should be void!
    3. entersub(h): From subroutine's caller: Scalar
    4. list: From subroutine's caller: Scalar

    Some code to support what I said:

    use strict; use warnings; sub cx { print !defined(wantarray()) ? 'v' : !wantarray() ? 's' : 'l'; } my ($x, @x); print('v: '); ( cx(), cx(), cx() ) ; print("\n"); print('cv: '); sub { ( cx(), cx(), cx() ) }->(); print("\n\n"); print('s: '); $x = ( cx(), cx(), cx() ) ; print("\n"); print('cs: '); $x = sub { ( cx(), cx(), cx() ) }->(); print("\n\n"); print('l: '); @x = ( cx(), cx(), cx() ) ; print("\n"); print('cl: '); @x = sub { ( cx(), cx(), cx() ) }->(); print("\n");
    v: vvv cv: vvv s: vvs \ mismatch cs: sss / l: lll cl: lll

    A practical difference:

    use strict; use warnings; my $x; $x = ( 'abc', 'def' ) ; # Warns $x = sub { ( 'abc', 'def' ) }->(); # Doesn't warn
    Useless use of a constant in void context at line 5.

    * — A list op in list context is subsequently optimized away since it's a no-op there. This does not affect the results.

Re: Context: compile-time vs. run-time
by ikegami (Pope) on Jan 25, 2009 at 22:32 UTC

    perl -le 'my $f = 1; ($f > 0 ? @a : $a ) = ("a", "b", "c")'
    Assignment to both a list and a scalar at -e line 1, at EOF

    Keep in mind that there are two different "=" operators: the list assignment operator (aassign) and the scalar assignment operator (sassign). The selection of the operator is based on whether the LHS of the assignment is list-ish or scalar-ish. The reason the above doesn't compile isn't the inability to change context at run-time, it's the inability to select an operator.

    The two operators compared:

    Context Imposed on OperandsStack on InputInEvaluates ToStack on Output
    sassignscalarTwo SVsscalarLHS as an aliasOne SV
    listLHS as an aliasOne SV
    lassignlistTwo marked lists of SVsscalarNumber of items in list returned by the RHSOne SV
    listLHS as a list of aliasesOne (unmarked) list of SVs

    Notice the significant differences in how Perl needs to setup the stack before the operator is called, making the choice of operators crucial.

Re: Context: compile-time vs. run-time
by Anonymous Monk on Oct 20, 2010 at 14:06 UTC

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://738778]
Approved by Corion
Front-paged by ikegami
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others drinking their drinks and smoking their pipes about the Monastery: (6)
As of 2014-08-30 00:42 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    The best computer themed movie is:











    Results (289 votes), past polls