Re: Type-checking trick

[Tom Wrensch <twrensch@...>]

You type checking solution is clever, but I'm not sure it will solve the
problem you want to solve. The difference between what you're doing here
and what C or Java does when it type checks is *when* the type check
happens. In C and Java a type error is found at compile time, in your
program it's found at run time.

The differences is that you have to actually execute a piece of code to
check if it is passing arguments of the correct type. More importantly,
you have to check every possible call point to be sure that each place
that calls the function is passing values of the correct type.

As a quick example:

    -- This function checks its arguments at run time
    function test(num, tab)
        assert(type(num)=="number")
        assert(type(tab)=="table")
        tab.value = num * 2
    end

    function main(num)
        assert(type(num)=="number")
        local t={}
        test(num, t)  -- This is okay
        if num < 0 then
            test(t, num * -1) -- This is not
        end
    end

Note that the type error in the function main() will only show up if its
argument is less than 0. If this is rare, you could go through a lot of
testing, and still miss that one case. It will, of course, then turn
around and bite you on the first real deployment.

Having said that I should point out that I've been involved in quite a few
Smalltalk development projects, two of which were quite large (100,000+
lines of code). Smalltalk has the same "problem" in that it does not have
static type checking. We very rarely found these sorts of type errors to
be a problem.


  - Tom Wrensch
  

On Thu, 25 Jul 2002, Reuben Thomas wrote:

> One of the problems I've been thinking about recently is type-checking in
> Lua. The main reason is that I'm trying to persuade my employer to use Lua
> for application programming. This might sound mad, but the context is that
> we have a large (~1M lines) C code base with an API that does not support
> good productivity (neither the API, nor the fact that it's in C), and it's
> impractical to reimplement, so building a better API on top in Lua seems 
> like a way to make application programming more productive, fun and the 
> system more modular (as the C hidden by the Lua API can now be 
> re-engineered).
> 
> The biggest disadvantage of Lua over C is the lack of static type-checking 
> (there are few other disadvantages I could think of; we write database 
> admin systems for hospitals, so the system spends most of its time waiting 
> for the user and the rest waiting for the disk; the performance of the Lua 
> code is not an issue).
> 
> Now, it's possible to typecheck assignments to globals easily: simply tag 
> the object, and set appropriate getglobal and setglobal methods. Locals I 
> can't think of a way of typechecking, but that problem will largely 
> disappear in Lua 5, when you can have nested global tables. The one 
> remaining problem is checking that the arguments to functions are correct. 
> It's easy to do this simply by checking them at the top of the function, 
> but this isn't nice to write. However, you can easily write something 
> like:
> 
> function fun (typeList, func)
>   return function (...)
>            local len = getn (typeList)
>            if len ~= getn (arg) then error...
>            for i = 1, len do
>              if tag (arg[i]) ~= typeList[i] then error...
>            end
>            return call (func, arg)
>            end
> end
> 
> which takes a function and generates the appropriate checking code, like 
> this:
> 
> f = fun ({Int, String},
> function (i, s)
>   print s .. " " .. tostring (i) 
> end)
> 
> so that it's a bit nicer to write.
> 
> Has anyone else tried something like this?
> 
> -- 
> http://www.mupsych.org/~rrt/
> L'art des vers est de transformer en beautés les faiblesses (Aragon)
> 
>