|
On 10/05/16 02:00 PM, Sean Conner wrote:
It was thus said that the Great Soni L. once stated:On 10/05/16 01:44 PM, Viacheslav Usov wrote:On Tue, May 10, 2016 at 5:54 PM, Michal Kottman <michal.kottman@gmail.com <mailto:michal.kottman@gmail.com>> wrote:The "mechanism" for your "policy" is strict.lua or any otherimplementation thereof. Not really. My policy is to guarantee that there are /no/ problems related to mistyped identifiers. Not just /this/ time I run my program, but /every/ time I run it. As far as I can tell, I /cannot/ represent that as a user-defined "policy", so your justification is not valid. I know that I could achieve that by using a language /different /from Lua. But I'd like to achieve that in Lua, and so I want to to understand why it is not possible. Cheers, V.So in other words you want explicit upvalue syntax? Upvalues as part of function signatures? Yeah me too! But I want it with defined order so my loadx lib[1] becomes more useful.I think he wants something like: global x -- define a global x function foo(a,b) local c -- define a local variable c = a * b + y -- compile time error---y not defined end To me, upvalues as part of a function signature reminds me of making exceptions part of the function signature in Java---it may be a nice idea to be explicit about such things, but it gets annoying quite fast (and you get aorund it by subclassing RuntypeException). It would also seem to be repeating yourself in code quite often. -spc
local function f() <> return function() -- no _ENV in enclosure, no _ENV in function return x -- error, no _ENV end end Doesn't look like a lot of repetition to me.As an extra would be to make load() take a list of upvalues and their values, value first, when loading plaintext code (defaults to `t, "_ENV"`) and a list of string-or-nil-separated upvalue values when loading bytecode. This would allow load() to load plaintext without _ENV, thus erroring on _ENV usage.
-- Disclaimer: these emails may be made public at any given time, with or without reason. If you don't agree with this, DO NOT REPLY.