OpenEuphoria

Re: String?

• Posted by irv mullins <irvm at ellijay.com> Jun 01, 2004
• 656 views

Derek Parnell wrote:

<snip>

> What would be the advantage of this? Well it would mean that Euphoria
> would be able to trap assignments of non-Unicode characters to string
> elements (characters?). Sure this can be done now with the 'type' system
> but a built-in method that is consistant, faster, and automatic is better
> than the generic 'type' method.

Obviously, the user 'type' system does slow things down (significantly) 
when doing something like checking a long string character-by-character.
So it would be better if it were built into Eu itself - like the integer 
checking. Add to that the fact that user-written type checking does 
nothing to simplify or eliminate errors when doing output, so it's a 
half-solution at best.

Consider this, however: 
Strings can reasonably be expected to be entered either in the source 
code, where no one in their right mind would go to the trouble to do it 
this way: name = {74,111,104,110}

or via keyboard, where they get entered character-by-character - 
meaning that if you actually were to type '{74,111,104,110}' and 
hit enter, you would not have anything resembling "John".

It seems to me that it shouldn't be too difficult to say that 
a leading '{' could always tag the input as a sequence of objects, 
while a leading '"' could tag it as a string. 
Just like:
constant a = 'A'
constant b = "A"
Note that these produce different results, based solely on whether 
a single or a double quote is used.

Makes me wonder why, if that can be done, what is it so hard to 
differntiate between a double quote and a curly bracket?

In neither of these cases would there be any significant slowdown, 
the first would be done at parse time, and the second would be limited by 
typing speed. Only in the (rare) instances where math is performed on 
strings would there be any chance of slowness actually being a factor.

> It would also mean that other built-in and library routines could perform
> processing more relevant to the data. Such as displaying the value in
> string notation "John" rather than numbers. 

And it would do away with the multiple-choice quiz everytime we want 
to output something. This is a major point of confusion for newcomers 
to Euphoria, and just causes extra work for all of us.

> So in the end, it really depends on whether RDS can risk the costs
> for the benefits.

I think it depends more on whether the design of the language allows 
for another type. There was discussion on this list years ago regarding 
this, and I believe a bit of detective work indicated that it was not 
possible. 

Regards,
Irv