whats a codex?
a codex is a hybrid python data type (or acts like a hybrid type due to special handling.)

it combines the advantages of a dictionary and list.

a list is a dynamically-typed array. you can create a 0-item list with [] and place a value in it such as 0, then multiply it by whatever numeric you like to "dimension" the array: x = [0] * 10000000 ...is like dim x(0 to 9999999). lists always have an "lbound" of 0, and a "ubound" of len(listname) - 1

a dictionary is like a list, except while an array has a fixed number of items ("fixed" as in even if you resize, you cant put an item outside the dimensioned range) a dictionary HAS NO LBOUND (well, there are integer limits on what you can use to address an item, although thats just because there are limits on integers) and NO UBOUND (same integer limits apply.)

a dictionary is dimensionless; you can have a 1d array coinciding with a 4d array in the same dictionary.

but the items in a dictionary arent ordered-- you can ask for d(-100) or d(5) or even d("walts phone") but you cant *natively* split and join, you cant load easily from a file or copy a list to a dictionary without either a. translating or b. simply having an dictionary "with a list in it." (you can have a dictionary of lists.)

a codex is a (working) feature of at least one language im trying out, making it possible to *ditch lists/arrays altogether* and use just ONE multi-item variable/data type. (ints and floats and strings are still available.)

when you need an array, it automatically translates the list to a dict or a dict to a list, mapping a sorted keylist (its ordered, like an array) automatically.

thus if the user wants to use arrays as a bridge to dictionaries-- or if they just dont want to bother deciding between lists and dicts, they can just use codices for everything-- list-oriented functions treat a codex as a list, and dict-oriented functions treat it as a dictionary.

although its complicated to explain, the point is that its VERY EASY to use:

* x(5) can store either -10 or "hello" -- this is a feature of lists as well as dicts, mixed type arrays

* you can use x(2000000) (or any other valid integer) without having 2000000 or more items in the codex and without dim or redim

* you can use dictionary-based commands as well as list-based commands interchangeably, although you may clobber (renumber) keys in the process, it will preserve the order of the dictionary (like an array.)

* appending items does not renumber; it follows a predictable scheme (like an array. less like a dict.)

* unlike a dictionary, using a codex makes it possible to easily abandon the entire concept of arrays (by making it possible to do the same thing using a dictionary.)

obviously there are some drawbacks to making a hybrid-anything. codices simply offer more out of a single type. (or emulated type.)

i dont expect it to catch on, but i do plan to explain it so that people have the option of using it.

lists and dictionaries have enough in common that combining them has the potential to simplify both of these concepts-- unless someone is *trying* to simplify both, theyre probably just going to stick with the standards that exist.

if they are trying to simplify, i think codices are nearly perfect for the task/concept of a hybrid list/dict. if you did it in a slightly different way, you could probably still call the thing a "codex." its my own word for a list/dict hybrid.

then again, im excited about unums: https://en.wikipedia.org/wiki/Unum_%28number_format%29

* public domain
Thanks. I always thought a codex was just there to take over when the dex was having sex with the flight attendant. Oh well...

Hey, maybe Google can market this and start by placing this in their music store...

When I think back on all the crap I learned in C school
It's a wonder I can code at all
And though my lack of OOP sure hasn't hurt me none
I can code the functions one and all
codex Chrome
they give me those nice bright colors
they give me the greens of summers
makes you think all your strings are an array, oh yeah
I got a web-based camera
I'd love to put you on my drive
So mama don't take my codex Chrome away...

Oh, and know need to explain what a dict is to me. I'm being one right now. Actually, I'm just rattling around the forums a bit. I'm trying to get rid of this damn newbie id. Aside from that, I did find your article rather interesting but frankly, you really are talking a bit over my head. Therefore, I feel somewhat compelled to tell you to... oh wait, I used that in another post, sorry. Of course the dictionary meaning of a codex is a book, typically an ancient one. I suppose in regard to BASIC codex could be a well connected term.

I guess all this is "codec" stuff in Python was necessary because more modern languages rely more on working with Unicode. So many characters to read from a stream. I take it a codec in Python is used to speed up that process, especially say if something is a program is entirely in ascii.


What I don't know doesn't bother me. What I do know scares the hell out me.
in the simplest terms possible:

