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
On Mon, 18 Dec 2006, martin.peach@sympatico.ca wrote:
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?
Do it the way most languages have borrowed from C : use backslash followed by an octal or hex code, like \033 or \0x1b. It's easy to make it compatible with C/C++/Java/Perl/Python/Tcl/Ruby/PHP, all at the same time.
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.
Well, you can solve that problem separately. There's no point to clump all issues into one ball.
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()
Yes, that's putting the burden of memory management on the emitter. I mean, what I call "the burden of memory management" isn't about writing your own malloc() from scratch, no, I'm not talking about that, I'm talking about having to decide when to copy and when to deallocate.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
-
martin.peach＠sympatico.ca -
Mathieu Bouchard