lua-users home
lua-l archive

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


Mark Hamburg kirjoitti 29.2.2008 kello 2:11:


on 2/28/08 11:16 AM, Asko Kauppi at askok@dnainternet.net wrote:



LuaSub gives '-sjacket' for making runtime type checks, and it works
like this:

tests/test-jacket.lua:

local function mydear( t :string_or_table, i :int, j :[int], n :
[number] )
 : string, table, [int]
...function body with returns...
end

't' is either string or table (checked by 'assert.string_or_table()')
'i' is integer ('assert.int()')
'j' is an optional integer (nil or fulfilling 'assert.int()')
'n' is ...


It's interesting syntactic sugar. Obviously this could be handled by
assertions in the code but sugar might increase the chance that they would 
get written.
This is exactly the point. I've often used assertions like that but this just makes it 
	- in one place (also returns)
	- less verbose
Are they optional on a compilation and if so how do you switch them on and off? Maybe if they only applied to functions it wouldn't matter as much. 

The syntax mod can be told to just skip them.

This will turn them off (just skip them in the source):

	luas -sjacket.OFF yourfile.lua
I used to have different mods for the 'off' and 'on' modes, but the way to signal the one mod is way better; it needs to know the syntax of the extension anyways. Jacket is the only mod I currently use arguments for, but the mechanism is available for any mod for any purpose.
Maybe a tracing JIT makes their cost drop low enough in practice so as not to matter. And if optional, one needs to be careful not to have any side 
effects in the functions.


Well, 'assert.*()' functions should hardly have any side effects. :)




But I like the general notion.


Thank You!  :)
Have you taken any of the standard benchmark code and added type assertions 
to see what sort of expense they incur?
Nope. I'm currently in the process of transforming Lumikki (XML generation) to use them. I'll draw my performance numbers from that, but you're welcome to test with anything.
Note that some code suits badly to any constraints. That's why they are _always_ optional anyways. You can say: 

	a			-- just the parameter, no constraint
	a : table		-- use built in constraints
	a : my_table	-- any assertion about how your table is expected to be
or even
	a : { a=int, b=string, ... }	-- a bit strecthing, but also this works
Constraining also the writing to variables is not implemented, yet, but would follow the same syntax. 

-asko





Mark