On Wed, 4 Mar 2009, Martin Peach wrote:
Mathieu Bouchard wrote:
Tables can be much faster but they also need to be statically-allocated (or dynamically-patched!), and they are type-restricted (where you can't say that any element slot may contain any atom one decides at runtime), and you have to find names for the tables because they can't be anonymous.
For the network objects the lists are made of floats so the type restriction is not important.
Right, but when it comes to making reusable classes, you have to choose between type-restricted statically-allocated, and freely-typed stack-allocated, and whatever class you make for processing lists doesn't work on arrays, and whatever class you make for processing arrays doesn't work on lists. Is there any way around that problem?
Also a table can be reused and resized and its contents never get added to the symbol list so there's no constantly increasing memory involved.
The symbol-table is a separate issue. You could make use of lists with mixed floats and symbols freely in lists and always reuse the same symbols, or you could be mixing floats and pointers.
The typical web page has a huge amount of irrelevant text that would quickly clog the symbol table, so it's more efficient to extract the relevant bits before converting any of it to a symbol.
I never ever mentioned converting a web page into a bunch of symbols.
I'm concerned about the proliferation of list-operations and the duplication between list-operations and array-operations and how it will tend to inflate the number of classes and by default (if the design of classes just goes the usual way) the interfaces of those two sets of classes won't be synchronised with each other, so it will mean more documentation to make and especially more documentation to read.
Tables also use half as much memory as lists
yeah, but you saw the price of RAM ? ;)
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec