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
Consider passing arguments to a function call. Commas delimit arguments. The keyword and can be used, but only in conjunction with an Oxford comma; this restriction is so that an argument can be an expression which uses the logical and operator:
Result is function taking x, y, z (three arguments)
Result is function taking x, y, and z (three arguments)
Result is function taking x, y and z (two arguments: the second argument is the expression arg1 && arg2)
Now, consider the comma as a continuation character.
Result is function taking x,
y, and z.
I think that syntax should be valid, but but continuation rules say the , escapes the subsequent newline and is otherwise ignored, so this statement becomes:
Result is function taking x y, and z.
That's not valid.
OK, what if we allow newlines inside argument separators? That leads to this, which should be valid, but isn't, because the ,\n in this specific scenario is now an argument separator, not an escaped line break:
Put function taking x,
into result.
OK, so what if the grammar allows spaces between function arguments? These would all be equivalent:
Result is function taking x y z
Result is function taking x, y, and z
Result is function taking x,
y, and z
There are many scenarios where this could make it easy to introduce bugs in a Rockstar program, but I don't think it makes anything impossible; it just introduces a bunch of places where the parser might interpret the code incorrectly until you add in some commas or semicolons to eliminate the ambiguity.
Result is function taking Sweet Mary Anne (could be one, two, or three proper variables, but the variable name parser is greedy and will assume Sweet Mary Anne is a single variable, so if it isn't you'll need to add some commas)
Result is sum taking a b product taking c d (ambiguous but not actually invalid)
Can anybody think of anything that'll actually be impossible (or of another feature of the proposed language spec which will break) if we allow function arguments separated only by a space?
The text was updated successfully, but these errors were encountered:
I like the idea. It will require changes on parsing for sure, but the result is a more freeform text, less like a real list.
I think this could be applied to all other list expressions like arithmetic or array operations, too. At least it would be good to maintain a uniform format to define lists.
Consider passing arguments to a function call. Commas delimit arguments. The keyword
and
can be used, but only in conjunction with an Oxford comma; this restriction is so that an argument can be an expression which uses the logicaland
operator:Now, consider the comma as a continuation character.
I think that syntax should be valid, but but continuation rules say the
,
escapes the subsequent newline and is otherwise ignored, so this statement becomes:That's not valid.
OK, what if we allow newlines inside argument separators? That leads to this, which should be valid, but isn't, because the
,\n
in this specific scenario is now an argument separator, not an escaped line break:OK, so what if the grammar allows spaces between function arguments? These would all be equivalent:
There are many scenarios where this could make it easy to introduce bugs in a Rockstar program, but I don't think it makes anything impossible; it just introduces a bunch of places where the parser might interpret the code incorrectly until you add in some commas or semicolons to eliminate the ambiguity.
Can anybody think of anything that'll actually be impossible (or of another feature of the proposed language spec which will break) if we allow function arguments separated only by a space?
The text was updated successfully, but these errors were encountered: