[Grace-core] Further questions on the specification

[Michael Homer]

On Thu, May 26, 2011 at 6:17 AM, Andrew P. Black <black at cs.pdx.edu> wrote:
>
> On 25 May 2011, at 10:17 , Kim Bruce wrote:
>>>
>>> - Tuples generally
>>> Section 5 says that "(7)" is "the number 7, which is also a 1-tuple
>>> containing 7". Does that mean that all objects support the tuple
>>> interface, or is the type of the expression to be inferred by context?
>
> If the argument is (4), I felt that had to be equivalent to an argument of 4.   If these two forms are not equivalent, then we will have to use some other kind of bracket for tuples.   I think that the implication of this is that 4 will have to be treatable as a sequence of length 1, as well as a number.   Will this have untoward consequences?  I don't know; we will have to see what happens.
>
> Another option would be to treat (4) as both a Number and a 1-tuple, but to treat 4 as just a number.  So 4 and (4) are not exactly the same.  This might also have untoward consequences.
>
> In answering the question "Does that mean that all objects support the tuple
> interface, or is the type of the expression to be inferred by context?" I would have said "yes", because I see these things as independent.  I'm not clear what the difference is between all objects supporting he tuple interface and the type of an expression being inferred from the context.  Can you give me a specific example where the answer will be different depending on which I pick?

What I meant was whether the expression would be of one type or the
other depending on what was "expected" in that position, or whether it
always represented an object with both interfaces. So (7) in a context
that expected a number would mean 7, while in a context that expected
a tuple it would be that tuple. I'm not sure how (or really if)
inference would work. It's fine if tuples are only ever used in
destructuring assignment, and as statically-typed parameters, but not
in "var x := (7) ; x.at(0)" or "(7) + 1".

The alternative of having every object support the tuple interface has
some wrinkles as well. If every object is treatable as a sequence of
length 1 then objects that are properly indexable have different
behaviour. (x).at(0) == x if x is not indexable, and not otherwise. If
the behaviour is restricted to literals only then that problem is
lessened, but it's a special case with odd corners of its own.

Python disambiguates the 1-tuple case with a trailing comma, so (7) is
7 and (7,) is the 1-tuple containing 7.
-Michael