Re: Just say 'YES' to strings (or not?)
Matt Lewis wrote:
>
>
> irv mullins wrote:
> >
> > Work like keeping track of pointers, garbage collection, etc.
> > Euphoria's selling points include "No pointers to run wild"
> > and "automatic garbage collection". Shouldn't those also be the
> > programmer's 'prerogative'? Do we want to do away with them?
> > How about integer types - should they go too?
> >
> > But if those are 'good things', then why is having a string type -
> > which keeps "John" from printing out as {74,111,104,110} suddenly
> > a bad thing?
> >
>
> This seems like a convenience issue to me. Or maybe I'm not clear as to
> what the issue is, but it reminds me of the type checking discussions that
> pop up here every so often, where the question always comes up: What is
> the purpose of type checking?
>
> Are you concerned that you can't keep track of the data type when you try
> to output it? I understand the complexities of printf can be daunting
> (it took me several months to figure it out, IIRC), but I don't see
> having a string type as being very useful. puts() handles 'simple' output
> requirements. No, it doesn't handle nested sequences, but those aren't
> really strings anyways.
Perhaps nested sequences of ASCII characters don't meet the definiion of
'strings', but as noted before, several other languages including Python
and Lua can handle them just fine, neither printing them as numbers, nor
halting on an error, as Euphoria is likely to do.
> For that problem, you'd need to introduce typed
> sequence elements first, which is a whole nother ball o' wax.
You would think so, but remember that neither Pyhon nor Lua have
types at all. Yet they manage things that look like strings without a
problem.
> This pro-string argument seems to say that the main reason for having
> a string type is that it helps us remember how it should be outputted,
> and maybe saves us some typing in the way of a printf() call.
>
> I really like being able to treat my strings as not-strings (which maybe
> we would still be able to do in a Eu-with-strings, so that may not
> be a valid objection), as opposed to using specialized string functions,
> and not being able to use the ASCII values as numbers without any
> conversion.
Do you really often add or subtract an integer from every character in
a string? That's the only use I can see for treating strings as non-strings.
You can't multiply or divide (and still have anything useful). Comparisons
and appending will still be comparisons and appending regardless of how
a variable is defined. The only affects of having a string type would be
to prevent entering a non-printable character, and to remove the need to
break a sequence into parts and choose different output routines based
upon what we 'expect' to be stored there. And sometimes being surprised
when something other that what we expect is actually there.
> As stated before, my principle objection is that a new primitive datatype
> would wreck Rob's data scheme, and the optimizations that we get because
> of it. ...
Perhaps he should have forseen that.
Irv
|
Not Categorized, Please Help
|
|
