On Wed, 24 Mar 2004, guenter geiger wrote:
On Wed, 24 Mar 2004, Mathieu Bouchard wrote:
- "#X connect" lines would take any number of extra arguments, which
would have to be preserved by attaching an atom list to each connection and save that list when saving the connection. Ideally this would have to be put in all versions of Pd. Now, miller+devel branches may actually just ignore those extra arguments, and the impd branch would do something else with it.
.. so this means no changes, right ? Surely a possible extension.
It means some changes, because currently, Pd can load a patch in which "#X connect" has 5 or more arguments, BUT it does NOT save back the extra arguments.
if the {} do not present problems for the tcl/tk interpreter they seem to be the best choice.
They don't present problems for Tcl/Tk as long as they are balanced, because then they are exactly matching Tcl/Tk list semantics.
I am not sure though if pd supports nested lists.
Pd does not support nested lists, and isn't quite equipped to support them gracefully. This is partly linked to the fact that objects are expected to treat "float 42" and "list 42" the same way.
In GridFlow this is particularly exacerbated, as you may have to insert [float $1( or [list $1( messageboxes in places to fudge the interpretation of the data. I mean, GridFlow isn't really about nested lists, but its multidimensional lists ("grids") can be thought of as if they were nested lists most of the time. And then this problem appears:
"list 42" is a 1-list -> a 1-dimensional grid of size {1} "float 42" is a scalar -> a 0-dimensional grid of size {}
Are essentially different in GF but the same by Pd, and GF cannot be changed to match Pd, as this is fundamental to handling any-dimensional grids in a clean, uniform manner.
Now back to nested lists... compare the mess.
If they are effectively introduced, it'd probably be by adding T_LIST as an atom type. But that means that, to be like other atom types, a list message would have to have only one argument, of atom type T_LIST. But it probably wouldn't, because of backward compatibility, and so if you happen to have a "list" message containing just a T_LIST, this would be a 1-list containing only another list. Furthermore, you wouldn't be able to just take a "list" message and extract its value as an atom, as that atom would've to be constructed. In a list message, $1 refers to the first element of the list, not the whole list as an atom.
Yet another problem with nested lists is that they require some special memory allocation tricks. I would assume a reference-counting scheme would be appropriate, as a mark+sweep system is more difficult to get right.
I think you would only have to change the parser, and the converter from pd internal types to text representation. This should not introduce changes in too many places.
Cool, I'll try this eventually, though I'm not completely sure how I'll implement nested lists -- or how I'll avoid implementing them...
Considering that the language itself should be kept as simple as possible (everyone is happy that we do not have integer and float types anymore), I think, at least for the user, there should not be a distinction between symbols and strings. Where would we want to have strings ?
Günter, a symboltable is not meant to be used as a textprocessing playground. The way it's used in Pd right now, it's a big gaping glorified developer-approved memory leak. I guess it matters less nowadays, because with average textprocessing needs, even a gallery installation can stay up for weeks and months on a commonplace 512M RAM memory card, and I'm not even talking of swap partitions and swap files. Then the next barrier is the 2560M limit of virtual memory per process... under 32-bit Linux anyway... and I guess buying a 64-bit K8 -- with 16 billion gigs of virtual address space per process -- is easier than fixing a big gaping glorified developer-approved memory leak... :-}
I mean I can hear John McCarthy scream in disgust and abomination... (he invented the symbol type back in 1958...)
If there is too much resistance, I guess I'll continue developing them string features in terms of grids, but currently it's not possible to put a grid inside a list, so you can't do a list of strings of variable lengths, so it sort of sucks too. I guess they could be \0-padded ... I wonder how Jitter's string handling handles this case... if it does at all...
________________________________________________________________ Mathieu Bouchard http://artengine.ca/matju