develooper Front page | perl.perl5.porters | Postings from October 2015

Re: YA smartmatch proposal [ was: Re: smartmatch needs your eyes]

Thread Previous | Thread Next
From:
Abigail
Date:
October 12, 2015 11:12
Subject:
Re: YA smartmatch proposal [ was: Re: smartmatch needs your eyes]
Message ID:
20151012111209.GA4788@almanda.fritz.box
On Mon, Oct 12, 2015 at 11:22:03AM +0100, Dave Mitchell wrote:
> On Wed, Oct 07, 2015 at 03:57:26PM -0400, Eric Brine wrote:
> > On Wed, Oct 7, 2015 at 4:24 AM, Dave Mitchell <davem@iabyn.com> wrote:
> > 
> > > 2. Make when's behaviour entirely dependent on the *compile-time* class
> > > of of its arg. In particular, make 'when (FOO)' have exactly the following
> > > behaviours:
> > >
> > >     FOO             condition evaluates to
> > >     --------------  ----------------------
> > >     literal undef             !defined($_)
> > >     numeric const                $_ == FOO
> > >     literal pattern              $_ ~= FOO
> > >     all else                     $_ eq FOO
> > >
> > > 3. when { FOO } has condition FOO.
> > >
> > > For example:
> > >
> > >     use constant ME  => "davem";
> > >     when (ANS)     # equivalent to when { $_ == 42 }
> > >
> > 
> > According to your table, shouldn't that be "when { $_ eq ANS }"? ANS could
> > have any value, so when (ANS)" is no different than "when ($x)". There's no
> > "compile-time class" available to study.
> 
> No, its specifically if FOO is a compile-time constant. At compile time
> there is no difference between
> 
>     when(42)
> 
> and
> 
>     use constant FOO;
>     when(FOO);
> 
> They have both been compiled to a single OP_CONST with a constant SV
> attached that can be examined at compile-time for numness.  Of course,
> 
>     sub FOO {}
>     when (FOO)
> 
> would be treated as ($_ eq FOO) still.



While sympathetic, and perhaps easier on the implementation side, I
think deciding what to do depending how an expression is evaluated at
compile time is a really bad idea:

  - Most Perl programmers will not be familiar enough with the perl
    internals to know what is actually happening at compile time.
    Nor should they.

  - It creates an action at a distance, as your latter example shows.
    Programs changing their behaviour in subtle ways if one replaces

        use constant FOO => "...";

    with

        sub FOO {...}

    (or in the other direction) doesn't seem like a good idea to me.
    It's a maintenance nightmare.

  - It makes it harder in the future to change what's done at compile
    time, as it may break the meaning of when().



Abigail

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About