[Grace-core] Further questions on the specification

[Eric Mullen]

On Wed, May 25, 2011 at 11:17 AM, Andrew P. Black <black at cs.pdx.edu> wrote:

>
> On 25 May 2011, at 10:17 , Kim Bruce wrote:
>
> >>
> >> - Tuple unpacking in method calls
> >> Section 9.1 says "multiple parenthesized arguments are treated as a
> >> single tuple argument". What does that mean? How do you declare a
> >> method that takes this tuple argument, distinguished from one that
> >> really does take one argument?
> >
> > Tuples were added a bit late, so we haven't thought them through.  Most
> functional languages treat all functions as taking a single argument, which
> may be a tuple.  If they are not in parentheses then they are assumed to be
> curried.  I'm not quite sure how this would interact with our mixfix
> notation for methods and method calls.  This is something that we should
> address in more detail.
>
> What I had in mind when I wrote this was as follows.  I obviously didn't
> make it very clear; I hope this is better, but if not, ask again.
>
> [Note on terminology: the specification in the heading of a method is
> called a parameter.  The value that is passed to the message request is
> called an argument.]
>
> If a method is defined as taking a parameter (a:R, b:S, c:T) then it should
> be given a 3-tuple of type (R,S,T) as argument.  If it's given a 2-tuple or
> a 4-tuple than that's an arity error (which I would expect even the
> dynamically-typed variant to trap statically in the case that the argument
> is a literal tuple).   If the method is given a 3-tuple of a different type,
> then that's a type error, which would be caught statically or dynamically,
> depending.
>

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):

class a() {
    method x(a,b) = { 5 }
}

class b() {
    method x(a) = { 2 }
}

object start {
    method main() = { //or however the main program is decided to happen,
doesn't really matter
         if(random_input() % 2 == 0) {
             myObj = new a()
         } else {
             myObj = new b()
         }
         print (myObj.x(3,4))
    }
}

There is a potential for an arity error there, but it isn't detectable until
runtime, since (random_input() % 2 == 0) could always be true.

>
> If you declare a method that takes one parameter p, of type Number, say,
> and a method request provides instead a tuple of three numbers (4, 5, 6),
> then that's a compile-time arity error.    If you declare a method that
> takes one parameter p of unspecified type, and call it with argument (4, 5,
> 6), then everything will work fine if the code treats p as a sequence (p map
> fun, p.size, for p do etc.), but if the code attempts an operation that is
> not defined on sequences (like  p = 0) then a run-time type error will be
> generated.
>
> >>
> >> - 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?
>
> > In general, most languages treat different arity of tuples as distinct
> data types.  I.e., 1-tuples are not the same type as 2-tuples.  That seems
> right to me.  (Though the specification section 5 seems to hint otherwise!)
>
> I agree that 1-tuples are not the same type as 2-tuples.  What in Section 5
> hints otherwise?
>
> > On the other hand, it might be handy to treat 1-tuples of type T as
> implicitly coerceable back and forth to elements of type T.  That makes me a
> bit nervous, however.  I assume the main issue here is with omitting
> parentheses in method/function calls and with getting back multiple values.
>  (As I noted in an earlier e-mail, I'd rather not see the a,b,c :=
> o.getVals(...) as being allowed -- I'd require (a,b,c) := o.getVals(...).)
>
> I didn't see that email, sorry.   I don't have a problem with requiring
> parens on the l.h.s. of an assignment or an initializing declaration.
>  However, this is an independent question: the thing on the l.h.s. is not a
> tuple, it's a pattern (binding construct) of some kind.
> >
> > I think we need to talk this through in more detail as to why we need
> both lists and tuples, and if we do, what their different interfaces should
> be!
>
> Lists would be a library-defined data type, implemented using finger trees
> or something similar for the immutable variant, and maybe cons cells for the
> mutable variant.   The place where this relates to tuples would be that one
> could create a list with method request like List.from(2,3,5,7,11,13).   The
> argument would be nothing more than 6 values on the stack, along with a
> length.   The object constructor would build the library-defined data
> structure for List using these values — that is, it would copy them into the
> finger tree or the cons cells, for example.   I don't see any redundancy
> here; maybe I'm missing something.
>
>        Andrew
>
>
>
>
>
>
Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailhost.cecs.pdx.edu/mailman/private/grace-core/attachments/20110525/2816b89c/attachment.html>