They have managed to combine list and dict into one type (table) that
does the job of both.
You say "managed" as if it were some technical accomplishment, or that
the result is able to actually do the job of both: neither of these
assertions are true.
Have you actually *used* Lua? I quite like the language in certain
contexts where its appropriate, but if you've actually used it in real
code and found tables to be at all a substitute for *either*
dictionaries *or* lists, then I think somehow you've managed to actually
miss using either data structure in Python to any real extent, somehow.
Lua's tables are at very weak "dictionary-like" and "list-like" objects,
which indeed have been folded into one. To the detriment of both, at
least as far as they are an actual useful data structure.
You can't even get the equivalent of len(dict) in it: you have to
actually brute-force iterate the table and count manually. Even for a
purely array-like table with onlyn umbered indexes, #table can be
unreliable: its quite possible through normal list-like operations that
you perform on it, it can end up with holes where #table will fail.
Since it is *not* an list internally at *all*, but simply an associative
array with numbered indexes.
I could go on, and on, and on: but the fundamental *weakness* of Lua'
data types as data-structures is irrefutable, from its tables to strings
to numbers: they are incredibly weak on capabilities. You end up writing
all kinds of "library" functions to just do the normal things that
should be really easy to do.
Now, of course, there's really good reason why Lua is so simple in these
ways. Its entirely suitable for Lua as an embedded scripting language to
keep things very light, so it can be simple and fast. Good for Lua to
fill this niche superbly. But you can't start saying its simple
alternatives are at all comparable to Python's extremely rich and
capable data types.
And yes there are tuples.
No, there isn't. There's ways to create a tuple-like-thing which kind of
behaves like a braindead tuple, and functions have a positively bizarre
capability of returning more then one value (and accepting variable
values), so there's these points in the language where you have this
sort of Immutable Sequence, but its opaque until you unwrap it -- and
then it ceases to be.
That's not the same thing as having an immutable sequence that you can
store data in at your discretion, with a rich series of capabilities
that you can leverage.
There are no classes, but there are closures and other building blocks
that can be used to create any object-oriented type system
Not really.
Above, I spoke of tables as data structures, things just storing data.
But you're right, they are capable of more then that-- but you're
over-selling just how far that capability goes, by a long shot (and
underselling just how much work it takes to get it there).
Yes, tables have a limited series of 'hooks' that you can tie into to
alter their behavior, and through this you can simulate certain higher
order type systems as defined in other languages. In fact, lots of
people have done this: there's multiple "classy" libraries out there to
bring some kind of Class-or-Object-Oriented-Programming to Lua.
They work to varying degrees: but the hooks that Lua provides to tables
is still significantly lacking to really replace Python's
comprehensively dynamic object model, without a LOT of wasted cycles.
For example, while you can use __newindex to 'catch' someone setting a
new 'key' on a table, and and __index to replace or forward the actual
lookup, you can't actually capture someone trying to set a value to a
key which already exists. So, you end up having to do a full proxy
approach, where your table never actually stores anything directly
(except a reference to another hidden table), and so when someone goes
to set something you have to set it on the proxied object instead.
Because you can't let there ever be any real keys on the proxying /
external table.
So you're able to work around its lack a bit, to simulate something
/like/ what it means to have __setattr__.
But then you run into problems. There's no way now to iterate over the
table now, because pairs() will only return your internal hidden keys
that you're using to point to the proxied table (Although you can get
around this with some more complexity by hiding said key into a
closure-- but even then, you still can't iterate over the proxied
table's keys instead).
So what do you do? Well you go replace the global "pairs" function,
that's what you do! So it learns your particular style of Classness, and
interacts well. Hope you never use any third-party code which has even a
vaguely different kind of Classness. Alternately, you can just decide to
never use the standard idiom of iteration for your classes, and instead
one must always "for x in my_table:iter()" -- so now you have one kind
of code operating on 'real' tables, and a totally different kind
operating on your 'classy tables'.
And on and on. The point is, sure. Lua can sort of simulate different
OOP approaches, and Lua-folk are very adept at tweaking, twisting,
turning and ripping tables into all kinds of pseudo-data types that
match other paradigms, but its all hacks on top of hacks on top of
hacks. You end up with some *really* weird and/or messy code if you try.
Better to do Lua in Lua, instead of Python in Lua, or Java in Lua.
(just like
CLOS is defined by Lisp, not a part of the basic Lisp syntax). So I
imagine it would be possible to define an equivalent to the Python
type system in Lua, and compile Python to Lua. Lua can be compiled to
Lua byte code. Factoring Lua, out that means we should be able to
compile Python to Lua byte code.
--
Stephen Hansen
... Also: Ixokai
... Mail: me+list/python (AT) ixokai (DOT) io
... Blog:
http://meh.ixokai.io/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.10 (Darwin)
iQEcBAEBAgAGBQJMMPikAAoJEKcbwptVWx/l+aUIALYgpp7eilD2hCIl97gW/on9
ndNqIl124psO+CZVr/GwAPfk9GBdzd7BUOVNCKV3S7QetBD+PZ1aEe4jFKvEeH5g
pKLRgjg35FUCPKEmzH98gNu+VdAeIySquePaLOEX+AjdPI+SdoUrOaLsMdl8Wj18
JduBxzl4GosxbvqW4GkrOkEz9721BwjyMgvNhkMBodkl3X2hboNplf3QyPgJ9F3/
enYpRHQHESthzRaeGQePSLkG3EHgiQwaPxQIzMnzwftr8GlWyEWyZFmT8ivdzjVD
VjX8VbaRVpXausFreL1fAU3Ee9duoCiZk2R5Wq9woPNETHw2Z3PUdovQeqqPgGM=
=14eq
-----END PGP SIGNATURE-----
For example, as a