OpenEuphoria

RE: String type (was: if statement not working)

• Posted by bensler at mail.com Mar 22, 2002
• 439 views

Strings should be secondarily supported. Not in the core of the 
langauge, but as an extension of the existing language.

There isn't even a fully working string library that I have found in the 
archives. I have found some things, but they are buried and shadowed by 
the main function of the library that they reside in.
At least as far as newbie euphorians are concerned, the best that is 
available is a half finished attempt at making a general string library 
that seems to be outdated to boot.

Maybe there is a very functional string lib out there already, and I 
just need someone to point me to it, but RDS needs to SUPPORT some form 
of string handling, whether it's a stamped include file that someone 
else wrote, or core language. I'd rather see an include file.

I've started working on a lib to fit this description just earlier today 
actually. The functions that I posted ealier will probably be in there.

If noone can point me to a good, complete, dedicated string library, 
I'll continue working on mine.

1)  why 0..65535?, why not 0..255?

2) Almost all of the sequence prone irrationals of EU can be taken care 
of, if relational operators would also work for sequences. You still 
wouldn't be allowed to get a slice that is smaller than what you asked 
for, but you shouldn't be able to.

while I agree with 2a), it only partially addresses how EU handles 
sequence comparisons

2b) breaks from logic where you specify that you want s[1..10], but the 
length is only 8 so you get s[1..8] instead. This is not an intuitive 
nature, and I think would lead to subtler bugs then what we get now.
I would rather EU be strict instead of passive.


Chris

Sabal.Mike at notations.com wrote:
> As much of a purist as I am, I must concur that string handling, as well
> as handing errors caused by mishandling strings, is grossly inadequate
> in Euphoria.
> 
> I think it would be a fair statement to say that about half of all
> sequences (at some given level) are in fact strings.  When working with
> string splices and string comparisons, it is fairly safe to assume that
> most people want the simplest and safest operation possible, and let the
> interpreter be smart enough to self-correct errors.  Therefore, I
> propose the following additions (which have been proposed many times
> before) to meet these goals:
> 
> 1) A built in string type = 1-level sequence containing only integers
> ranging from 0..65535.  This should be no more difficult to accomplish
> than the built in integer type, and follows naturally with the existing
> concept of the language.
> 
> 2) A "with safe_strings" switch, defaulted to off, that would
> intelligently handle string related errors rather than crashing the
> program.  Use of this switch would automatically throw a warning rather
> than an error when such a condition is encountered.  The two following
> errors would be the easiest to fix:
> 
> 2a) if x[1..3]="I" then ... : Rather than crash, simply return 0.  It's
> intuitive, expected; and if well documented, won't cause confusion.  
> 
> 2b) referencing past the end of a string (i.e., x[1..inf]) should
> return up to the end of the string instead of crashing.  This
> intelligence would also take care of the ..length(x)] shortcut that has
> oft been discussed here, with the shortcut being the built-in atom
> "inf".
> 
> Personally, I believe these behaviors should be the default in any
> interpreter.  However, the safe_strings switch fits in better with the
> strict programming style paradigm that Rob adheres to.  I'm not
> expecting anything, but I would like to hear Rob's view on why these
> behaviors go against the Euphoria philosophy.
> 
> Michael J. Sabal
> 
>