On Thu, 5 Mar 2009, Martin Peach wrote:
Mathieu Bouchard wrote:
By floats, you mean a single float representing a single character?
Yes single character, any unicode character will fit in a float.
Well, my question was not about whether they'd fit or not in a single float, but rather whether you were talking about supporting sequences of float messages as being a string. I just wanted to make clear that i believe that a message sequence "72,101,108,108,111" should be converted to a single list message "72 101 108 108 111" to make things easier.
But now that I think of it, a float only represents a code-point. In most of the usage of unicode, a code-point = a character, but I've already encountered cases where I typed a character in two parts that are registered as one code-point each. I thought I never would.
But now, La Question Qui Tue: if you do a [string append] on two strings of different format, what should be the format of the output?
The first argument of the object would be the name of a table, with a [set( message to change it.
Well, my goal was to come up with an idea of a [string append] that isn't array-centric, for example, or at least, doesn't look like it when you try to use it with something else than arrays. But if the $1 of [string append] means an array name when it's a symbol, then it can't mean a symbol whose letters would be turned into list elements or array elements, for example.
Actually, there's another killer question: if you do a [string append] on two arrays, and that it is agreed that the output should go in an array, in which array does the output go?
If it's like a [strcat] it goes into the table named by its first argument, or the most recent [set( message.
Seems good.
I think instead of using zero to terminate the string the destination table should be resized to the length of the resulting string.
Ideally, yeah, many programming languages don't use zero-termination, including a bunch that used to use zero-termination and went away from it. (Those languages that used to still store it as a hidden element in the array, but that's an optimisation trick for interfacing with C, and it doesn't apply if your array is made of floats and not of bytes.)
It would be a lot better if arrays could be resized in more flexible ways. That way, you could gradually add elements to it without fearing of hitting a mountain of redundant reallocations, that is, one per character added in a long sequence of strcats of single chars.
For example, I made an implementation of t_binbuf in which "size" is distinguished from "capacity", and the difference between the two is some padding for future use. The capacity grows by bigger amounts than the size, so that the capacity doesn't have to grow as often. Many programming languages have arrays that work like this. Several of those also have an index for padding at the beginning so that you can gradually chop off elements at the beginning without having to copy the table a bunch of times.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec