lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]




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 other
implementation 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.