[Pugs] Stumbled into another Pugs sand trap (indirect object call I think)

[Andrew Savige]

# cat h3.p6
my $label = 'abc';
print("$label: is this new indirect object call business?\n");

# perl -w h3.p6
abc: is this new indirect object call business?

# pugs h3.p6
Undefined variable $label:
Var "$label:"

I've lost count of the number of punishing Pugs hazards that have
snared me in my quest to convert a little p5 program to a real live
working p6/Pugs one. This was the latest one, I expect due to my
ignorance of new indirect object call. Anyway, thought you'd like
to know. Believe or not, I'm almost done. ^.^

/-\

Find local movie times and trailers on Yahoo! Movies.
http://au.movies.yahoo.com

[Autrijus Tang]

On Fri, Mar 18, 2005 at 12:20:31AM -0700, Luke Palmer wrote:
> That's actually because of the list of allowed characters in a variable
> name included : to support $Foo::bar. Unfortuately, it would also
> support $Fo:oba:r, and your $label . It appears to be fixed as of r868.

Hey. Is "&infix:Y" a valid variable name?

Thanks,
/Autrijus/

[Autrijus Tang]

On Fri, Mar 18, 2005 at 05:39:49PM +1100, Andrew Savige wrote:
> # cat h3.p6
> my $label = 'abc';
> print("$label: is this new indirect object call business?\n");
>
> # perl -w h3.p6
> abc: is this new indirect object call business?
>
> # pugs h3.p6
> Undefined variable $label:
> Var "$label:"

Dear mad golfer, it was caused by the rather unforgiving Parsec
that <commit> by default, so I added "try" to (string "::") and
now it won't barf after seeing a colon. As of r868 it should
now work fine.

> I've lost count of the number of punishing Pugs hazards that have
> snared me in my quest to convert a little p5 program to a real live
> working p6/Pugs one. This was the latest one, I expect due to my
> ignorance of new indirect object call. Anyway, thought you'd like
> to know. Believe or not, I'm almost done. ^.^

Woot! I'd like to see that program once you finished it. :)

Thanks,
/Autrijus/

[Luke Palmer]

Andrew Savige writes:
> # cat h3.p6
> my $label = 'abc';
> print("$label: is this new indirect object call business?\n");
>
> # perl -w h3.p6
> abc: is this new indirect object call business?
>
> # pugs h3.p6
> Undefined variable $label:
> Var "$label:"

That's actually because of the list of allowed characters in a variable

name included : to support $Foo::bar. Unfortuately, it would also
support $Fo:oba:r, and your $label . It appears to be fixed as of r868.

Luke

[Autrijus Tang]

On Fri, Mar 18, 2005 at 12:25:26AM -0700, Luke Palmer wrote:
> Of course not. &infix:<Y> refers to the infix Y operator, but you need
> the hashy subscript.

So, what is the full name for the operator in the symbol table? :)

Thanks,
/Autrijus/

[Luke Palmer]

Of course not. &infix:<Y> refers to the infix Y operator, but you need
the hashy subscript.

Luke

[Andrew Savige]

--- Autrijus Tang <autr...@autrijus.org> wrote:
> Woot! I'd like to see that program once you finished it. :)

I've written up my experiences at:

http://www.perlmonks.org/?node_id=440685

I'll commit it to examples/golf after feedback is received.
Thanks for all your help!

[Larry Wall]

On Fri, Mar 18, 2005 at 03:27:04PM +0800, Autrijus Tang wrote:

%::{'&infix:<Y>'}, I suspect. &::('infix:<Y>') should also get to it
as a symbolic reference. Of course, it can actually be stored as "Woot!",
as long as you translate both directions. :-)

Larry

[Luke Palmer]

Larry Wall writes:
> On Fri, Mar 18, 2005 at 03:27:04PM +0800, Autrijus Tang wrote:
> : On Fri, Mar 18, 2005 at 12:25:26AM -0700, Luke Palmer wrote:
> : > Of course not. &infix:<Y> refers to the infix Y operator, but you need
> : > the hashy subscript.
> :
> : So, what is the full name for the operator in the symbol table? :)
>
> %::{'&infix:<Y>'}, I suspect.

I suspect that's a bad idea. What about &infix:{'<'}?

Perhaps there is a %infix: (in every appropriate scope) that holds
anonymous symbol table references:

%{%infix:{'Y'}}

And:

%{%::{'%infix:'}{'Y'}}

We might make the table lookup smart enough to do the right thing, but
then again, that may be a bad idea:

keys %::; # doesn't return &infix:<Y>

Luke

[Larry Wall]

On Fri, Mar 18, 2005 at 04:06:21PM -0700, Luke Palmer wrote:
: Larry Wall writes:
: > %::{'&infix:<Y>'}, I suspect.

:
: I suspect that's a bad idea. What about &infix:{'<'}?

Well, one could go with &infix:«<» in that case, but yes, one could
always construct an operator that violates all the standard quotes.
I was thinking of it as just stealing the hash notation for another
purpose, but real hashes have the advantage of delimiting their keys
and values out of band.

: Perhaps there is a %infix: (in every appropriate scope) that holds

: anonymous symbol table references:
:
: %{%infix:{'Y'}}
:
: And:
:
: %{%::{'%infix:'}{'Y'}}

Maybe it's just too early in the morning/week/year, but I don't
understand why you're putting the outer %{}. It seems like

%::{'%infix:'}{'Y'}

would be sufficient. So should

%::<%infix:><Y>

: We might make the table lookup smart enough to do the right thing, but
: then again, that may be a bad idea:
:
: keys %::; # doesn't return &infix:<Y>

It'd presumably return '%infix:' as the key of one of its hash values,
which actually seems like it might be useful and efficient when it
happens you're trying to generate a list of infix operators. As long
as the &infix: token prefix is syntactically smart enough to return a
reference to %::<%infix:>, the standard &infix:<Y> notation could even
be a hash lookup at run-time. The main problem with that, of course,
is that things like operators are where you want the optimizer to
have as much information as possible at compile time. We'd have to
have some way of representing to the compiler that it's okay to do
that lookup at compile time, and assume someone isn't changing the
symbol table out from under you. Actually, it should probably assume
that by default, and the people who are wanting to doctor the symbol
table at run time should have to make the explicit representations.

Larry