I suggest the ' operator as in

  let sum (x:'T) (y:'T) = x + y  

I have no idea why you even have to specify that a method is generic shouldn't it be generic by inference?

If quotes are used for grouping characters (as they are in C, Java, C#, Python etc.) then this is just as bad as using <>. How can you tell if it is a character literal or a type?

I have no idea but F# does exactly that.

I'm guessing that it uses a context sensitive grammar that doesn't allow you to use string literals for variable names.

Maybe, but the problem was that "all lexing/parsing/syntax highlighting/analysis of the language is much harder because of this horrible choice". Using quotes doesn't really fix that.

The problem is that you often need to decorate a generic parameter with additional information (like its type constraints or variance). If the type parameter doesn't have a singular place where it's "declared", there's no convenience place to do that. In your example, how would you specify that T must implement Summable?

I'm afraid <> is too ingrained at this point to turn around, but seriously; is it such a problem? In C# a template can show up in a class like:

public class Foo<T> { ...

a method like:

public void EatAFoo<T>(...

and usage like:

var f = new Foo<int>();

someObj.EatAFoo<int>(...

I don't see how any of these cases could be confused with a greater than or less than operator. Could you expand on where the problem comes in?

The statement: F(G<A, B>(7)); could be interpreted as a call to F with two arguments, G < A and B > (7). Alternatively, it could be interpreted as a call to F with one argument, which is a call to a generic method G with two type arguments and one regular argument.

See the C# specification section 9.2.3 (grammar ambiguities) for more details: http://www.ecma-international.org/publications/files/ECMA-ST...

is this really a big deal? I wrote my share of Java code with generics and the issue never popped up, because generics are way more restricted than c++'s templates. E.g.

   myclass<3>4>  

can only be a syntax error because you can't have a value in there, inly a type name

Ok. Still, it makes syntax highlighting and everythink lexical so much harder and ambivalent (think a<b<c>> - close paren or right shift?) with no benefit compared to e.g. []

again a syntax error, you can't have generics in an expression in which operators such as > are allowed, the java syntax is really simple and unambiguous to parse.

On the other hand, [] is used for arrays in java so it _would_ conflict with something

See this comment above in this thread: http://news.ycombinator.com/item?id=2442468

It is a semantic error, not a syntax error (in the sense that an annotated grammar CANNOT, without semantic analysis, find that this is an error).

The example given in this comment, F(G<A,B>(7)) is syntactically ambiguous and can only be resolved to either F( (G<A) , (B>(7) ) - a two argument function call, or F( (G<A,B>(7)) ) - a one argument function call - when the types of F, G, A and B are known.

Also, things like F<G<A>> (which are perfectly legal) make lexing very hard - you can't assume '>>' is the shift right token without syntactic (and semantic) analysis. Or, you can decide like early C++ that you must write it F<G<A> > which is confusing.

sorry, but are you sure a C# problem applies to Java?

AFAIK the syntax for passing type arguments to a generic method in the latter would be

   obj.<A,B>G(7)

so

   F(G<A,B>(7))

is once again unambiguous, at a syntactic level.

It would seem the java designers thought of the issue :)

> please use {} or []

How about a Pascal-ish:

(List of Integer) l = new List();