Mailing List Archive: Perl: porters

proposal: functional C<if>

1 2

View All

Index | Next | Previous | View Threaded

avarab at gmail

Apr 28, 2012, 6:21 AM

Post #26 of 39 (163 views)
Permalink

Re: proposal: functional C<if> [In reply to]

For what it's worth I once asked Larry Wall on #perl6 if he'd consider
making everything an expression in Perl 6, i.e. you could always stick
an assignment in front of any block.

He didn't like that for language design reasons, he thought that
expressions and blocks should be distinct constructs.

I think for Perl 5 it makes the most sense to just continue using do {}.

davidnicol at gmail

Apr 28, 2012, 1:53 PM

Post #27 of 39 (161 views)
Permalink

Re: proposal: functional C<if> [In reply to]

On Sat, Apr 28, 2012 at 8:21 AM, Ã†var ArnfjÃ¶rÃ° Bjarmason
<avarab [at] gmail> wrote:
> For what it's worth I once asked Larry Wall on #perl6 if he'd consider
> making everything an expression in Perl 6, i.e. you could always stick
> an assignment in front of any block.
>
> He didn't like that for language design reasons, he thought that
> expressions and blocks should be distinct constructs.
>
> I think for Perl 5 it makes the most sense to just continue using do {}.

( expression )
could always be
do { expression }

could it not?

--
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" are to be interpreted using situational ethics.

abigail at abigail

Apr 28, 2012, 2:12 PM

Post #28 of 39 (159 views)
Permalink

Re: proposal: functional C<if> [In reply to]

On Sat, Apr 28, 2012 at 03:53:23PM -0500, David Nicol wrote:
> On Sat, Apr 28, 2012 at 8:21 AM, Ævar Arnfjörð Bjarmason
> <avarab [at] gmail> wrote:
> > For what it's worth I once asked Larry Wall on #perl6 if he'd consider
> > making everything an expression in Perl 6, i.e. you could always stick
> > an assignment in front of any block.
> >
> > He didn't like that for language design reasons, he thought that
> > expressions and blocks should be distinct constructs.
> >
> > I think for Perl 5 it makes the most sense to just continue using do {}.
>
> ( expression )
> could always be
> do { expression }
>
> could it not?

No.

@a = ("foo") x 3;

isn't the same as

@a = do {"foo"} x 3;

("foo") [0]

is valid, but

do {"foo"} [0]

is a compile time error. OTOH,

sub foo ($) {...}
foo (1, 2);

is a compile time error, but

sub foo ($) {...}
foo do {1, 2};

is legal.

Abigail

zefram at fysh

Apr 28, 2012, 2:19 PM

Post #29 of 39 (161 views)
Permalink

Re: proposal: functional C<if> [In reply to]

David Nicol wrote:
>( expression )
>could always be
>do { expression }

Ooh, a new and vaguely sane idea! I was despairing of this thread.
Since an expression can always appear where a statement is permitted, by
virtue of expression statements, it would be syntactically feasible for
a context where only an expression can appear to be extended to accept a
statement or sequence thereof, provided that (a) the final semicolon of
a statement is allowed to be omitted and (b) an expression statement has
the same behaviour than the correspoding expression used to. This is not
(and should not be) specific to if-statements.

Watch out for scoping issues: "(my $a)" is not equivalent to "do{my $a}".
There's also a detail to sort out around null statements. I believe with
a bit of work you could have completely acceptable semantics for this,
and only have the aesthetics left to argue.

-zefram

zefram at fysh

Apr 28, 2012, 2:27 PM

Post #30 of 39 (160 views)
Permalink

Re: proposal: functional C<if> [In reply to]

Abigail wrote:
> @a = ("foo") x 3;
>isn't the same as
> @a = do {"foo"} x 3;

Yes, you'd need something slightly different from that to retain semantic
equivalence. The paren flags are hard.

> foo (1, 2);
...
> foo do {1, 2};

That's a grammatically distinct usage of the paren characters. I imagine
only the term and list-slice paren cases would be extended to contain
statements.

-zefram

abigail at abigail

Apr 28, 2012, 3:41 PM

Post #31 of 39 (159 views)
Permalink

Re: proposal: functional C<if> [In reply to]

