1. String type (was: if statement not working)
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
2. Re: String type (was: if statement not working)
On Fri, 22 Mar 2002 18:12:24 +0000, bensler at mail.com wrote:
>
>Strings should be secondarily supported. Not in the core of the
>langauge, but as an extension of the existing language.
>
I wholeheartedly agree. I can see a set of routines which encode
strings so that they hold 4 "characters" in a single sequence entry
(0.127), a variant which does a max of 3 (0..255) and a third more
complex variant which holds 3 or 4 bytes (if first is 127 then skip;
this entry only hold 3 bytes).
Take the last (and hardest) case; you suddenly *cannot* easily hard
code numbers in sequence slices.
This is an opportunity, not a stumbling block. (?Encapsulation?)
My point is this:
Code this (-or a much simpler doobrie-) in standard Eu; cover all
expected cases;
Post your best effort, expect it to be shot down/refined.
Figure the ones you need speed/easy syntax on, *THEN* ask rob to cater
for them in the core language.
Rob is just one man. We can help him with a concerted effort. (if it
was easy, he'd have done it already). We CANNOT help him with a
concerted winge.
Chris's "splice" function was a good start, let's work from there.
There are alot of good ideas out there. Ask yourself why you need Rob
to code them in C, in the heart of Euphoria, when you apparently
cannot code them for yourself.
Pete
