4 ms·

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

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.

cwzwarich 7y ago
> 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 (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.
- unlinked_dll 7y ago
 Rust uses the "turbo fish" to get around this. Your example wouldn't compile unless a and b where valid variable names. a:: (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 c>
 - cwzwarich 7y ago
 > Bigger problem is value type generics/const generics How does Rust solve the ambiguities with const generics?
 - chrismorgan 7y ago
 The expression must be wrapped in curly braces: Type<{ expression }>
 - monocasa 7y ago
 The ambiguous const generics have to be surrounded by { }: fn function<T, { ambigous const generic expression }>(arg1: T) -> T {
 - unlinked_dll 7y ago
 I believe the current proposal (partially supported on nightly) is to require expressions in generic arguments to be enclosed in {}
- seanmcdirmid 7y ago
 > 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(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=(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.
 - cwzwarich 7y ago
 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.
 - seanmcdirmid 7y ago
 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.
- owl57 7y ago
 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?

cwzwarich 7y ago

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

unlinked_dll 7y ago
Rust uses the "turbo fish" to get around this. Your example wouldn't compile unless a and b where valid variable names. a:: (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 c>
- cwzwarich 7y ago
 > Bigger problem is value type generics/const generics How does Rust solve the ambiguities with const generics?
 - chrismorgan 7y ago
 The expression must be wrapped in curly braces: Type<{ expression }>
 - monocasa 7y ago
 The ambiguous const generics have to be surrounded by { }: fn function<T, { ambigous const generic expression }>(arg1: T) -> T {
 - unlinked_dll 7y ago
 I believe the current proposal (partially supported on nightly) is to require expressions in generic arguments to be enclosed in {}
seanmcdirmid 7y ago
> 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(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=(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.
- cwzwarich 7y ago
 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.
 - seanmcdirmid 7y ago
 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.
owl57 7y ago
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?