On Sat, Apr 28, 2012 at 03:53:23PM -0500, David Nicol wrote:
> On Sat, Apr 28, 2012 at 8:21 AM, Ævar Arnfjörð Bjarmason
> <avarab [at] gmail> wrote:
> > For what it's worth I once asked Larry Wall on #perl6 if he'd consider
> > making everything an expression in Perl 6, i.e. you could always stick
> > an assignment in front of any block.
> >
> > He didn't like that for language design reasons, he thought that
> > expressions and blocks should be distinct constructs.
> >
> > I think for Perl 5 it makes the most sense to just continue using do {}.
>
> ( expression )
> could always be
> do { expression }
>
> could it not?
>

($foo) can appear in lvalue context, do {$foo} cannot:

($foo) = (1, 2); # $foo = 1

do {$foo} = (1, 2); # syntax error

Side-effects:

("foo" =~ /(.)/); say $1; # f

do {"foo" =~ /(.)/}; say $1; # undefined value

Abigail

pagaltzis at gmx

Apr 28, 2012, 4:44 PM

Post #32 of 39 (159 views)
Permalink

Re: proposal: functional C<if> [In reply to]

* Zefram <zefram [at] fysh> [2012-04-27 21:35]:
> So if-expression would be the purest kind of syntactic convenience.
> Given this, it would have to be extremely convenient in order to
> justify adding it to the language. Grammatical ambiguity, misleading
> appearance, and inconsistency with the rest of the grammar are just
> a few of the ways in which the proposed forms of if-expression would
> be inconvenient.

If anything I would have expected people proposing loops as expressions.
(Or conversely, adding some form of control flow to map/grep.) I donâ€™t
quite understand why if-expressions of all things are what people have
latched ontoâ€¦ they seem really useless to me in terms of either removing
impossibilities or raising clarity of the already possible.

Can anyone come up with even one example of expression-if where it makes
for clearer code than either statement-if (with duplicated assignments)
or a ternary? (In short, is there a point of adding this to the language
other than the sheer ability to do so?) Because I fail.

Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>

leonerd at leonerd

May 1, 2012, 8:11 AM

Post #33 of 39 (162 views)
Permalink

Re: proposal: functional C<if> [In reply to]

Several comments have been made, but I have one more:

If you want to consider equivalence between

my $var = $cond ? 1 : 2;
my $var = if($cond) { 1 } else { 2 };

Then why not also

my @squares = map { $_ * $_ } @nums;
my @squares = foreach (@nums) { $_ * $_ };

At which point we might consider what

my @values = while($cond) { EXPR };

might do.

Just a thought...

--
Paul "LeoNerd" Evans

leonerd [at] leonerd
ICQ# 4135350 | Registered Linux# 179460
http://www.leonerd.org.uk/

Attachments:

signature.asc (0.19 KB)

davidnicol at gmail

May 1, 2012, 8:24 AM

Post #34 of 39 (162 views)
Permalink

Re: proposal: functional C<if> [In reply to]

On Tue, May 1, 2012 at 10:11 AM, Paul LeoNerd Evans
<leonerd [at] leonerd> wrote:
> At which point we might consider what
>
> Â my @values = (while($cond) { EXPR });
>
> might do.
>
> Just a thought...

it seems clear that @values would wind up holding one of undef, 0, '',
or some overloaded reference that gives a false value in boolean
context..

ikegami at adaelis

May 1, 2012, 12:53 PM

Post #35 of 39 (161 views)
Permalink

Re: proposal: functional C<if> [In reply to]

On Tue, May 1, 2012 at 11:24 AM, David Nicol <davidnicol [at] gmail> wrote:

> On Tue, May 1, 2012 at 10:11 AM, Paul LeoNerd Evans
> <leonerd [at] leonerd> wrote:
> > At which point we might consider what
> >
> > my @values = (while($cond) { EXPR });
> >
> > might do.
> >
> > Just a thought...
>
> it seems clear that @values would wind up holding one of undef, 0, '',
> or some overloaded reference that gives a false value in boolean
> context..
>

It does not seem clear to me at all. Why would Perl do something useless? I
would expect a warning if not an error.

ikegami at adaelis

May 1, 2012, 12:55 PM

Post #36 of 39 (163 views)
Permalink

Re: proposal: functional C<if> [In reply to]

