Re: Just say 'YES' to strings (or not?)
Matt Lewis wrote:
> Perhaps. :) But I think he found a nice compromise. If we can come up
> with a new scheme that doesn't sacrifice too much speed, then my concern
> would go away. This would satisfy the, "You don't have to use it,"
> argument for me. Basically, I perceive a small to zero benefit to me,
> with a guaranteed, but unspecified cost. Shrink the cost enough, and
> then I would "Just say 'YES' to strings." Not that it can't happen,
> just that no one has figured out a way to do it yet.
Well, there are already 'types' to be checked, so the type-checking code
is already there. One more branch shouldn't hurt much, and any extra
string handling-code should only affect strings, not atoms, integers,
or even sequences. Since string input and output are I/O bound anyway,
I doubt there would be any real impact on speed.
Where it would 'cost' (in a negative sense) would be in the 75% savings
when storing text. To be able to process roughly 4x as much data in memory
would be a big plus to some people.
Then it would also be possible to reduce the number of functions needed to
output stuff, resulting in a shorter learning curve, fewer errors, simpler
programming.
We'd also be able to use the = sign in a logical manner for comparing stringsm
and ditch that stupid equal().
When was the last time you wanted to compare two strings and get back a
sequence of ones and zeros? Is there any reason you could not get that
result by writing a simple loop, in the rare event you really needed it?
I'd say the benefits far outweigh the costs.
Regards,
Irv
|
Not Categorized, Please Help
|
|
