Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Perl: porters

[perl #114414] indirect object heuristic misparses foo bar->baz

 

 

Perl porters RSS feed   Index | Next | Previous | View Threaded


perlbug-followup at perl

Aug 7, 2012, 6:47 AM

Post #1 of 10 (373 views)
Permalink
[perl #114414] indirect object heuristic misparses foo bar->baz

# New Ticket Created by l.mai [at] web
# Please include the string: [perl #114414]
# in the subject line of all future correspondence about this issue.
# <URL: https://rt.perl.org:443/rt3/Ticket/Display.html?id=114414 >



This is a bug report for perl from l.mai [at] web,
generated with the help of perlbug 1.39 running under perl 5.16.0.


-----------------------------------------------------------------
[Please describe your issue here]

Let's create a dog and wash it:

% perl -MO=Deparse -e '{package Dog} sub wash {}' -e 'wash Dog->new;'
{;};
sub wash {

}
'Dog'->wash->new;
-e syntax OK


Wait, that's not what I meant! Maybe like this?

% perl -MO=Deparse -e '{package Dog} sub wash {}' -e 'wash Dog::->new;'
{;};
sub wash {

}
'Dog'->wash->new;
-e syntax OK


No, same problem. Hmm ...

% perl -MO=Deparse -e '{package Dog} sub wash {}' -e 'wash ::Dog->new;'
{;};
sub wash {

}
wash '::Dog'->new;
-e syntax OK


OK, that at least parses the sub call correctly. But:

% perl -e '{package Dog} sub wash {}' -e 'wash ::Dog->new;'
Can't call method "new" without a package or object reference at -e line 2.


Looks like '::Dog' doesn't work as 'Dog'. Finally:

% perl -MO=Deparse -e '{package Dog} sub wash {}' -e 'wash +Dog->new;'
{;};
sub wash {

}
wash 'Dog'->new;
-e syntax OK


This is what I wanted all along.

I think the indirect object heuristic is too trigger-happy and should be dialed
back a bit. 'foo bar->baz' should not be parsed as an indirect invocation of
'bar->foo', especially not if the parser knows 'foo' to be a sub in the current
scope.

In fact, I'd be glad to see indirect object syntax simply go away completely
(except for builtin special cases like print/system/exec/etc). Otherwise, a
pragma to disable it would be nice[1]. Otherwise, the parser should prefer the
non-indirect-object interpretation of code where possible.


[1]
'no indirect' is a nice pragma but it doesn't disable indirect object syntax;
it just recognizes it and makes it into an error after the fact. That is, the
default interpretation of my first example is silently wrong, 'no indirect'
makes it loudly wrong, and I want it to be silently right.

[Please do not change anything below this line]
-----------------------------------------------------------------
---
Flags:
category=core
severity=medium
---
This perlbug was built using Perl 5.12.1 - Thu Jun 3 20:09:15 CEST 2010
It is being executed now by Perl 5.16.0 - Mon May 21 12:24:16 CEST 2012.

Site configuration information for perl 5.16.0:

Configured by mauke at Mon May 21 12:24:16 CEST 2012.

Summary of my perl5 (revision 5 version 16 subversion 0) configuration:

Platform:
osname=linux, osvers=2.6.38-gentoo-r6, archname=i686-linux
uname='linux nora 2.6.38-gentoo-r6 #1 preempt sat aug 6 03:05:34 cest 2011 i686 amd athlon(tm) 64 processor 3200+ authenticamd gnulinux '
config_args='-Dcc=cgcc -Dprefix=/home/mauke/usr/local -Dman1dir=none -Dman3dir=none -Dinc_version_list=none -Doptimize=-O2 -flto'
hint=recommended, useposix=true, d_sigaction=define
useithreads=undef, usemultiplicity=undef
useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
use64bitint=undef, use64bitall=undef, uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='cgcc', ccflags ='-fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
optimize='-O2 -flto',
cppflags='-fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include'
ccversion='', gccversion='4.6.3', gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
alignbytes=4, prototype=define
Linker and Libraries:
ld='cgcc', ldflags ='-fstack-protector -L/usr/local/lib -O2 -flto'
libpth=/usr/local/lib /lib/../lib /usr/lib/../lib /lib /usr/lib
libs=-lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lc -lgdbm_compat
perllibs=-lnsl -ldl -lm -lcrypt -lutil -lc
libc=/lib/libc-2.14.1.so, so=so, useshrplib=false, libperl=libperl.a
gnulibc_version='2.14.1'
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
cccdlflags='-fPIC', lddlflags='-shared -O2 -flto -L/usr/local/lib -fstack-protector'

Locally applied patches:
SAVEARGV0 - disable magic open in <ARGV>

---
@INC for perl 5.16.0:
/home/mauke/usr/local/lib/perl5/site_perl/5.16.0/i686-linux
/home/mauke/usr/local/lib/perl5/site_perl/5.16.0
/home/mauke/usr/local/lib/perl5/5.16.0/i686-linux
/home/mauke/usr/local/lib/perl5/5.16.0
.

---
Environment for perl 5.16.0:
HOME=/home/mauke
LANG=en_US.UTF-8
LANGUAGE (unset)
LC_COLLATE=POSIX
LD_LIBRARY_PATH=/home/mauke/usr/local/lib
LOGDIR (unset)
PATH=/home/mauke/usr/perlbrew/bin:/home/mauke/usr/local/bin:/usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/i686-pc-linux-gnu/gcc-bin/4.4.5:/opt/sun-jdk-1.4.2.13/bin:/opt/sun-jdk-1.4.2.13/jre/bin:/opt/sun-jdk-1.4.2.13/jre/javaws:/opt/dmd/bin:/usr/games/bin
PERLBREW_BASHRC_VERSION=0.43
PERLBREW_HOME=/home/mauke/.perlbrew
PERLBREW_PATH=/home/mauke/usr/perlbrew/bin
PERLBREW_ROOT=/home/mauke/usr/perlbrew
PERLBREW_VERSION=0.27
PERL_BADLANG (unset)
PERL_UNICODE=SAL
SHELL=/bin/bash


eda at waniasset

Aug 7, 2012, 7:18 AM

Post #2 of 10 (361 views)
Permalink
Re: [perl #114414] indirect object heuristic misparses foo bar->baz [In reply to]

via RT <l.mai <at> web.de> writes:

>In fact, I'd be glad to see indirect object syntax simply go away completely
>(except for builtin special cases like print/system/exec/etc).

I think 'new' should be special-cased too.

--
Ed Avis <eda [at] waniasset>


c.nehren/p5p at shadowcat

Aug 7, 2012, 7:21 AM

Post #3 of 10 (363 views)
Permalink
Re: [perl #114414] indirect object heuristic misparses foo bar->baz [In reply to]

On Tue, Aug 07, 2012 at 14:18:11 +0000 , Ed Avis wrote:
> via RT <l.mai <at> web.de> writes:
>
> >In fact, I'd be glad to see indirect object syntax simply go away completely
> >(except for builtin special cases like print/system/exec/etc).
>
> I think 'new' should be special-cased too.

Please no. This only exacerbates the problem of indirect object syntax
(which I agree should go away completely), sweeping the problem under
the rug and adding more complexity without solving the problem. It's a
net loss on all sides.

--
Chris Nehren | Coder, Sysadmin, Masochist
Shadowcat Systems Ltd. | http://shadowcat.co.uk/


fawaka at gmail

Aug 7, 2012, 7:23 AM

Post #4 of 10 (363 views)
Permalink
Re: [perl #114414] indirect object heuristic misparses foo bar->baz [In reply to]

On Tue, Aug 7, 2012 at 4:47 PM, l.mai [at] web <perlbug-followup [at] perl> wrote:
> I think the indirect object heuristic is too trigger-happy and should be dialed
> back a bit. 'foo bar->baz' should not be parsed as an indirect invocation of
> 'bar->foo', especially not if the parser knows 'foo' to be a sub in the current
> scope.

You're forgetting this scenario: «new Foo->bar». I'd expect this to be
far more common, if only because this is how many other language
operate. IMHO changing it to do something subtle different is just a
lot of trouble for no benefit.

> In fact, I'd be glad to see indirect object syntax simply go away completely
> (except for builtin special cases like print/system/exec/etc). Otherwise, a
> pragma to disable it would be nice[1]. Otherwise, the parser should prefer the
> non-indirect-object interpretation of code where possible.

Everybody likes to hate indirect object syntax. I never use it, and
wouldn't mind it being gone it, but rarely get bitten by it.

Leon


fawaka at gmail

Aug 7, 2012, 7:23 AM

Post #5 of 10 (362 views)
Permalink
Re: [perl #114414] indirect object heuristic misparses foo bar->baz [In reply to]

On Tue, Aug 7, 2012 at 5:21 PM, Chris Nehren
<c.nehren/p5p [at] shadowcat> wrote:
> On Tue, Aug 07, 2012 at 14:18:11 +0000 , Ed Avis wrote:
>> via RT <l.mai <at> web.de> writes:
>>
>> >In fact, I'd be glad to see indirect object syntax simply go away completely
>> >(except for builtin special cases like print/system/exec/etc).
>>
>> I think 'new' should be special-cased too.
>
> Please no. This only exacerbates the problem of indirect object syntax
> (which I agree should go away completely), sweeping the problem under
> the rug and adding more complexity without solving the problem. It's a
> net loss on all sides.

+1


eda at waniasset

Aug 7, 2012, 8:10 AM

Post #6 of 10 (361 views)
Permalink
Re: [perl #114414] indirect object heuristic misparses foo bar->baz [In reply to]

I wanted to make the point that if you intend to get rid of dative syntax,
perhaps 80% of the uses of it are for constructors, which by convention are
called 'new'. To simplify the grammar while avoiding as far as possible the
breakage of existing code, you could restrict the syntax to constructors.

If that's not an option, I would prefer to keep the indirect object syntax rather
than remove it altogether.

--
Ed Avis <eda [at] waniasset>


c.nehren/p5p at shadowcat

Aug 7, 2012, 8:41 AM

Post #7 of 10 (362 views)
Permalink
Re: [perl #114414] indirect object heuristic misparses foo bar->baz [In reply to]

On Tue, Aug 07, 2012 at 15:10:14 +0000 , Ed Avis wrote:
> I wanted to make the point that if you intend to get rid of dative syntax,
> perhaps 80% of the uses of it are for constructors, which by convention are
> called 'new'. To simplify the grammar while avoiding as far as possible the
> breakage of existing code, you could restrict the syntax to constructors.

I'm not sure I understand how adding a special case simplifies the
grammar. This only promotes 'new' to a position of specialness. Perl's
OO is as flexible as it is--it supports everything from inside-out
objects to Moose--because we provide mechanism, not policy. Making 'new'
special is providing policy, sharply in opposition to how things usually
work in Perl.

--
Chris Nehren | Coder, Sysadmin, Masochist
Shadowcat Systems Ltd. | http://shadowcat.co.uk/


xdaveg at gmail

Aug 7, 2012, 2:23 PM

Post #8 of 10 (352 views)
Permalink
Re: [perl #114414] indirect object heuristic misparses foo bar->baz [In reply to]

On Tue, Aug 7, 2012 at 9:47 AM, l.mai [at] web <perlbug-followup [at] perl> wrote:
> In fact, I'd be glad to see indirect object syntax simply go away completely
> (except for builtin special cases like print/system/exec/etc). Otherwise, a
> pragma to disable it would be nice[1]. Otherwise, the parser should prefer the
> non-indirect-object interpretation of code where possible.

+1

My preference: indirect object syntax (except for built-in special
cases) gets deprecated under "use v5.18" and then removed under "use
v5.18+N" where N is whatever our deprecation policy turns out to be.

-- David


abigail at abigail

Aug 7, 2012, 2:34 PM

Post #9 of 10 (355 views)
Permalink
Re: [perl #114414] indirect object heuristic misparses foo bar->baz [In reply to]

On Tue, Aug 07, 2012 at 03:10:14PM +0000, Ed Avis wrote:
> I wanted to make the point that if you intend to get rid of dative syntax,
> perhaps 80% of the uses of it are for constructors, which by convention are
> called 'new'. To simplify the grammar while avoiding as far as possible the
> breakage of existing code, you could restrict the syntax to constructors.
>
> If that's not an option, I would prefer to keep the indirect object syntax rather
> than remove it altogether.
>


Perl already has a constructor, it's special cased (as in, it's a keyword),
and it's spelled "bless".



Abigail


abigail at abigail

Aug 7, 2012, 2:43 PM

Post #10 of 10 (354 views)
Permalink
Re: [perl #114414] indirect object heuristic misparses foo bar->baz [In reply to]

On Tue, Aug 07, 2012 at 06:47:50AM -0700, l.mai [at] web wrote:
> # New Ticket Created by l.mai [at] web
> # Please include the string: [perl #114414]
> # in the subject line of all future correspondence about this issue.
> # <URL: https://rt.perl.org:443/rt3/Ticket/Display.html?id=114414 >
>
>
>
> This is a bug report for perl from l.mai [at] web,
> generated with the help of perlbug 1.39 running under perl 5.16.0.
>
>
> -----------------------------------------------------------------
> [Please describe your issue here]
>
> Let's create a dog and wash it:
>
> % perl -MO=Deparse -e '{package Dog} sub wash {}' -e 'wash Dog->new;'
> {;};
> sub wash {
>
> }
> 'Dog'->wash->new;
> -e syntax OK
>
>
> Wait, that's not what I meant! Maybe like this?
>
> % perl -MO=Deparse -e '{package Dog} sub wash {}' -e 'wash Dog::->new;'
> {;};
> sub wash {
>
> }
> 'Dog'->wash->new;
> -e syntax OK
>
>
> No, same problem. Hmm ...
>
> % perl -MO=Deparse -e '{package Dog} sub wash {}' -e 'wash ::Dog->new;'
> {;};
> sub wash {
>
> }
> wash '::Dog'->new;
> -e syntax OK
>
>
> OK, that at least parses the sub call correctly. But:
>
> % perl -e '{package Dog} sub wash {}' -e 'wash ::Dog->new;'
> Can't call method "new" without a package or object reference at -e line 2.
>
>
> Looks like '::Dog' doesn't work as 'Dog'. Finally:
>
> % perl -MO=Deparse -e '{package Dog} sub wash {}' -e 'wash +Dog->new;'
> {;};
> sub wash {
>
> }
> wash 'Dog'->new;
> -e syntax OK
>
>
> This is what I wanted all along.
>
> I think the indirect object heuristic is too trigger-happy and should be dialed
> back a bit. 'foo bar->baz' should not be parsed as an indirect invocation of
> 'bar->foo', especially not if the parser knows 'foo' to be a sub in the current
> scope.
>
> In fact, I'd be glad to see indirect object syntax simply go away completely
> (except for builtin special cases like print/system/exec/etc). Otherwise, a
> pragma to disable it would be nice[1]. Otherwise, the parser should prefer the
> non-indirect-object interpretation of code where possible.
>
>
> [1]
> 'no indirect' is a nice pragma but it doesn't disable indirect object syntax;
> it just recognizes it and makes it into an error after the fact. That is, the
> default interpretation of my first example is silently wrong, 'no indirect'
> makes it loudly wrong, and I want it to be silently right.


Is this indirect object heuristic, or bare word heuristics?

$ perl -MO=Deparse -e '{package Dog} sub wash {} wash "Dog" -> new'
{;};
sub wash {

}
wash 'Dog'->new;
-e syntax OK
$


If you don't want to get bitten by Perl having to guess what you mean,
one could also just quote their barewords.



Abigail

Perl porters RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.