Much thanks to gaal and Stevan for preparing this nice ChangeLog that summarizes the past three days of hacking. Tonight's release plan came to a halt when Juerd explained succintly that our current type-based Context handling is All Wrong; instead of using object types, what really needs to happen is to group the contexts into Singular (subtypable), Plural (non-subtypable) and maybe Void (not sure). That invalidates much of the new context-handling code I checked in today, so I'm back at square one, needing to repair it tomorrow. :-/
Well... At least we did not push a bogus version out. I'll keep you posted...
Then, Autrijus sent his question to p6l, I answered it there according to my latest guess, and Larry confirmed that this guess was right:22:13 < autrijus> Juerd: hey, maybe you can answer this
22:13 < autrijus> foo(1,2,3);
22:13 < autrijus> foo(1,(2,3));
22:13 < autrijus> foo((1,2,3));
22:13 < autrijus> they are potentially different things, right?
22:13 < autrijus> not always the same
22:15 < Juerd> autrijus: Depends on foo's signature, I think
22:15 < autrijus> Juerd: right.
22:15 < Juerd> OTOH, no, I think they're all the same.
22:15 < autrijus> Juerd: right.
22:15 < autrijus> wait, you can't be right on both times.
22:15 < Juerd> Or, wait, no, "," is a constructor now, isn't it?:)
22:16 < autrijus> Juerd: you are confusing me:-/
22:16 < autrijus> I'm already confused
22:16 < Juerd> That'd mean they have to be different
22:16 < Juerd> But they can't be, because non-subcall parens are only for
forcing precedence
22:16 < Juerd> HELP
22:16 < Juerd> There are two similarly spelled operators, one being , and the
22:16 < autrijus> *exactly*
22:16 < Juerd> One separates sub call arguments, the other list elements
22:16 < autrijus> right.
22:17 < Juerd> Except of course when lexical (lexical as in how they appear in
code) lists do flatten, regardless of context
22:17 < Juerd> In which case everything matches up again
22:17 < Juerd> In a most useful way:)
22:17 < autrijus> so...
22:17 < autrijus> is((1,2), (3,4), "hey");
22:17 < autrijus> is this happy or not?
22:18 < autrijus> assuming &is has the signature of <Str,Str,Str -> Str>
22:18 < Juerd> No
22:18 < Juerd> Oh
22:18 < Juerd> What's ->?
22:18 < autrijus> <Str,Str,Str -> Bool>, rather
22:18 < autrijus> the return type
22:18 < Juerd> And doesn't -> in <> clash?
22:18 < autrijus> not something canonical;)
22:18 < autrijus> i.e. it's my notation, ignore it
22:18 < Juerd> Oh!
22:19 < Juerd> It has too many arguments, I think, autrijus
22:19 < Juerd> Although
22:19 < Juerd> Hm, no
22:19 < Juerd> It's okay!
22:19 < Juerd> Because the *,* is in scalar context, not the parens - they just
group
22:19 < Juerd> Yep, that must be it
22:20 < autrijus> ok. I'm asking p6l:)
22:20 * Juerd can be extremely confusing when he's thinking out loud
22:20 < Juerd> autrijus: I think it's okay and equivalent to is([1,2], [3,4],
"hey")
We continued on IRC: (the time difference is caused by my driving home)From: Larry Wall <larry@wall.org>
Date: Wed, 20 Apr 2005 13:30:38 -0700
To: perl6-language@perl.org
Subject: Re: Quick question: parens vs subroutine parameter
On Wed, Apr 20, 2005 at 10:23:14PM +0200, Juerd wrote:
: Autrijus Tang skribis 2005-04-21 4:19 (+0800):
: > So, following up on the Parens handling, are these two equivalent?
: > # Assuming &is has the parameter signature (Str, Str, Str)
: > is((1,2), (3,4), "hey");
: > is([1,2], [3,4], "hey");
:
: I think so.
:
: > What happens if &is is of type (Any, Any, Str)?
:
: Same thing, as the inner comma is still in scalar context.
:
: However, with list context, I expect things to flatten, so with a
: signature of *@_, it puts 5 elements in @_.
That's all correct.
Larry
See also the related thread "Quick question: parens vs subroutine parameter" in the perl6-language mailinglist.23:08 < Juerd> autrijus: I eventually guessed correctly!;)
23:10 < autrijus> gah.
23:10 < autrijus> Juerd: you are correct after all.
23:10 < autrijus> Juerd: so if &is is of signature (Array, Array, Str)
23:11 < autrijus> (all three nonslurpy)
23:11 < autrijus> Juerd: is the inner (1,2) still running in scalar context?
23:11 < autrijus> Juerd: or are the suddenly in Array context?
23:11 < Juerd> autrijus: Then it's still scalar context (specifically, array
context, which surprisingly nicely is not a form of list context):)
23:11 < Juerd> autrijus: Array context is a scalar context
23:11 < autrijus> Juerd: that is hard to believe.
23:12 < autrijus> Juerd: I can see "array ref" context, maybe
23:12 < Juerd> I think we should rename scalar context to singular context
23:12 < autrijus> Juerd: but Array is a List
23:12 < autrijus> as Hash is a List
23:12 < Juerd> autrijus: Array is a class, classes when used for context expect
objects, objects are references, Array implies ref
23:12 < Juerd> autrijus: That may be, but types have nothing to do with
context.
23:12 < autrijus> Juerd: wow. that line is the most clear thing I have read.
23:13 < autrijus> Juerd: it also invalidates my hope to release 6.2.1 tonight
:-(
23:13 < autrijus> Juerd: since that means my Eval.hs comma implementation is
All Wrong.
23:13 < Juerd> autrijus: I think it'd be good to rename scalar and list context
to singular and plural context, to avoid confusion with types.
23:13 < autrijus> Juerd: so, it has nothing to do with types, right?
23:13 < autrijus> it's either singular, or plural
23:14 < autrijus> literal lists always flatten in plural context
23:14 < autrijus> and never flatten in singular context
23:14 < autrijus> singular context may be further limited in expecting specific
object types
23:14 < Juerd> autrijus: The main contexts have nothing to do with types,
except that scalar(singular) context can expect a certain type of singular
value, for example, an Array (reference)
23:14 < autrijus> while plural context does not care about type
23:14 < Juerd> autrijus: Exactly
23:14 < autrijus> is that the case?
23:15 < Juerd> autrijus: Plural context can care about the types of its values
23:15 < autrijus> Juerd: I wish these lines are in the synopsis!
23:15 < autrijus> Juerd: can you be kind and summarize these line into a reply
on p6l to my thread?
23:15 < autrijus> and get another "That's all correct" from Larry
23:16 < autrijus> so, sorry, folks, no 6.2.1 tonight because the new context
handling is all wrong:-/
23:16 < Juerd> autrijus: Which lines precisely?
23:16 < autrijus> Juerd: everything after
23:16 < autrijus> 05:08 < autrijus> Juerd: you are correct after all.
23:16 < Juerd> autrijus: That's a lot.
23:16 < autrijus> Juerd: well, what you said, anyway
23:16 < autrijus> I'd do that, but it's 5:14am here and my fingers are on
strike:)
23:16 < Juerd> I'll see if I can make a nice bulleted list
23:17 < autrijus> thank you
23:17 < autrijus> Juerd++
23:19 < autrijus> is Void a special subtype of Singular, then?
23:19 < autrijus> or is Void a context of its own like in p5?
23:21 < autrijus> Nullar
23:21 < autrijus> I'll need to sleep on this new revelation.
23:21 < gaal> (i've seen "nullary" mentioned in some haskell texts, no doubt in
different, er, contexts)
23:22 < autrijus> gaal: it's used in arity context, so "unary" instead of
"singular"
23:22 < gaal> ah. the *opposite* of context.
23:22 < gaal> (in a way.)
23:23 < autrijus>:)
23:23 * autrijus waves... I'll be back:)
23:23 < gaal> night!
23:23 < autrijus> see you tomorrow, folks
23:23 < autrijus> night!
23:23 < autrijus> &
23:27 < Juerd> autrijus: I'd think void context would not be Void context, as
you cannot have a reference to nothing, or express nothingness in a variable
(we have undef), or meaningfully force void context in an expression
