You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Shouldn't the compiler be able to recognize it as a key definition at this point? I don't see any ambiguity there (as far as my knowledge of the Nickel syntax goes).
The text was updated successfully, but these errors were encountered:
In all generality, we can't have all identifiers (variable names + field names) be metadata keywords, because it would be ambiguous: would {foo | optional} be an optional field, or a field foo with the optional contract applied?
That being said, I don't see any issue allowing them for fields alone, albeit being slightly more annoying implementation-wise (this is not a good argument, just the reason why it's not already the case 🙂 ).
Such a change raises the following question: how do you recursively refer to such fields, if normal identifiers can't refer to them? for example, you still couldn't write {optional = false, bar = if optional then 1 else 2} (because optional in bar is a normal identifier and can't be a keyword). I imagine the cleaner solution is to add raw identifiers, probably using the syntax r%id and/or r%"id" (maybe r isn't a good prefix, because we probably want raw strings as well). Whatever the syntax is, you could then do {optional = false, if raw_id%optional then 1 else 2}.
In fact this issue is already present today, because you can define fields that aren't valid identifier by enclosing them with quotes: {"some=>field" = true, bar = if ??? then 1 else 2}.
This works:
and this doesn't:
{ value = "Hello", optional = false, }
Shouldn't the compiler be able to recognize it as a key definition at this point? I don't see any ambiguity there (as far as my knowledge of the Nickel syntax goes).
The text was updated successfully, but these errors were encountered: