gmane.comp.lang.lua.general

Tim Channon | 2 Oct 15:09

Unexpected behaviour

Where does argument 3 go?

tagclass = {}
tagmetatable = {__index = tagclass}
function tagclass.new (kind, args, body)
  local self = {}
	self.kind=kind
	self.args=args
	self.body=body
  setmetatable(self,tagmetatable)
  return self
end

function tagclass:show()
	print("kind",self.kind)
	print("args",self.args)
	print("body",self.body)
end

xx=tagclass:new("kindp", "argp", "bodyp")

xx:show()

kind	table: 00887f48
args	kindp
body	argp

headers

Dirk Feytons | 2 Oct 15:16

Re: Unexpected behaviour

On Thu, Oct 2, 2008 at 3:10 PM, Tim Channon <tc <at> gpsl.net> wrote:
> Where does argument 3 go?
>
>
> tagclass = {}
> tagmetatable = {__index = tagclass}
> function tagclass.new (kind, args, body)
>  local self = {}
>        self.kind=kind
>        self.args=args
>        self.body=body
>  setmetatable(self,tagmetatable)
>  return self
> end
>
> function tagclass:show()
>        print("kind",self.kind)
>        print("args",self.args)
>        print("body",self.body)
> end
>
> xx=tagclass:new("kindp", "argp", "bodyp")

This is syntactic sugar for

xx=tagclass.new(tagclass, "kindp", "argp", "bodyp")

You have to call your new() like a regular function:

xx=tagclass.new("kindp", "argp", "bodyp")

(Continue reading)

headers

Tim Channon | 2 Oct 16:27

Re: Unexpected behaviour

Dirk Feytons wrote:

>> xx=tagclass:new("kindp", "argp", "bodyp")
> 
> This is syntactic sugar for
> 
> xx=tagclass.new(tagclass, "kindp", "argp", "bodyp")
> 
> You have to call your new() like a regular function:
> 
> xx=tagclass.new("kindp", "argp", "bodyp")
> 

Ah, thanks. Looks like I've been caught again by shorthand. 

I'm struggling with a language where I have no mental model, rather too
abstract for me. Part of what I am trying to work towards is use a
technique I think I last used in modula where it is trivially easy. This
would be a dynamically decorated trie where the leaves are executable,
data driven.

This is most easily explained by example: might be a patricia trie which
can be runtime fed with t4 fax huffman codes and routines. T4 data can
then be walked into the trie and the leaves executed, decoding the fax.
In practice this proved faster executing than commercial assembler
decoders, which was a surprise.

Lua obviously would be much slower but that doesn't matter. (especially
as computers are slightly faster many years later)

(Continue reading)

headers

Ralph Hempel | 2 Oct 16:45

Re: Unexpected behaviour

Tim Channon wrote:

> I'm struggling with a language where I have no mental model, rather too
> abstract for me. Part of what I am trying to work towards is use a
> technique I think I last used in modula where it is trivially easy. This
> would be a dynamically decorated trie where the leaves are executable,
> data driven.

The idea of mental model is important! I used FORTH for many years, to
the point where juggling stack frames in my head became second nature.

When I started programming in C 20 years ago, having FORTH and assembler
and linker experience allowed me to mentally model pointers and data
structures in physical memory.

Moving to a new language requires a new mental model, and Lua is no
different. Keep at it, and eventually the light will come on and
burn brightly.

> The point though is it can be dynamically altered. (at that point the
> brain hurts)

It gets worse as you get older 

Ralph

headers

Cimarron Taylor | 4 Oct 18:46

Re: Unexpected behaviour

 | I'm struggling with a language where I have no mental model, rather too
 | abstract for me.

If that's the case then I would recommend reading 
"The Implementation of Lua 5.0" - http://www.tecgraf.puc-rio.br/~lhf/ftp/doc/jucs05.pdf

Regards,

Cimarron Taylor

headers

Tim Channon | 4 Oct 22:54

Re: Unexpected behaviour

Cimarron Taylor wrote:
>  | I'm struggling with a language where I have no mental model, rather too
>  | abstract for me.
> 
> If that's the case then I would recommend reading 
> "The Implementation of Lua 5.0" - http://www.tecgraf.puc-rio.br/~lhf/ftp/doc/jucs05.pdf

Nice one thank you. A first look that, is a useful and very interesting
paper. Always is when discussion is taking place about design tradeoffs.