[Grace-core] More notes on the spec (0.7.0)

[Tijs van der Storm]

Hi all,

Going through my notes based on the reading the spec.

- "Statements may optionally be terminated by semicolons": this suggests
you can always remove them, but this is seems not to be true. I thought
statements can be on the same line if there's a semicolon.

- Comments (3.3): the text focuses on a single line, but what about
sequences of line comments. I presume there's some longest match semantics
here.

Furthermore: Is it correct to assume that the rules about
preceding/following syntactic element require an empty line when, e.g.,
attaching a comment to a class decl?

Ellipsis: very nice! This is what Sean calls "providing real-estate to the
unknown" :-)

4.7: it is an error to declare any name more than once. I presume
compile-time error? Same with shadowing error.

Nit-pick: what happens when return gets executed from a closure that has
escaped the current method?

6.1 All of the declared attributes of the object are in scope throughout
the object constructor:
- I presume regardless of ordering?
- Defs and vars are not visible during def/var initialization?
- The unnamedCat example (6.1) is not visible within the object constructor?

Since manifest expressions allow static checking (if I understood
correctly), I assume the object composition errors of 6.5 & 6.5.1 are
static as well?

"local declarations override declarations from both..." this includes
vars/defs?

I don't understand why in 6.5.3 there is a trait conflict between feline
and canine. The example suggests that even though I have aliased the
trait-inherited methods, I still have to override to resolve the conflict.
Oh, wait, using both aliases without override, means I have no move method
anymore; is that a problem? (Is this because types?). Would it be ok to
alias just one?

7.3.2: implicit requests: is ambiguous request a runtime error? Again,
assuming manifest expressions in inherit/use, this could be a static error,
no?

7.9: "the meaning of the parent expressions not be subject to overriding"
I'm unsure what this means. During the workshop this came up, but there I
thought that (since classes are methods), they can be overridden to the
Newspeak style stuff. This would seem to contradict the above. Would it be
correct to paraphrase this as: a manifest expression must be top-level?
E.g. cannot be nested in a class, method, or object constructor?

One more thing regarding types: I didn't read anywhere that overridden
methods can refine the return type (as in Java).

Ok, I'll stop now :)

Cheers,

T




On Wed, Jul 27, 2016 at 10:25 AM Tijs van der Storm <storm at cwi.nl> wrote:

>
>> ha!
>> yes that's a good point - even if the answer is: execution "mostly"
>> doesn't depend on types...
>>
>
> Ok... I presume (hope) you're referring to pattern matching here... ;-)
>
>
>> > For instance, as far as I can see, the only place where [] are used are
>> lineups.
>>
>> that's right. we got each bracket pretty much used in only one place
>> (except { } which are used in lots of places, notably for lambdas but
>> also for grouping).    At one point I did look at going semi-Python:
>> {} for lambdas/blocks but just layout for classes/methods/objects...
>>
>> > You could require at least 1 space to occur before a lineup, and
>> disallow a space before the [] actual generic type arg.
>>
>> right, yes that would work.  But people seemed to be against that kind of
>> space-sensitivity, or actively like being post-ascii.
>>
>
> I agree that layout sensitivity should be a last resort (except for things
> like longest match of identifiers etc.). If it perfectly matches default
> style of writing however, I think it would be ok.
>
> Does this mean Lineups can't be nested? What about:
>
> x.set[[y]]
>
> Seems ambiguous to me, unless there's still whitespace sensitivity here.
> Disallowing nested line ups would also mean one more exception in the
> manual...
>
>
>
>>
>> Alternatively we could get rid of lineups :-)
>> Lineups came in when we removed varargs: overriding by arity
>> (which I don't particularly like) came in at the same time,
>> but with an injunction not to use it.
>>
>> Given that we have if/then/elseif/then,  match/case/case/case... and
>> friends
>> nominally implemented by a whole bunch of methods (since we don't have
>> Michael's nice generalised methods, or even a simpler version of it)
>> I don't see why list or set or seq couldn't be "implemented" the same way.
>>
>
> Yes. The nice thing about varargs is that you avoid the nesting
> opportunity (unless you have a splat operator a la Ruby). You can make it
> simple in Grace, by only allowing selector component to be *either* a list
> of params, *or* a single varargs (so, no "x, y, *z", rest argument
> patterns).
> It is then still possible to state that the vararg formal will be bound to
> some unspecified object that supports iteration, but nothing else (although
> personally I think it should just be a standard library list/array
> object...).
>
> T
>
>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailhost.cecs.pdx.edu/pipermail/grace-core/attachments/20160727/5d88651b/attachment-0001.html>