<div dir="ltr"><div><br></div>Hi all,<div><br></div><div>Going through my notes based on the reading the spec.</div><div><br></div><div>- "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.</div><div><br></div><div>- 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.</div><div><br></div><div>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? </div><div><br></div><div>Ellipsis: very nice! This is what Sean calls "providing real-estate to the unknown" :-)</div><div><br></div><div>4.7: it is an error to declare any name more than once. I presume compile-time error? Same with shadowing error.</div><div><br></div><div>Nit-pick: what happens when return gets executed from a closure that has escaped the current method?</div><div><br></div><div>6.1 All of the declared attributes of the object are in scope throughout the object constructor: </div><div>- I presume regardless of ordering? </div><div>- Defs and vars are not visible during def/var initialization?</div><div>- The unnamedCat example (6.1) is not visible within the object constructor?</div><div><br></div><div>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?</div><div><br></div><div>"local declarations override declarations from both..." this includes vars/defs?</div><div><br></div><div>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?</div><div><br></div><div>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? </div><div><br></div><div>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?</div><div><br></div><div>One more thing regarding types: I didn't read anywhere that overridden methods can refine the return type (as in Java). </div><div><br></div><div>Ok, I'll stop now :)</div><div><br></div><div>Cheers,</div><div><br></div><div>T</div><div><br></div><div><br></div><div><br><br><div class="gmail_quote"><div dir="ltr">On Wed, Jul 27, 2016 at 10:25 AM Tijs van der Storm <<a href="mailto:storm@cwi.nl">storm@cwi.nl</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
ha!<br>
yes that's a good point - even if the answer is: execution "mostly" doesn't depend on types...<br></blockquote><div><br></div></div></div><div dir="ltr"><div class="gmail_quote"><div>Ok... I presume (hope) you're referring to pattern matching here... ;-)</div></div></div><div dir="ltr"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> For instance, as far as I can see, the only place where [] are used are lineups.<br>
<br>
that's right. we got each bracket pretty much used in only one place<br>
(except { } which are used in lots of places, notably for lambdas but<br>
also for grouping).    At one point I did look at going semi-Python:<br>
{} for lambdas/blocks but just layout for classes/methods/objects...<br>
<br>
> You could require at least 1 space to occur before a lineup, and disallow a space before the [] actual generic type arg.<br>
<br>
right, yes that would work.  But people seemed to be against that kind of space-sensitivity, or actively like being post-ascii.<br></blockquote><div><br></div></div></div><div dir="ltr"><div class="gmail_quote"><div>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. </div><div><br></div><div>Does this mean Lineups can't be nested? What about:</div><div><br></div><div>x.set[[y]]</div><div><br></div><div>Seems ambiguous to me, unless there's still whitespace sensitivity here.</div><div>Disallowing nested line ups would also mean one more exception in the manual...</div></div></div><div dir="ltr"><div class="gmail_quote"><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Alternatively we could get rid of lineups :-)<br>
Lineups came in when we removed varargs: overriding by arity<br>
(which I don't particularly like) came in at the same time,<br>
but with an injunction not to use it.<br>
<br>
Given that we have if/then/elseif/then,  match/case/case/case... and friends<br>
nominally implemented by a whole bunch of methods (since we don't have<br>
Michael's nice generalised methods, or even a simpler version of it)<br>
I don't see why list or set or seq couldn't be "implemented" the same way.<br></blockquote><div><br></div></div></div><div dir="ltr"><div class="gmail_quote"><div>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). </div><div>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...).</div><div><br></div><div>T</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
</blockquote></div></div></blockquote></div></div></div>