They do different things if it's defined vs. if it's undefined. This is
preferred to having an if-then test in a single implementation, if they're
different enough that you're really writing two functions anyway.

And List is supposed to be vague there. At the level of Any, it can be a
list of anything. To be more specific about the result, you need an
implementation on specific types instead of on Any; but most of those
implementations would be doing exactly the same thing, only the signature
being different. Which is silly and wasteful and makes the computer dig
though a sea of identical functions for no reason.

On Fri, Sep 14, 2018 at 6:41 PM ToddAndMargo <toddandma...@zoho.com> wrote:

> On 09/14/2018 03:10 PM, Brandon Allbery wrote:
> > On Fri, Sep 14, 2018 at 5:56 PM ToddAndMargo <toddandma...@zoho.com
> > <mailto:toddandma...@zoho.com>> wrote:
> >
> >            'To opt into a non-nullable version of a type add the :D
> >            "smiley" to it."
> >
> >     This is confusing.  And I don't think correct, but I could be wrong.
> >     Curt stated it a lot better:
> >
> >             If I say "my Int $x",
> >             $x is now an Int, but an undefined Int.
> >
> >             If I say "my Int $x = 42",
> >             $x is an Int, but set to a defined value, 42.
> >
> >     ":D" means that the variable is "defined".  "non-nullable" is
> >     a confusing way to state it.
> >
> >
> > Not exactly. "Defined" is a "now" thing; "non-nullable", via type
> > smileys, is an "always" thing. It is defined now, and it can never be
> > undefined.
> >
> >     To me ":D" means that the variable has something assigned to
> >     and ":U" means that the variable has yet to have anything
> >     assigned to it.
> >
> >     If I were to rewrite this, I'd reverse D and U as that
> >     is the way they evolve.  All variables start out as :U.
> >
> >
> > This is the same misunderstanding: what is now, is not guaranteed to be
> > so in the future. :U and :D provide such guarantees. Merely being
> > defined or undefined right now says nothing about the future.
>
>
> Hi Brandon,
>
> Thank you!
>
> My use for the "smileys" is in methods definitions.  It tells me
> that the variable has to have a value or a null.
>
> For instance:
>      multi method kv(Any:U:  -->List)
>      multi method kv(Any:D:  -->List)
>
> is their way of saying I can use either.
>
> Question,  why don't they just say?
>      method kv(Any:  -->List)
>
> And "List" is really vague, as in what kind of list?
>
> -T
>


-- 
brandon s allbery kf8nh
allber...@gmail.com

Reply via email to