Internal compiler error when `\` is missing both source and arguments

[Grissess]

Hello again!

This is fairly easy to reproduce: when given

\method  -- oops

in a file, MoonScript version 0.5.0 produces this output:

issue.moon	Compile error: ...local/share/lua/5.4/moonscript/transform/transformer.lua:23: table index is nil
stack traceback:
	...local/share/lua/5.4/moonscript/transform/transformer.lua:23: in function <...local/share/lua/5.4/moonscript/transform/transformer.lua:19>
	(...tail calls...)
	/usr/local/share/lua/5.4/moonscript/compile.lua:476: in method 'value'
	/usr/local/share/lua/5.4/moonscript/compile/value.lua:120: in function 'moonscript.compile.value.chain'
	/usr/local/share/lua/5.4/moonscript/compile.lua:491: in method 'value'
	/usr/local/share/lua/5.4/moonscript/compile/statement.lua:96: in function </usr/local/share/lua/5.4/moonscript/compile/statement.lua:91>
	/usr/local/share/lua/5.4/moonscript/compile/statement.lua:91: in function 'moonscript.compile.statement.assign'
	/usr/local/share/lua/5.4/moonscript/compile.lua:530: in method 'stm'
	/usr/local/share/lua/5.4/moonscript/compile.lua:564: in function </usr/local/share/lua/5.4/moonscript/compile.lua:555>
	(...tail calls...)
	/usr/local/share/lua/5.4/moonscript/compile.lua:530: in method 'stm'
	/usr/local/share/lua/5.4/moonscript/compile.lua:564: in function </usr/local/share/lua/5.4/moonscript/compile.lua:555>
	(...tail calls...)

which is not very helpful in finding the root cause!

Despite this seeming like a bizarre circumstance, it's not too hard to instigate in with context; for example:

class Eg
	unary_method: (x) => print x
	nilary_method: => print!

with Eg!
	\unary_method 2
	\unary_method 3
	\nilary_method
	\unary_method 4

What was probably meant was \nilary_method!, but the compiler output is again unhelpful:

issue.moon	Compile error: ...local/share/lua/5.4/moonscript/transform/transformer.lua:23: table index is nil
stack traceback:
	...local/share/lua/5.4/moonscript/transform/transformer.lua:23: in function <...local/share/lua/5.4/moonscript/transform/transformer.lua:19>
	(...tail calls...)
	/usr/local/share/lua/5.4/moonscript/compile.lua:476: in method 'value'
	/usr/local/share/lua/5.4/moonscript/compile/value.lua:120: in function 'moonscript.compile.value.chain'
	/usr/local/share/lua/5.4/moonscript/compile.lua:491: in method 'value'
	/usr/local/share/lua/5.4/moonscript/compile/statement.lua:96: in function </usr/local/share/lua/5.4/moonscript/compile/statement.lua:91>
	/usr/local/share/lua/5.4/moonscript/compile/statement.lua:91: in function 'moonscript.compile.statement.assign'
	/usr/local/share/lua/5.4/moonscript/compile.lua:530: in method 'stm'
	/usr/local/share/lua/5.4/moonscript/compile.lua:564: in method 'stms'
	/usr/local/share/lua/5.4/moonscript/compile/statement.lua:235: in function 'moonscript.compile.statement.do'
	/usr/local/share/lua/5.4/moonscript/compile.lua:530: in method 'stm'
	/usr/local/share/lua/5.4/moonscript/compile.lua:564: in function </usr/local/share/lua/5.4/moonscript/compile.lua:555>
	(...tail calls...)
	/usr/local/share/lua/5.4/moonscript/compile.lua:530: in method 'stm'
	/usr/local/share/lua/5.4/moonscript/compile.lua:535: in method 'stm'
	/usr/local/share/lua/5.4/moonscript/compile.lua:564: in method 'stms'
	/usr/local/share/lua/5.4/moonscript/compile/statement.lua:235: in function 'moonscript.compile.statement.do'
	/usr/local/share/lua/5.4/moonscript/compile.lua:530: in method 'stm'
	/usr/local/share/lua/5.4/moonscript/compile.lua:564: in function </usr/local/share/lua/5.4/moonscript/compile.lua:555>
	(...tail calls...)

which especially gives no line numbers for large files :)

Arguably, \, like Lua's :, is not syntactically valid when not followed by syntax resembling a function call; I know the parser plays fast and loose here with value juxtaposition like some other PF languages, but it could at least be linted that a \ without associated call/arguments is an error during analysis, even if the grammar allows it.

[Grissess]

(GitHub's telling me there's a reply, but I don't see it--oh well.)

I guess there is a place where no argument list is needed: function stubs. That said, the interaction of function stubs with an ambient with object is troubled:

with obj
	x = \method

does not compile, for the reason above. It's arguable the expected result is that x is bound to a function stub obj\method, but I'm not committed to that :)