Localization and goto()

[p5pRT]

Migrated from rt.perl.org#1787 (status was 'resolved')

Searchable as RT1787$

[p5pRT]

From ilya@math.ohio-state.edu

$a = 5;
sub a { print $a }
sub b {local $b = 9; goto &a}
b;

This prints 5. "Should" not it print 9 instead?

Ilya

Perl Info

Site configuration information for perl 5.00562:

Configured by ilya at Fri Oct 15 19:37:24 EDT 1999.

Summary of my perl5 (revision 5.0 version 5 subversion 62) configuration:
  Platform:
    osname=os2, osvers=2.30, archname=os2
    uname='os2 karetnikova 2 2.30 i386 '
    config_args='-des -Dprefix=f:/perllib'
    hint=recommended, useposix=true, d_sigaction=define
    usethreads=undef useperlio=undef d_sfio=undef
    use64bits=undef usemultiplicity=undef
  Compiler:
    cc='gcc', optimize='-O2 -fomit-frame-pointer -malign-loops=2 -malign-jumps=2 -malign-functions=2 -s', gccversion=2.8.1
    cppflags='-Zomf -Zmt -DDOSISH -DOS2=2 -DEMBED -I. -I/usr/local/include -D_EMX_CRT_REV_=60'
    ccflags ='-Zomf -Zmt -DDOSISH -DOS2=2 -DEMBED -I. -I/usr/local/include -D_EMX_CRT_REV_=60'
    stdchar='char', d_stdstdio=define, usevfork=false
    intsize=4, longsize=4, ptrsize=4, doublesize=8
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
    alignbytes=4, usemymalloc=y, prototype=define
  Linker and Libraries:
    ld='gcc', ldflags ='-Zexe -Zomf -Zmt -Zcrtdll -Zstack 32000'
    libpth=f:/emx.add/lib f:/emx/lib D:/DEVTOOLS/OPENGL/LIB f:/emx/lib/mt
    libs=-lsocket -lm -lbsd
    libc=f:/emx/lib/mt/c_import.lib, so=dll, useshrplib=true, libperl=libperl.lib
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' '
    cccdlflags='-Zdll', lddlflags='-Zdll -Zomf -Zmt -Zcrtdll -s'

Locally applied patches:
    


@INC for perl 5.00562:
    lib
    f:/perllib/lib/5.00562/os2
    f:/perllib/lib/5.00562
    f:/perllib/lib/site_perl/5.00562/os2
    f:/perllib/lib/site_perl
    .


Environment for perl 5.00562:
    HOME=f:/home
    LANG=EN_US
    LANGUAGE (unset)
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=d:\NETSCAPE;d:\OPENDOC\EPM;d:\OPENDOC\OREXX;d:\OPENDOC\BIN;F:\DRV;f:\TOOLKIT\BETA\BIN\PMEISTER;f:\TOOLKIT\BETA\BIN;f:\TOOLKIT\BIN\OSARED;f:\TOOLKIT\SOM\COMMON;f:\TOOLKIT\SOM\BIN;f:\TOOLKIT\BIN;D:\OS2;D:\OS2\SYSTEM;F:\VABASIC\SOM\BIN;D:\OS2\INSTALL;D:\;D:\OS2\MDOS;D:\OS2\APPS;F:\BIN;F:\UTILS;F:\EMACS\19.33\BIN;F:\EMX.ADD\BIN;F:\EMX\BIN;F:\PBM;F:\EMTEX\bin;f:\ckermit;F:\PAGETURN;d:\tcpip\bin;D:\TCPIP\UMAIL;D:\VIEWER\BIN;F:\XFree86\bin;F:\VABASIC\BIN;F:\SMART;G:\EMX\BIN;d:\JAVAOS2\bin;D:\MMOS2;
    PERL_BADLANG (unset)
    SHELL (unset)

[p5pRT]

From @samtregar

$a = 5;
sub a { print $a }
sub b {local $b = 9; goto &a}
b;

This prints 5. "Should" not it print 9 instead?

What? No!

Maybe if you said "local $a = 9" it would!

-sam

[p5pRT]

From [Unknown Contact. See original ticket]

Sam Tregar writes​:

$a = 5;
sub a { print $a }
sub b {local $b = 9; goto &a}
b;

This prints 5. "Should" not it print 9 instead?

What? No!

Maybe if you said "local $a = 9" it would!

Thanks for this correction. My test script was busted, but my
conclusion is not​:

$a = 5;
sub a { print $a }
sub b {local $a = 9; goto &a}
b;

This still prints 5... :-(

Ilya

[p5pRT]

From [Unknown Contact. See original ticket]

$a = 5;
sub a { print $a }
sub b {local $a = 9; goto &a}
b;

This still prints 5... :-(

And this is a problem exactly how?

b()'s frame goes away. So its local view of $a
went away.

I do not find this behaviour astonishing.

--tom

[p5pRT]

From [Unknown Contact. See original ticket]

ilya@​math.ohio-state.edu wrote

$a = 5;

sub a { print $a }
sub b {local $b = 9; goto &a}
  $a
b;

This prints 5. "Should" not it print 9 instead?

That was my initial reaction, but the documentation suggests rather
strongly that *all* effects of b() are undone​:

  The `goto-&NAME' form is highly magical, and substitutes
  a call to the named subroutine for the currently running
  subroutine. This is used by `AUTOLOAD' subroutines that
  wish to load another subroutine and then pretend that
  the other subroutine had been called in the first place
  (except that any modifications to `@​_' in the current
  subroutine are propagated to the other subroutine.)

After the \`goto'\, not even \`caller\(\)' will be able to
tell that this routine was called first\.

Mike Guy

[p5pRT]

From [Unknown Contact. See original ticket]

On Tue, Nov 16, 1999 at 06​:08​:18AM -0700, Tom Christiansen wrote​:

$a = 5;
sub a { print $a }
sub b {local $a = 9; goto &a}
b;

This still prints 5... :-(

And this is a problem exactly how?

b()'s frame goes away. So its local view of $a went away.

This is an implementation detail. IIRC, it is documented that frame
is replaced, not goes away. What happens/should-happen with locals
during "replacement" is debatable.

I do not find this behaviour astonishing.

I never said it was. However, while not astonishing, it is
unpredictable. Different implementation might be possible. What
happens, however, is making some "normal programming constructs" much
harder to implement.

Ilya

[p5pRT]

From [Unknown Contact. See original ticket]

This is an implementation detail. IIRC, it is documented that frame
is replaced, not goes away. What happens/should-happen with locals
during "replacement" is debatable.

If something has been replaced, it has gone away and is no longer there.
If I replace your dog with a cat, you would not expect your new feline
to bark; the dog is long gone.

What happens, however, is making some "normal programming constructs"
much harder to implement.

Such as?

--tom

[p5pRT]

From [Unknown Contact. See original ticket]

Tom Christiansen writes​:

This is an implementation detail. IIRC, it is documented that frame
is replaced, not goes away. What happens/should-happen with locals
during "replacement" is debatable.

If something has been replaced, it has gone away and is no longer there.
If I replace your dog with a cat, you would not expect your new feline
to bark; the dog is long gone.

Whether a person ceases to exist after a sex change operation is
highly debatable.

What happens, however, is making some "normal programming constructs"
much harder to implement.

Such as?

In the particular case I needed it was

  local @​ISA = (@​ISA, 'DynaLoader');
  goto \&DynaLoader​::bootstrap;

Ilya

[p5pRT]

From [Unknown Contact. See original ticket]

ilya>> This is an implementation detail. IIRC, it is documented that frame
ilya>> is replaced, not goes away. What happens/should-happen with locals
ilya>> during "replacement" is debatable.

tom> If something has been replaced, it has gone away and is no longer there.
tom> If I replace your dog with a cat, you would not expect your new feline
tom> to bark; the dog is long gone.

ilya> Whether a person ceases to exist after a sex change operation is
ilya> highly debatable.

Let's chalk this one up to a language barrier.

  http​://work.ucsd.edu​:5141/cgi-bin/http_webster?replace

  1​: substitute a person or thing for (another that has ceased to
  fulfil its function); "He replaced the old razor blade"

  2​: take the place of [syn​: {supplant}, {supersede}, {supervene
  upon}]

  3​: put something back where it belongs [syn​: {put back}]

  4​: put in the place of another [syn​: {substitute}]

If a frame has been replaced, then that frame *has* gone away,
*has* been substituted for, *has* been supplanted, *has* been
superseded, and *has* been supervened upon. Your poor frame,
guardian and caretaker of an ephemeral setting of a shadowed @​ISA,
had the fatal misfortune and dubious design to find itself in the
wrong place at the wrong time. It's not just resting, playing
hooky, or changing its sex, for today is Garbage Day and the
Garbage Collectors have both come and gone. Your lamented frame
is not merely past its prime. It's an ex-frame. It's pushing up
malloc space. It's gone to the Happy Allocating Grounds in the sky.

It's a dead frame, Ilya.

ilya>> What happens, however, is making some "normal programming
ilya>> constructs" much harder to implement.

tom> Such as?

ilya> In the particular case I needed it was
ilya> local @​ISA = (@​ISA, 'DynaLoader');
ilya> goto \&DynaLoader​::bootstrap;

From the example you provided above, I see that, as it was with
"replaced", so too does your notion of "normal programming constructs"
differ significantly from my own. This particular disparity, however,
I am rather less quick to attribute to a misunderstanding of the English
language than I am to a misplaced projection of your own peculiar
practices onto the rest of the cosmos. Just because these constructs
might be normal in the sovereign state of Ilyania hardly implies that
they honestly deserve to be branded "normal programming constructs".
In fact, anything having to do with magical goto clearly belongs to a
completly disjoint set, that of "extra-ordinary programming constructs".

Be that as it may, I continue to fail to see any such ambiguity in the
description's wording that could theoretically permit some alternate,
conforming implementation to behave in a fashion different than the
way in which the current one behaves. And considering that no such
alternate implementation appears imminent, even if it were truly the
case that you were being insightful rather than obstreperous in your
most unusual reading of that passage, I still find little cause for
grave concern--unless, perchance, it should happen to be you yourself
who would end up the author of that hypothetical alternate implementation.

Could it be that your problem is nothing more than, having misunderstood
what "replaced" meant in the context of the cited documentation on magical
goto, that you have developed unfulfilled expectations as to how that
construct shall and should work with respect to storage recovery or any
other action associated with the now defunct frame? It might at this time
prove more expedient for you to attempt to devise some other mechanism by
which to accomplish whatever it is that you're actually trying to do here.

--tom

[p5pRT]

From [Unknown Contact. See original ticket]

Tom Christiansen <tchrist@​jhereg.perl.com> writes​:

$a = 5;
sub a { print $a }
sub b {local $a = 9; goto &a}
b;

This still prints 5... :-(

And this is a problem exactly how?

b()'s frame goes away.

One could expect the frame to stay until the "goto" returned ;-)

So its local view of $a
went away.

I do not find this behaviour astonishing.

--
Nick Ing-Simmons <nik@​tiuk.ti.com>
Via, but not speaking for​: Texas Instruments Ltd.

[p5pRT]

From [Unknown Contact. See original ticket]

One could expect the frame to stay until the "goto" returned ;-)

Don't we need a comefrom construct for that? :-)

--tom

[p5pRT]

From [Unknown Contact. See original ticket]

Ilya Zakharevich <ilya@​math.ohio-state.edu> writes​:

What happens, however, is making some "normal programming constructs"
much harder to implement.

Such as?

In the particular case I needed it was

local @​ISA = (@​ISA, 'DynaLoader');
goto \&DynaLoader​::bootstrap;

What is the snag with :

{
local @​ISA = (@​ISA, 'DynaLoader');
&DynaLoader​::bootstrap;
}

Is it that now caller() will see the wrapper?

--
Nick Ing-Simmons <nik@​tiuk.ti.com>
Via, but not speaking for​: Texas Instruments Ltd.

[p5pRT]

From [Unknown Contact. See original ticket]

Tom Christiansen writes​:

If a frame has been replaced, then that frame *has* gone away,

Absolutely not. The contents of the frame is different, but the frame
is still the same.

Ilya

[p5pRT]

From [Unknown Contact. See original ticket]

If a frame has been replaced, then that frame *has* gone away,

Absolutely not. The contents of the frame is different, but the frame
is still the same.

Brevity and sophistry do not a productive pairing make.

--tom

[p5pRT]

From [Unknown Contact. See original ticket]

Nick Ing-Simmons writes​:

In the particular case I needed it was

local @​ISA = (@​ISA, 'DynaLoader');
goto \&DynaLoader​::bootstrap;

What is the snag with :

{
local @​ISA = (@​ISA, 'DynaLoader');
&DynaLoader​::bootstrap;
}

This is what the wrapper is currently doing. But note that the
"depth" of the call to bootstrap() is different. In particular, any
special processing which "pseudo-unwinds" to upper frames (such as
error reporting by Carp) would see a "wrong" frame.

Apparently, undocumented magic of Carp hides this issue (I could not
solicit "wrong" messages with the above construct), but if goto would
work, it would be a bullet-proof way to do things.

Ilya