[Grace-core] collections interface for new classes

[Kim Bruce]

But part of the reason for this was ambiguity (e.g., with <>).  If we fix the ambiguity problems then we can make the spacing optional.  But right now we need rules in some cases — and in that case it’s easier to make them uniform.  I personally don’t teach the “a[i]” for lists, using a.at <http://a.at/>(i) instead.  If we do that and solve the generics problem then we could ease up on these.

Kim

> On Dec 10, 2015, at 4:36 PM, Andrew P Black <black at cs.pdx.edu> wrote:
> 
> 
> On 10 Dec 2015, at 14:00, James Noble <kjx at ecs.vuw.ac.nz <mailto:kjx at ecs.vuw.ac.nz>> wrote:
> 
>>> Not requiring the second set of brackets is quite important,
>> 
>> Yes...
>> Hopefully Michael can point out what the issue is...
>> 
>>> I think the issue is distinguishing between [ ] as an operator, ... and as a sequence denotation
>> 
>> Again yes
>> 
>>> Two simple solutions are to keep [ ] as an operator, and use something else (like ⟨ ⟩) for sequences, or to appropriate [ and ] for sequences and remove them from the set of available operators.
>> 
>> Operators have to be delineated by spaces in Kernan - which I've now got used to and like: it does makes things easier to read. So one option is that indexing operators cannot be preceded by spaces, but literals must be. 
> 
> I think that space sensitivity is daft.  And using one rule for the * operator and the opposite rule for the  [] operator is dafter.  
> 
> Spaces around operator symbols do make the expression easier to read when there is only one operator and two operands.  But when you have a complex arithmetic expression, the effect is to make it harder to read, because it falls off the end of the line.  So this is something that I would rather leave up to the programmer to consider on a case-by-case basis.
> 
> 	Andrew
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailhost.cecs.pdx.edu/pipermail/grace-core/attachments/20151210/e79d8dd8/attachment.html>