[nem-en] Syntax change - your thoughts?

[Gerard Murphy]

Kamil,

A quick reply before leaving home...

> -----Original Message-----
> From: devel-en-bounces at nemerle.org [mailto:devel-en-bounces at nemerle.org]
> On Behalf Of Kamil Skalski
> Sent: 03 February 2006 19:59
> To: devel-en at nemerle.org
> Subject: Re: [nem-en] Syntax change - your thoughts?
> 
> >
> > I get the impression that the decision to use a dot before the type
> > parameters in an expression context was driven by an implementation
> decision
> > - without the dot, the expression would look like an indexer call (and
> > indeed, neglecting the dot results in such an error message).
> >
> 
> Did you take a look at http://nemerle.org/Generic_specifier ?
> And especially http://nemerle.org/Generic_specifier#Why_not_.5B.5D.3F
> 
> There is one, though not very common reason, why plain [] causes problems.
> If it wouldn't collide with the rest of the language I would also like
> to use alwas [].


Thanks for that link; I've gone and looked at that page.

However, what's being described there is exactly the problem I'd already
mentioned: because the implementation tries to avoid using semantic context
while parsing, it needs the dot character to avoid an ambiguity with indexer
calls (and as Alejandro points out, list comprehensions too).


> 
> And the main reason why we generally ignore this consistency is that
> in real programs there is rarely any need to use .[] syntax. You can
> write 5000 lines of code using generics havily without even knowing
> it.
> You just write
> def x = List();
> x.Add (1);
> 1 + x[0];
> 

Well, in that case I guess that making such a syntax change won't cause much
upset to the user community. :-)

I take your point that you have written a lot of code without encountering
this issue, Kamil - however I have run straight into it within the first
month of coding in Nermele.

I'm not the sort of developer who looks for problems in a programming
language - although I am the sort who likes to fix any broken windows as
soon as possible.

Here's two cases I've come across:-


One situation is where a generic method (i.e. a method that is generic in
its right, not simply a method within a generic class) has type parameters
that are unrelated to its arguments:-

lotsOfThings = SomeClass.createLotsOfThingsAndDoSomePostprocessing
					.[Thing](numberOfThingsDesired);

Type inference isn't applicable here.

Here's another:-

class Example
{
   // etc, etc...

   private heterogenousListOfThingsTreatedUsingInclusionPolymorphism:
List[SuperType] = 
			List.FromArray(array [ASubtype(): SuperType,
AnotherSubType.[TypeParameter]()]);
}


As I mentioned before, I can make the effort in my own time to look at the
compiler sources to see how difficult it would be to make this syntax change
without breaking the compiler.

I've already started looking at the compiler sources, but I thought it might
save time if I discussed the matter on the mailing list first.

Needless to say, even if I could make the changes easily, I would obviously
hold back from submitting patches if the user community is against this
syntax change. 


Regards,

Gerard