lua-users home
lua-l archive

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




Le ven. 16 nov. 2018 à 23:04, Sean Conner <sean@conman.org> a écrit :
Oh, then there are the various LISP machines, made in the late 70s---they
had tagged memory.  So in addition to the "data bits" part of the
"word", they also had "tag bits" that existly solely to impart type
information for the "data bits" part of the word.  So it's inaccurate to say
that a "word" is just a collection of undifferentiated set of bits.

Reread: you're reformulating what I told. I never said that a word was a collection of undifferentiated bits.

This is exactly the opposite that I said (and this is notably applicable to Lua "words" whose innner "bits" are differerentiated between datatype indicators and actual data (to represent numeric or string values or nil or table instances, or functions; we have to add also "closures", i.e. the instanciated contexts in which functions or coroutines are operating): "words" in Lua are tagged objects with a small size (fixed for each type, even if they are linked to other "words" to create a larger structure, notably for strings, tables, functions, and coroutines). The fact that these tagged objects have small fixed size allows storing them in a single "word" which are then countable and referencable, by the instruction set defined by the Lua VM.

So yes there's a valid concept of "word" in that context.

In Lisp the fundamental unit of information is the "node" in a binary tree: there's a differenciation only between the left and right links of the node (which is just an ordered pair), an in very few bits reserved in each link of the pair (allowing to differentiate a "nil" reference from an actual node reference, or a scalar value); both items of the pair are identifical and you could argue that the fundamental unit of information is one of these two items, but these items by themselves do not allow any contruction of larger data structures (lists, stacks, sets, tables, graphs...) and do not allow creating an ordered flow of instructions. Instructions in any Lisp VM are themselves represented by these "nodes" (so the language naturally has reflection/instrospection capability, it can even transform "functions", i.e. what they will do when executed).