[Grace-core] Further questions on the specification

[Kim Bruce]

Hi Michael,

I don't find a record that anyone responded to your questions.  Let me try.

Kim



On May 13, 2011, at 5:01 PM, Michael Homer wrote:

> Hi,
> I have another list of questions about the specification, less focused
> than the Unicode questions so they can share a post. Deeper discussion
> of any particular point should probably split off to its own thread.
> These cover either areas that I found ambiguous in the specification
> or points that weren't covered at all.
> 
> - Are classes open or closed?
> Can a class have methods added to it after declaration? If so, does
> that propagate to pre-existing instances? How does it affect the
> implicitly-created type?

That is still under discussion.  I believe Andrew wants yes, and I prefer no open classes (as it is not needed for novices)
> 
> - Is there any form of mixin or trait?

Not at the moment, but we might be forced into it.  Still an open question.

> 
> - Are there short-circuiting operators?
> I think they aren't in the specification as it stands, though I've
> seen mention of them. The right-hand side would need to be a block so
> they will be syntactically a little weird.

We should have them as otherwise the circumlocutions without them are too painful.  Putting curly brackets around the right-hand side would be a pain, however.  Perhaps a good reason to have them built-in to the language rather than considered as definable.
> 
> - if-then-else
> How does elseif work? Is the idea that there is an infinite chain of
> if-then-elseif-then-elseif-then-...-else methods? A short chain in the
> standard library? Something else? Currently the specification only
> uses if-then-else.

That is a recognized problem.  I personally don't think it is a big deal to have these things defined primitively, but others seem to want most control structures definable in the language.  Syntactically it's not an issue, and not a problem if we don't require it to be definable.
> 
> - Float64 and equality
> There is a Float64 type, and there is built-in equality. How do those
> combine? Is equality defined at all on floating-point types? In my
> implementation I am currently deferring to the underlying processor's
> floating-point, which means equality is nonreflexive.

An annoying detail that we will eventually have to resolve.  In principle I'd prefer not to have equality for floating point types, but I suspect that would drive people crazy.  I'd prefer to defer the decision for now.
> 
> - MessageNotUnderstood
> Is there a feature like this in method dispatch? How does it interact
> with static typing?

We obviously need to throw an exception of this sort in the dynamically typed version of the language.  On the statically typed side we should only need it for type "dynamic" or whatever we end up calling it.
> 
> - for ... each or for ... do
> for ... do is in section 6 (Blocks), for ... each in section 10
> (Control flow). Is there a distinction, or are they two forms of the
> same thing to be settled later?

We will want two "for" loops, one for sequential and one for parallel execution, but that is a different distinction than what is (likely accidentally) made in the specification.  I'd stick with for .. do as either part of the language or part of the standard library.  Andrew's grammar omits both (assuming they are defined in a library).
> 
> - 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.
> 
> - 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?

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

Kim
> 
> -Michael
> _______________________________________________
> Grace-core mailing list
> Grace-core at cecs.pdx.edu
> https://mailhost.cecs.pdx.edu/mailman/listinfo/grace-core