[nem-en] Syntax change - your thoughts?

[Kamil Skalski]

> > 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).
>

No, the problem lays a little futher than avoiding to use semantic
context during parsing. It lays in "for every moment in existance of
world" ambiguity of what actually

x [y] ();

means.

Let's assume following code:

namespace Root {
class x [T] {
  public this () { ... }
}
class y {}

class Foo {
  public x [a : int] : void -> void
  { get { ... } }

  y : int;

  foo () : void
  {
    _ = x [y] ();
  }
}
}

Now, 'x [y] ()'  has two ambiguous interpretations:
  Root.x. [Root.y] ();
and
  this.x [this.y] ();

It is true that this case is rather rare and we have discussed
ignoring it before. But it came out that in general people prefer the
dot notation to make things less ambiguous and cleaner to read.

Ok, we could switch to plan [] syntax, but it would need an agreement
in most of the community. And for example we (compiler developer) are
quite happy with current solution - as I said before, this syntax is
used very rarely and if it actually is, it's nice to have it explicit.

>
> 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.

Of course there are examples where type inference is not applicable,
but probably this is not the one of such cases.
Did you try ommiting .[Thing] part in your program? Because compiler
can infer the type not only from arguments passed, but also from the
return value - if you ever used 'lotsOfThings' in some context
requiring it to contain Thing, then you don't need to specify
.[Thing].

For example in my application, I have a auxiliary method, which takes
SQL query and returns list of values (assuming that query returns
single column):

public ['a] getSingleColumn (conn : IDbConnection, query : string) : List ['a]
{
  ...
}


and I use it simply as:


def res = getSingleColumn (main_conn, "SELECT age FROM user");
def my_age = res [0]  / 2;
def date = getSingleColumn (main_conn, "SELECT born FROM user");
def time_span = System.DateTime.Now - date [0];


The only situation when .[T] is needed is when you found some
bug/missing feature in type inference engine, where is fails in some
very complex expression:

fun (x) { foo (fun (y) { generic_method_returning_T () }) (x) } ....

Once or twice I encountered that compiler could not handle my code,
though in general it is  a bug and should be reported.

The other situation is when generic parameter is totally independent
from arguments and return value:

public print ['a] () : void
{
  System.Console.WriteLine (typeof ('a));
}

but such cases are not "real-life" and very uncommon.

>
> Here's another:-
>
> class Example
> {
>    // etc, etc...
>
>    private heterogenousListOfThingsTreatedUsingInclusionPolymorphism:
> List[SuperType] =
>                         List.FromArray(array [ASubtype(): SuperType,
> AnotherSubType.[TypeParameter]()]);
> }

In such cases you should always be able to use type enforcement syntax. Didn't
AnotherSubType () : AnotherSubType
work?

>
>
> 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.
>
>

Of course this is a right thing to do. In general because of points
above I would prefer even completely eliminating the generic specifier
syntax, though it would limit language in cases like this 'print'
example and workarounding type inference weaknesses.

If you have some nice solution for the problems posed in
http://nemerle.org/Generic_specifier
then we should consider it for implementation. :)

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