lualint (Re: Static typing in Lua)

[Asko Kauppi <askok@...>]

In practise, this could mean having (optional) type names preceding  
Lua function parameters.

   local string function dummy( table t, int i, optional int j,  
optional number n )
	...
	local int x= i + (j or 0) + (n or 0)
	return string t[x]
   end

At least, to me, it's often easiest to think of an enhancement  
through some 'real' syntax, and see what can / cannot be done, with it.

1. Lua could understand the above type names -all being optional- and  
add in asserts accordingly:
	- check function argument types (runtime)
	- check variable assignments (runtime)
	- check return values (runtime)

This would make current assert-filled source code a lot easier to  
read, but would not provide any static-kind (compile time) "proof"  
that the asserts would not be triggered.

This would also allow for easy "boost mode" where such asserts would  
not be enabled, say for production use.

However...

2. The exact same syntax _would_ allow a further, static-kind (lint)  
preprocessor, that could do code analysis and actually reason out  
warnings that without knowledge of the programmer type tips would not  
perhaps be possible.

Doing such an analyser would perhaps be a bigger undertaking, but  
also it could be a separate tool (or part of luac), so that  
introducing it to the community would be as smooth as possible.

In fact, lua, luac, lualint, and luajit would make quite a Hit Parade  
by themselves!  :)

-asko


Gavin Wraith kirjoitti 27.7.2006 kello 21.37:

> In message  
> <c6c947f60607271027v5c186680wd3668c22302cf8fd@mail.gmail.com> you  
> wrote:
>
>
> > > I think nil has to have every type.
> >
> > I disagree. Nils are often "generated" by accidentally forgetting  
> > last
> > function parameter(s) or return value in some of function branches.
>
> I am sorry, you evidently misunderstood what I meant. My fault for
> not expressing myself clearly. What I meant was that in a statically
> typed language (which Lua is not, but I am musing about what
> aspects of Lua could be consistent with static typing), it would be
> necessary for nil to be a polymorphic value. So, were one foolish  
> enough
> to make the definition of mul_div that you mention and type it as
> (int,int,int) -> int then the nil result you mention would be a nil
> of type int. If nil is the value of an unassigned variable x and
> x has been typed as type t, then that nil is the nil of type t, if you
> see what I mean.
> How to type errors in a strongly typed language has always been a
> thorny subject in the semantics of type theories.
>
> Obviously, there is no hope for strongly typing things like arrays.
> However, it seems to me that by making a distinction between
> hashes and lists at the user level, and not just internally as Lua
> does, there is a possibility for some optimization. At present,
> I presume, when table accesses/assignments take place within a
> loop, the interpreter has to check which part, hash or list, is
> actually being accessed, each time round. If there were a distinction
> (as between hashes and arrays, as in Perl, say) then the check code
> could be lifted out of the loop.
>
> --
> Gavin Wraith (gavin@wra1th.plus.com)
> Home page: http://www.wra1th.plus.com/