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
Rather than parsing a normal func like < and an "extended" func like @<, and presumably extended extended funcs like @@<, each with their own enum cases, can probably go the J route and combine them all into one alphabet like <, <.. . isn't used in functions at the moment in order to make parsing decimal numbers dead easy, but the logic of adding it would not be much tougher than the existing @ notation. The only ambiguity would be something like <.5, which should favor the function. There are already certain instances that necessitate whitespace anyway.
Can be combined into one alphabet with something like
VM_LESS_THAN = '<',
VM_FLOOR = '<' | ('.' << 8)
etc.
This would remove the need for redundant f and g fields in the VmCell union, which currently segregate normal functions and extended functions respectively for pattern matching warning purposes.
The text was updated successfully, but these errors were encountered:
Rather than parsing a normal func like
<
and an "extended" func like@<
, and presumably extended extended funcs like@@<
, each with their ownenum
cases, can probably go the J route and combine them all into one alphabet like<
,<.
..
isn't used in functions at the moment in order to make parsing decimal numbers dead easy, but the logic of adding it would not be much tougher than the existing@
notation. The only ambiguity would be something like<.5
, which should favor the function. There are already certain instances that necessitate whitespace anyway.Can be combined into one alphabet with something like
etc.
This would remove the need for redundant
f
andg
fields in theVmCell
union, which currently segregate normal functions and extended functions respectively for pattern matching warning purposes.The text was updated successfully, but these errors were encountered: