It shouldn't be necessary to quote keywords

[Adrian Sieber]

This works:

{
  value = "Hello",
  "optional" = false,
}

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

[Yann Hamdaoui]

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