E6: assume nothing

[Trey Harris]

To take the E6 example of currying &part:

&List::Part::part.assuming(labels => <<sheep goats>>)

One had to curry in C<labels> to be the same as it was defined in C<&part>
originally, i.e. C<< <<sheep goats>> >>.

What if one wanted to curry in whatever the default is, i.e., assuming
"nothing" (different from "assuming nothing"), so that if List::Part::part
changed its default for C<labels> to C<< <<oves caperes>> >>, the client
code would pick that up?

--
Trey Harris
Vice President
SAGE -- The System Administrators Guild (www.sage.org)
Opinions above are not necessarily those of SAGE.

[Austin Hastings]

--- Trey Harris <tr...@sage.org> wrote:
> To take the E6 example of currying &part:
>
> &List::Part::part.assuming(labels => <<sheep goats>>)
>
> One had to curry in C<labels> to be the same as it was defined in
> C<&part>
> originally, i.e. C<< <<sheep goats>> >>.
>
> What if one wanted to curry in whatever the default is, i.e.,
> assuming
> "nothing" (different from "assuming nothing"), so that if
> List::Part::part
> changed its default for C<labels> to C<< <<oves caperes>> >>, the
> client
> code would pick that up?

assuming(labels => undef)

[Trey Harris]

In a message dated Thu, 31 Jul 2003, Austin Hastings writes:
> assuming(labels => undef)

Okay... I think you're wrong, because this would have to be a special case
(defaults take effect only when *nothing* is passed in, not when the
argument is undefined) but, assuming you're right... if I want to pass
undef to labels, what would I write?

[Austin Hastings]

This is, I believe, an extension of the undef vs. null discussion that
went on some time back (we were discussing default values for arrays,
types, etc.)

The consensus (which I remain in disagreement with) was that undef
meant "go get your default" -- in effect, that you couldn't store undef
into a value that had a default specified.

If that consensus remains, there is no way to pass undef to a parameter
with a default value specified, as I read it. (Which is one of about a
million reasons why I don't like it.)

=Austin

--- Trey Harris <tr...@sage.org> wrote:

[Damian Conway]

Trey asked:

> To take the E6 example of currying &part:
>
> &List::Part::part.assuming(labels => <<sheep goats>>)
>
> One had to curry in C<labels> to be the same as it was defined in C<&part>
> originally, i.e. C<< <<sheep goats>> >>.
>
> What if one wanted to curry in whatever the default is, i.e., assuming
> "nothing" (different from "assuming nothing"), so that if List::Part::part
> changed its default for C<labels> to C<< <<oves caperes>> >>, the client
> code would pick that up?

If you're assuming "nothing", don't use C<.assuming> (since you aren't ;-)
Just write:

sub my_part(Selector $s, *@data) { part $s <== *data }

and let C<&part> do the assuming for you.

Damian

[Luke Palmer]

Gee, that's about as helpful as saying to do &baz.assuming(foo => 'bar'):

sub my_baz(*@data) {
baz foo => 'bar' <== *@data
}

Wasn't the whole idea of assuming to make it easy to curry without
knowing the entire signature, and being tolerant to changes? I see a
simple solution:

our &my_part := &part.assuming('labels');

Or, maybe if we're caught up on readability (and error checking):

our &my_part := &part.assuming(none 'labels');

Luke

> Damian

[Luke Palmer]

I wrote:
> Damian explains:

Here's a wacky idea. We have C<undef> for for undefined, and
C<defined> to check it. We have C<exists> to check existance, so,
(hold your breath) C<nonex>.

A synonym of:

delete %h{foo};

would be

%h{foo} = nonex;

To assume that a value wasn't provided:

our &my_part := &part.assuming(labels => nonex);

And to declaratively copy a hash but delete a key:

{
%other,
baz => nonex,
}

> Luke
>
> > Damian

[Jonadab The Unsightly One]

Luke Palmer <fibo...@babylonia.flatirons.org> writes:

> A synonym of:
>
> delete %h{foo};
>
> would be
>
> %h{foo} = nonex;

This has the potential, if not documented exactly right, to create
bogus expectations. Consider...

$s = %h{foo} = nonex;

After deleting the foo key (and its value, if any) from %h this then
probably procedes to autovivify it when evaluating it as an rvalue; if
so, that may break the programmer's expectation, but if not, what is
assigned to $s -- obviously you can't assign nonex, because it isn't a
value. Do we mutate it to undef? Throw a runtime exception? Remove
the entry for $s from the symbol table?

undef, odd though it is, is a value of sorts. Not a terribly
meaningful value in many contexts, but a value. And it knows how to
stringify, numify, et cetera. The proposed nonex would do none of
those things, at least not without first autovivifying, at which point
it would no longer be nonex.

However, it might be possible to write the documentation so that it's
clear nonex isn't really a value, just syntactic sugar for deleting
the corresponding key.

--
$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b->()}}
split//,"ten.thgirb\@badanoj$/ --";$\=$ ;-> ();print$/

[Paul Johnson]

Jonadab the Unsightly One said:

> $s = %h{foo} = nonex;
>
> After deleting the foo key (and its value, if any) from %h this then
> probably procedes to autovivify it when evaluating it as an rvalue;

Now why on earth would you want to do that? Perl 5 doesn't.

By the way, I trust this will be addressed (if it hasn't been already):

perl5 -le 'print "gah!" if exists $a{b}{c}; print "phooey!" if exists $a{b}'

perlfunc says:

This surprising autovivification in what does not at first--or even
second--glance appear to be an lvalue context may be fixed in a future
release.

--
Paul Johnson - pa...@pjcj.net
http://www.pjcj.net

[Larry Wall]

On Mon, Sep 08, 2003 at 11:18:12AM +0200, Paul Johnson wrote:
: By the way, I trust this will be addressed (if it hasn't been already):

:
: perl5 -le 'print "gah!" if exists $a{b}{c}; print "phooey!" if exists $a{b}'
:
: perlfunc says:
:
: This surprising autovivification in what does not at first--or even
: second--glance appear to be an lvalue context may be fixed in a future
: release.

I sure hope so. Perl 5 confuses reference contexts with lvalue
contexts. With the new vtable implementation of basic types, we
ought to be able to substitute an "always undefined" array or hash
vtable that can propagate non-existence outward in rvalue context.

Larry

[Paul Hodges]

This one doesn't *quite* make me as strongly prompted to chuckle and
say "Larry, you're an evil genius" as the comments on macros in another
thread, but it still gives me a warm fuzzy.... particularly because we
know Good Larry is in charge, and Evil Genius Larry just works in the
sweatshop to satisfy his need to beat the Gods of Cryptocontext at
their own game.

TMTOWTDI applies likewise to DWIMming! :)

Also, I'm very sorry Larry -- I hit the wrong button backing up to edit
this, and sent you an empty message. :(