On Mon, Oct 12, 2015 at 12:54:31PM -0400, Eric Brine wrote: > On Mon, Oct 12, 2015 at 6:22 AM, Dave Mitchell <davem@iabyn.com> 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. > > > It doesn't matter what code it *results* in. > > use constant FOO => $x; > when (FOO) > > is no different than > > when ($x) > > and we all agree the latter is not workable. FOO is the still the result of > an arbitrary expression, even if the expression is evaluated at > compile-time. This differs from > > when ("x") > when (4) > > because that bases behaviour on the *source* code. This is Perl. You can't even trust the source code: use constant; use overload::constant integer => sub {"$_[0]"}; when (3) {...} # What does this do? 'eq' or '=='? AbigailThread Previous | Thread Next