[Grace-core] Further questions on the specification

[Andrew P. Black]

On 25 May 2011, at 15:02 , Eric Mullen wrote:

> 
> I'm curious how you expect a dynamically typed variant to statically catch arity errors. Say I write the following program, with no type annotations (since it's going to be dynamically typed):

I'm Graceifying your example:

> 
> const a := class {
>     method x(a,b) = { 5 }
> }
> 
> const b := class b {
>     method x(a) = { 2 }
> }

>  // top-level code is just executed:
> var myObj
> if standardIn.readInteger.isEven
> 	then { myObj := a.new }
>         else { myObj := b.new }
> standardOut.print myObj.x(3,4).asString
>   

> There is a potential for an arity error there, but it isn't detectable until runtime, since standardIn.readInteger could always be even.

Yes, I think that you are right.  In some cases the arity error can't be detected until runtime.  So this is the same as the type error.  It was wishful thinking on my part that it could be otherwise.


On 25 May 2011, at 14:49 , Michael Homer wrote:

> 
> 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".

Well, the static type that one gets from inference always depends on the context.  But that doesn't change the set of operations that the object can actually understand. 

> 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.

You are right, this is nasty, but maybe not as nasty as you imagine.  It's not every object that is treatable as a sequence of length one, but every varargs parameter.   So (x) == x at all times.  However, if x… is declared as a parameter, then the name x always denotes the whole collection of arguments, not any particular one of them.  They are x.at 1, x.at 2, up to x.at (x.size).

By the way, I would much rather have tuples be 1-indexed.  So a 3-tuple has elements 1, 2 and 3, and a size of 3.

> 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.

So, my proposal is that this behavior is restricted to varargs parameters. It doesn't work on literals.  Yes, this is a special case, and I'm not sure that I like it.

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

Yes, I recall that now.  Apart from looking weird, this might be an alternative solution.
Funny that we should go to great lengths to make trailing semicolons insignificant, and then give this role to the trailing comma!   Can I write (4,5,6,) and if so, is it the same as (4,5,6)?

Another possibility would be have no syntax for 1-tuples, and require that they be made explicitly when required, e.g, by 1.asTuple

	Andrew