Re: Ambiguous syntax

[Jay Carlson <nop@...>]

On Dec 17, 2012, at 1:48 AM, Dirk Laurie wrote:

> 2012/12/16 Sven Olsen <sven2718@gmail.com>:
>> 
>> The error in 5.1 was a good annoyance.
>> It did come up, but only rarely, and removing the error was always easy --
>> just a question of changing your formatting or dropping in a semicolon.  In
>> 5.2 I started catching the same little errors of intent during runtime
>> debugging -- meaning that they'd take minutes, rather than seconds, to
>> identify and fix.
>> 
> Maybe the debug library could be a home for a mechanism that
> controls error/warning options.
> 
> debug.option{ambiguous_call='warn'}

The error we're trying to catch happens at compile-time. The option could only apply to chunks loaded after this was set; notably it can't apply to the current chunk. In the case of promoting ambiguities/infelicities to errors, I don't think the results can be consistent.

Consider setting ambiguous_call to 'error' and then executing

  require("brokencode") 

The program will terminate--unless brokencode has been byte-compiled.

Similarly, soar (a script+modules packager) can't do anything reasonable, as it has compiled all of its modules and stuffed them into modules.preloaded by the time the main chunk runs.

I don't mean to say that control of warnings is a bad idea, but it either has to be something notionally part of luac.exe's command line option processing, or become part of the chunk syntax.