[nem-en] Syntax change - your thoughts?

Kamil Skalski kamil.skalski at gmail.com
Tue Feb 7 20:48:58 CET 2006


> > Now, 'x [y] ()'  has two ambiguous interpretations:
> >   Root.x. [Root.y] ();
> > and
> >   this.x [this.y] ();
> >
>
>
> Perhaps you are misdiagnosing the problem here. I agree that the above
> example leads to an ambiguity, but if I try the same thing using a
> non-generic class to supply the constructor, and a non-generic method to
> compete against the constructor, then I still have an ambiguity:-

You are right. There are many places in the language, even much more
common than this one, where natural constructs lead to ambiguities.
Maybe generic specifier should be just one of them, though this is not
only a compiler issue - from now on user would need to analyse if
x [y]  is an indexer access or generic specifier, especially that they
are quite different things.

>
> I shouldn't have been in such a hurry when I posted my previous E-mail:
> there are examples where the subsequent usage of 'lotsOfThings' would still
> not be enough for type inference to pin down the type parameter in the call
> to 'SomeClass.createLotsOfThingsAndDoSomePostprocessing()'.
>
...
> I'm not quite so sure about that: I'm thinking of the 'self registering
> factory' idiom in C++, where a class or function template uses its type
> parameter to cause the registration of a factory function for creation of an
> object of the type parameter.
>
> In this case, one doesn't see either a return value or an argument of the
> type parameter - the type parameter is used entirely within the registration
> code within the factory function.

Ok. So let's summarize: the need for generic specifier is only for
functions which does not communicate their type parameters with call
site, that is something like:

foo ['a]  (...) : ...

where 'a does not occur in ...

(if it occurs in return type, you can always use type enforcement
like:  def x = foo() : List[int])

So, it implies that foo must ignore 'a or analyse it by reflection
(the factory example), because .NET does not allow C++ - like
instantiation.

I agree that it would be nice to have consistent syntax for generics,
but this scenario just doesn't persuade me to have it at all costs.
Maybe others think differently?


>
> OK, putting myself in your shoes, I would probably not want to expend time
> and effort into doing this: it sounds like it's only me that runs into these
> more obscure corners of the language.

You can grep in sources for GenericSpecifier. But I think that in
place where overloading is analysed, there might be some problems with
merging .[] and [] nodes. But I'm not sure, Michal knows better.

>
> Still, I'll carry on my investigations into seeing if the change could be
> made in theory, at least for a week or two. If I get anywhere in that time,
> I'll be back in touch, otherwise take it that I've quietly admitted defeat!

This is just a place of design, where we were not sure how it would
look better. So we have chosen some democratic approach and it pointed
out that most users perefer .[] syntax.

--
Kamil Skalski
http://nazgul.omega.pl



More information about the devel-en mailing list