Mathieu Bouchard matju@artengine.ca wrote:
Do you realise that the quoting problem can be solved independently of the allocation problem? In that case, you would be able to save any symbol and read it back. This would solve the problem about CR LF and spaces; only the problem with \0 (NUL) would remain.
If ascii values from 0 - 31 can be part of symbols that would be nice. How do you specify a symbol containing ascii values 1 2 and 3? Do they have names?
Symbols could be usable, if the problems that can be fixed in symbol without changing the nature of symbols, are fixed. You don't need strings for that.
You still have the problem of the symbol table that grows by one each time the symbol changes. If I want to parse a book one word at a time, for example, it would only take one string for the input buffer, but it would take as many symbols as there are different words in the book.
Wouldn't you want objects to be able to emit strings in a way as carefree as they are with symbols? I'm talking about not putting the burden of memory management on the emitter of strings.
A string library could have functions similar to getbytes(), resizebytes() and freebytes() for changing the length of strings that could be called by any other external in the library. Or pd could have the same functions that could be called by any external. Either way...
Martin