1. Re: Eu vs perl, strings
Kat wrote:
> I think a *real string* handling library would help.
> I am spoiled by things like what is in the attached
> file. So i can do things like this code snippet:
OK, the light finally goes on. I was thinking that Everett was asking that
Euphoria be extended to handle strings as some sort of native type, instead
of wanting a library of useful routines.
Yes, these seem are reasonable requests. Wanna write them?
> And the annoying crashes caused by out-of-bounds testing
> of sequences is , well, annoying.
This was the primary motivation behind one of my 'robust' option for
Euphoria. Having programs fail because pixel() tried to draw out of the
screen boundary or, even more horrible, write to a location like {0.5, 3.5}
got pretty irritating. Before the introduction of short-circuiting, it was
even worse, because tests had to be written as:
if length( s ) >= n then
if s[n] ...
instead of:
if length( s ) >= n and s[n] ...
Anyhoo, I suggested that there be a 'robust' option, where instead of
choking, Euphoria would instead offer a reasonable data value back. For
example, floats would be coerced into integers, bad slices would return
empty sequences, etc.
The idea was that that eventually there would be a small cascading of
errors, until the coder's error-checking routines caught on that there was
some sort of problem, and gracefully recover.
In addition, when the first error was encountered, Euphoria would trigger a
user-defined data recovery routine. This would allow the application to save
the data the user was working, instead of losing everything (as it currently
does).
To say the least, the idea wasn't well received. The consensus seemed to be
that letting Euphoria crash and burn kept the data 'safe'. Even the
possibility of a user-defined error recovery routine being triggered on
fatal errors was very controversial - lots of complaints about it being
'abused'. *grumble*
For parsing, I finally caved and wrote my own 'safe' mid$ function.
> functions as include files will result in slowing down
> Eu to the point it is unusable, so imho they should
> be part of the core.
I used to get nervous about that, too. A lot of routines that I initially
thought should be in the core are actually implemented in high-level include
routines, and the speed is suprisingly good. If it's too slow, Robert will
just have to add some more optimizations.
-- David Cuny