On Tue, May 1, 2012 at 3:53 PM, Eric Brine <ikegami [at] adaelis> wrote:

> On Tue, May 1, 2012 at 11:24 AM, David Nicol <davidnicol [at] gmail> wrote:
>
>> On Tue, May 1, 2012 at 10:11 AM, Paul LeoNerd Evans
>> <leonerd [at] leonerd> wrote:
>> > At which point we might consider what
>> >
>> > my @values = (while($cond) { EXPR });
>> >
>> > might do.
>> >
>> > Just a thought...
>>
>> it seems clear that @values would wind up holding one of undef, 0, '',
>> or some overloaded reference that gives a false value in boolean
>> context..
>>
>
> It does not seem clear to me at all. Why would Perl do something useless?
> I would expect a warning if not an error
>

...if some useful behaviour can't be found, that is.

abigail at abigail

May 1, 2012, 1:05 PM

Post #37 of 39 (159 views)
Permalink

Re: proposal: functional C<if> [In reply to]

On Tue, May 01, 2012 at 03:53:49PM -0400, Eric Brine wrote:
> On Tue, May 1, 2012 at 11:24 AM, David Nicol <davidnicol [at] gmail> wrote:
>
> > On Tue, May 1, 2012 at 10:11 AM, Paul LeoNerd Evans
> > <leonerd [at] leonerd> wrote:
> > > At which point we might consider what
> > >
> > > my @values = (while($cond) { EXPR });
> > >
> > > might do.
> > >
> > > Just a thought...
> >
> > it seems clear that @values would wind up holding one of undef, 0, '',
> > or some overloaded reference that gives a false value in boolean
> > context..
> >
>
> It does not seem clear to me at all. Why would Perl do something useless? I
> would expect a warning if not an error.

I'd expect Perl to DWIM, and that's to populate @values with the successive
values of EXPR. That is, if it were valid syntax, I'd expect:

my $i = 3;
my @values = while ($i) {$i * $i --};
say "@values";

to print out "9 4 1".

That would be much more useful than the final result of the condition.

Abigail

perl-diddler at tlinx

May 4, 2012, 11:10 PM

Post #38 of 39 (145 views)
Permalink

Re: proposal: functional C<if> [In reply to]

Eric Brine wrote:
> ...if some useful behaviour can't be found, that is.
>

=========
Along the same lines (alt syntax), why should this yield an error:

#!/usr/bin/perl -w
use strict;

sub mins {
my $p=shift;
@_ and do {
my $H = shift;
my ($tM, $M) = ($H,0);
@_ ? #if (@_) {
($M, $tM)=(shift, 100*$H+$M)
($H, $M) = (int $H/100, $tM % 60);
#}
@$p{'H','M','tM'} = ($H, $M, $tM);
return $p;
};
undef;
}

bless my $p={},__PACKAGE__;

my $t=mins($p, 1800);
printf "h M tM= %02d %02d %03d\n", $t->{H}, $t->{M}, $t->{tM};

----
> /tmp/pp.pl
Assignment to both a list and a scalar at /tmp/pp.pl line 12, near ");"
Execution of /tmp/pp.pl aborted due to compilation errors.

Seems to be similar to what the OP was wanting, but generates
what appears to be a bogus error message.

Where's the assignment to a scalar?

davidnicol at gmail

May 7, 2012, 3:19 PM

Post #39 of 39 (143 views)
Permalink

Re: proposal: functional C<if> [In reply to]

On Sat, May 5, 2012 at 1:10 AM, Linda W <perl-diddler [at] tlinx> wrote:

>
> Along the same lines (alt syntax), why should this yield an error:
>

Parens clear it up, but is there really an ambiguity?

Further data points:
$ perl -le '@A ? @B=( 11) : @B = (22); print @B'
Assignment to both a list and a scalar at -e line 1, near ");"
Execution of -e aborted due to compilation errors.
$ perl -le '@A ? @B=( 11) : (@B = (22)); print @B'
22
$ perl -le '@A ? @C : @B = (22); print @B'
22
$ perl -le ' @B = (2,3) = (2,4); print @B'
Can't modify constant item in list assignment at -e line 1, near ");"
Execution of -e aborted due to compilation errors.
$ perl -le '( @B = (2,3) )= (2,4); print @B'
24

1 2

View All

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads