Re: Eu vs perl, strings
David Cuny wrote:
>Kat wrote:
>
>> I think a *real string* handling library would help.
snip
>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?
Before you and Kat get to enamored of what you think I am saying, let me
amend. A great deal of the string handling facilities could be handled in an
include library. I'll buy that one. But, strings are a type and they would eat
up so much overhead as a declared type that I don't think that it would be
practical, especially when you consider the items in the post that you
didn't read before you answered this one. Please refer to it.
>> 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.
snip
>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).
The robust option could actually eliminate many of the areas where an
error handling routine would be necessary, and it certainly would allow
testing for certain error conditions. It also could trigger some errors so
subtle as to almost defy testing. The only way around this would be for the
robust option to do something that would create an error that could be
tested for such as returning an atom or an integer for a sequence and
vice-versa. Short circuiting would make this a very cheap option.
However, I really think that we need a true error handling routine. Many
systems are just not allowed to crash, even if they have to start over. To
be useful, an error routine, has to have access to the context that created
the error. In Euphoria, I think that would mean that the error routine(s)
would have to act as an implicitly called procedure from the context of
the error with access to the valid variables at that level. Maybe, error
processing could be another one of those "with" options in which the
last parameter of the function or procedure would be the name of the
error procedure to be active within it's scope when the "with error"
directive is active.
Or maybe we could have something of the form of
procedure oops(seqence slip, sequence fall) with cleanup()
where cleanup() is the relevant error routine active in the scope of oops()
when "with error" is on.
snip
>possibility of a user-defined error recovery routine being triggered on
>fatal errors was very controversial - lots of complaints about it being
>'abused'. *grumble*
Luddites everywhere!
>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
Error routines have to be built in and include libraries alone cannot solve all
the ills of strings in Euphoria.
Everett L.(Rett) Williams
rett at gvtc.com
|
Not Categorized, Please Help
|
|
