Hacker News Reader

Comment by jackyinger | Hacker News Reader

Try using verilog where <= is both the non-blocklocking assignment operator and the less-than-or-equal operator. At first it might sound/look weird, but you can get used to it easily.

It’s all about the context; I think it would actually be more confusing to go with the author’s suggestion.

Furthermore, I can’t think of a place in code where the generic and comparison use cases of < or > would be ambiguous or even adjacent.

View on HN

> Furthermore, I can’t think of a place in code where the generic and comparison use cases of < or > would be ambiguous or even adjacent.

Most languages that use angle brackets for generics (e.g. C++, Rust, Swift) also allow you to explicitly instantiate generics, which leads to a syntactic ambiguity, e.g. is

    a < b > (c)

a function call or two comparisons? The usual way to disambiguate in these cases is to check whether b is plausibly a type and treat it as a generic, but this is ugly on a few different levels.

Rust uses the "turbo fish" to get around this. Your example wouldn't compile unless a and b where valid variable names.

    a::<b> (c)

Is how you instantiate a generic. It's not that ugly. Bigger problem is value type generics/const generics where you want to do some logic like

     a<b > c>

> Bigger problem is value type generics/const generics

How does Rust solve the ambiguities with const generics?

The ambiguous const generics have to be surrounded by { }:

  fn function<T, { ambigous const generic expression }>(arg1: T) -> T {

I believe the current proposal (partially supported on nightly) is to require expressions in generic arguments to be enclosed in {}

The expression must be wrapped in curly braces: Type<{ expression }>

> The usual way to disambiguate in these cases is to check whether b is plausibly a type and treat it as a generic

Most compilers don't even go that far: using type information parsing is a huge no no for almost all languages that aren't C++. So for example, Typescript will flag:

    a<b>(c)

as an error if a, b, and c are untyped, meaning it automatically resolved the generic application in the parser before type information was processed, while this is fine:

    a<b>=(c)

Since the equal sign means > is part of a >= token. The parser is automatically determining if generic application was meant or not, before any type info is considered.

That's why I said "plausibly". From the TypeScript spec, it looks like it takes the Boolean grammar approach (treat it like a type expression if it's a valid type expression, otherwise don't):

The grammar ambiguity is resolved as follows: In a context where one possible interpretation of a sequence of tokens is an Arguments production, if the initial sequence of tokens forms a syntactically correct TypeArguments production and is followed by a '(' token, then the sequence of tokens is processed an Arguments production, and any other possible interpretation is discarded. Otherwise, the sequence of tokens is not considered an Arguments production.

Right...the big weakness of this approach are the error messages, which are fairly obtuse if you ever happen to run into this corner case. Luckily, most programmers won't.

If you need compatibility with C, JS or whatever, then you can't use square brackets for generics anyway. If you don't need such compatibility, why can't you just make that a function call and tell users to avoid funny combinations of comparisons and parens?

Reply on news.ycombinator.com