Re: Constraints patch - help? [what about "native" multimethod dispatch?]

[Karel Tuma <ktuma@...>]

hello,

On Mon, Oct 23, 2006 at 03:34:44PM +0200, David Given wrote:
> Karel Tuma wrote:
> [...]
> > tab[do_something.."_"..type(arg1).."_"..type(arg2)](arg1,arg2)
> [...]
> > similiarly as for argument type constraints, this is partially implementable
> using
> > metatables, but not to the degree i'd call satisfactory.
> 
> Untested, but:
> 
> t = {}
> setmetatable(t, t)
> function t:__index(key)
> 	return function dispatch(...)
> 		local k = {key}
> 		for _, j in ipairs(arg) do
> 			k[#k+1] = type(j)
> 		end
> 		k = table.concat(k, "_")
> 		return rawget(self, k)(unpack(arg))
> 	end
> end

i'm using __index very similiar to yours.

the problem is you've to name your function like
function t.do_something_number_string(a,b) ... end
which is not much readable for some people.
... having sugar just for function t.do_something(number a, string b) .. end
would be more readable though.

> Now, whenever you call a method k on t, it'll actually attempt to call
> k_type1_type2_type3... instead. This strikes me as being rather simple code
> --- why do you consider such an approach unsatisfactory?

creating unique function closure for each function call.

> 
> I don't believe that such a thing belongs into the parser. Nobo

agreed

> [...]
> > function fun(s($==1 or $=="a"), n isnumber($))
> > 	local s2 (isstring($) and #$>5) = somethingcool(s)
> > 	return somethingboring(s,s2,n) isstring($)
> > end
> 
> Again, what's the difference between this and:
> 
> function fun(s, n)
> 	assert((s==1 or s=="a") and isstring(n))
> 
> 	local s2 = somethingcool(s)
> 	assert(isstring(s2) and (#s2 > 5))
> 
> 	local r = somethingboring(s, s2, n)
> 	assert(isstring(r))
> 	return r
> end

i'm fine with assert()'s too, my post was merely
bastardization-suggestion for asko.

> 
> ...? I find this considerably clearer to read, as well as not needing any new
> features. It makes it explicit the order of processing, for example --- in
> your example, the 'local' line has the assertions on the left of the
> expression, where the return line puts them on the right, which isn't terribly
> clear.

the posfix/prefix/infix does not really matter as it is very subjective
topic. the point was to allow in-place usage of existing syntax instead
of 'range' etc.

ps:
i love the way that lua is not only an extension
language, but also extremely extendible language - it's just fun to play
with lua internals. and i wish it'll stay that way, which is plain lua
being bare minimum with people sticking optional bloat to customize it
the way they like, a feature unseen in other scripting language,
simplicity with the spice of optional complexity is a true power of lua.

fear the day when the whole lexer/parser/codegen will be maintained in lua and
core C lua will be merely VM bytecode interpreter:
http://luaforge.net/projects/yueliang/
/* not likely to happen because lua is not that suitable for writing
 * self-compiler as ocaml is *g* */

//kt