1. Re: Just say 'YES' to strings (or not?)
irv mullins wrote:
>
>
> 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.
Actually one more branch would hurt, because Rob doesn't have any more
bits to work with, so he'd have to use some additional storage, or
completely different way to store type data. It may be possible to achieve
similar performance with some other scheme, but if so, I don't think that
anyone has stumbled upon it, and I'm skeptical that it exists.
> 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.
I agree, although it's not much benefit to me, personally, which was how
I was valuing the changes.
> 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.
Maybe, although it might also increase the number of output functions.
Could we still output a sequence as a string? How are literals handled?
What if we append an integer (really meaning a character)? I suspect
that you'd still have all the same, plus a new pretty print type procedure
that dealt intelligently with your data. Not really a big improvement
over what we have now.
> 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?
Yes, I agree that this is probably backwards (not caring about the
orthogonality of operator usage, of course...)
> I'd say the benefits far outweigh the costs.
I know. And I'd still say the reverse. :)
Matt Lewis