a variable is a value associated with an identifier (a name.) if it can only be set once, its a constant.

-- the way you reference a variable (get the value) is by its name. of course you know that, its for comparison.

an array is (in basic) a collection of 1 or more values *generally, of the same type* associated with a name.

-- the way you get the value is by its name and its numeric index. again, this is for comparison.

a list is (in python) a collection of 1 or more values, of one or more types (string, float, int, others) that is more or less like an array in basic. smallbasic is one basic dialect with arrays that allow more than one type per array. one can be a string, another can be numeric, etc.

-- the way you get the value is by its name and its numeric index. its basically an array, by any other name.

a dictionary is/like a linked list. its probably oop under the hood (in python, everything is oop under the hood, though its usually not something you need to worry about unless you prefer to do things with oop) although so are lists (and variables.)

-- the way you get the value is by its name and its KEY. pythons dictionaries are not ordered, instead of searching each numerically-indexed item for the value that you want:

basic: for x = arr$(lbound(arr$)) to arr$(ubound(arr$)): print (lcase$(arr$(x)) == "pete mobile") : next
python: exec("def lcase(p):\n" + chr(32) * 4 + "if type(p) == str: return p.lower()\n"+ chr(32) * 4 +"else: return p")
for x in range(len(arr)): print (lcase(arr[x]) == "pete mobile")

the first line there defines a special lcase() function that will return a numeric if given one, instead of type-erroring as lcase ought to. otherwise: def lcase(p): return p.lower() # there you go, a qb-style lcase command

...instead of searching each numerically-indexed item for the value that you want, a dictionary lets you do this:

arr = {}
arr["pete mobile"] = "(555) 867-5309"
print arr["pete mobile"]

but a key doesnt have to be a string-- you can partly simulate a traditional, numerically-indexed array by using numeric keys:

arr[1] = "pete"
arr[2] = "walt"
arr[3] = "michael"

however when you use alphanumeric keys (like arr["pete mobile"] = "(555) 867-5309") the values wont be in any predictable order. so you dont know what will happen when you iterate through them in a loop.

also, pythons various list-based commands (like split and join) dont work with dictionaries, so you cant fully replace lists with dictionaries, even if dictionaries can hold all the data that lists can.

a codex is just a dictionary with special handling to allow it to work with list-based commands like split and join and iteration in loops.

if you become familiar with dictionaries in python, then it should be easy enough to figure out what a codex is.

for people that ARENT already familiar with arrays or lists, a codex is a single type that can replace both dictionaries and lists.

python has arrays, lists, dictionaries, AND tuples. for one of my beginner-friendly educational languages, i prefer to offer just codices, so that codices can be taught and learned and used, rather than bother teaching arrays AND lists AND dictionaries AND tuples.

to make matters "worse", python can have a list of dictionaries of tuples, but codices are (so far) more restrictive than that. whether a codex could allow such a thing would be up to the designer of the implementation.
In QB i might want to keep a name, area code and phone number in a file. If it was a national directory such a codec system could help search all the 555 area codes, etc. I see that. In QB i had to assign a three-dim array and consider the phone numbers as strings to do somewhat the same thing. Of course the search would require a complete pass through all the arrays and I would see the advantage in speed if the area codes could be indexed.

"Of course the search would require a complete pass through all the arrays and I would see the advantage in speed if the area codes could be indexed."

not only that-- although its relatively complicated to explain this codex idea in terms of everything its capable of-- the whole point of it is that you get all the features of a dictionary, but that you have the option of using it *no differently* than an array. in other words, if you only want to use it like an array, you can.

you dont even have to dim and redim. you can just say x[1] = "whatever" or x[1000000] = "there are a million items in this array? no, it only uses up the entries you bother to set." in fact the bracket syntax [] is python; for a language like rose that implements a codex, you could have parentheses or even nothing at all: a 50 = "(555) 555-5555"
Never mind all that.... I just got 2-stars. Let's party!!!!
I like the concept of non-dim arrays quite a bit. Actually, I always liked QB for not having to bother with defining variables, too. It seems the language is actually more sophisticated that way. I recall trying C and feeling it was a damn waste of time, because I tend to use 100s of variables over the course of large apps. 


Oh damn... now it refers to me as junior. Son of a b....