<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>Ok... I presume (hope) you're referring to pattern matching here... ;-)</div><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>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><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>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>