lua-users home
lua-l archive

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



On 10/05/16 02:20 PM, Sean Conner wrote:

It was thus said that the Great Soni L. once stated:

   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.


local function f() <>
   return function() -- no _ENV in enclosure, no _ENV in function
     return x -- error, no _ENV
   end
end

   Wouldn't this need to be?

	local function f() <>
	  return function()<>
	    return x
	  end
	end
No <> = old handling, and adding it to the outer function doesn't force you to add it to inner functions. The old handling means it'll try to fetch _ENV from the enclosing scope but if there's none, it'll act like an implicit <> (assuming no other upvalues would be used). 

I never intended to require explicit upvalues signature.

And this brings up another point:

	local print = print
	local cache = {}

	local function f()
	  return function(key) <print,cache>
	    print("DEBUG: key is ",key)
	    return cache[key]
	  end
	end

Or should it be:

	local function f() <print,cache>
	  return function(key) <print,cache>
	    print("DEBUG: key is ",key)
	    return cache[key]
	  end
	end

I could make an argument for both cases.  And is this for safety, or for
easy of serialization?
Both. Actually, it doesn't help with serialization, but it helps with dynamic upvalues (`load(string.dump(f))`, see loadx[1] examples). 

   -spc



[1]: https://github.com/SoniEx2/loadx

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