lua-users home
lua-l archive

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



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/