[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Some questions on Lua's design
- From: Sean Conner <sean@...>
- Date: Mon, 1 Apr 2013 01:05:47 -0400
It was thus said that the Great Sean Conner once stated:
> > I get how all of that works- but I'm confused why there exists types other
> > than Tables at all. It would make sense to me if type declarations were
> > just sugar for table archetypes... Forgive me, I'm not talking about how
> > the language is used, but how it is designed and works under the hood.
>
> I'm going to step aside here and use a simplified LISP as an example. In
> this LISP, there are only two types, NIL and () (a list with no elements).
> Memory consists of CONS CELLS, which is conceptually two memory cells, both
> pointers. NIL is:
>
> +------+------+
> | NULL | NULL |
> +------+------+
[ snip ]
> You can use just this to represent everything else in LISP, including
> numbers. For instance, 0 is (), 1 is ( () ), two is ( () () ), etc. You
> can then define operations such as addition, subtraction, multiplication,
> what have you.
>
> But you run into a problem. A number like 65535, which can be held in 16
> bits, using *this* representation, requires 65536 CONS CELLS, which on a
> 32-bit system, would require half a gig of memory (64 bit system is a full
> gig, just to represent a number that could fit in 16 bits).
>
> And yet people have done just this. They've done this in the same way
> people have implemented RFC-1149 [1], not because it's practical, but
> because they can.
Oops. Got sent prematurely. Sorry about that.
Anyway, theorectical considerations are nice, but in practice, you still
have to run on existing hardware.
-spc
> [1] http://www.ietf.org/rfc/rfc1149.txt