OpenEuphoria

Re: math.e and misc.e

• Posted by CChris <christian.cuvier at ag?iculture.?ouv.fr> Aug 05, 2007
• 495 views

Juergen Luethje wrote:
> 
> CChris wrote:
> 
> > Juergen Luethje wrote:
> > > 
> > > Robert Craig wrote:
> > > 
> > > <snip>
> > > 
> > > > Note that there is already a bit pattern that means "NO VALUE".
> > > > That's how the back-end detects uninitialized variables at run-time.
> > > > However I'm reluctant to make it a visible part of the language.
> > > > It might constrain future optimizations, features etc. 
> > > 
> > > Out of curiosity:
> > > Maybe you could give an example of such optimizations or features,
> > > which might be constrained by making that bit pattern a visible part
> > > of the language?
> > > 
> > > > In most cases the programmer can make up his own special code, 
> > > > meaning "error", or "not meaningfully initialized yet", 
> > > > or perhaps have several different codes for various kinds of errors.
> > > 
> > > In many (if not most) cases this is more ugly and complicated than using
> > > something like 'nil' or 'nan'. That's the reason why other languages
> > > have this, and why several Eu programmers have asked for it for years.
> > > E.g. in mathematics, it's quite "natural" that sometimes some values are
> > > undefined, so people want their programming language to privide a
> > > "natural"
> > > way to express this.
> > > 
> > > Regards,
> > >    Juergen
> > 
> > There is another way: let the runtime error happen, but allow for a handler
> > with retry/resume/exit/return ability.
> > 
> > This is called exception handling, and more languages have it rather than
> > NIL.
> > An exception handler is called only when there is no exception, so normal
> > execution
> > gets zero overhead.
> > 
> > As a result, signalling an error could be made simply by throwing n
> > exception,
> > processing it in a handler and, according to language capabilities:
> > * retrying faulty instruction
> > * skipping faulty instruction
> > * aborting
> > * executing cleanup conformant code (ie code interpreted in the context of
> > the
> > file/routine where exception occurred.
> > 
> > This way is completely independent from the type system - except that type
> > check
> > failures are exceptions -. So, contrary to NIL, there is a chance that such
> > a system could exist in Eu some day. 
> > 
> > Of course, conformant code would require a change of structure of the
> > backend,
> > since some canned tokens would have to be interpreted at unpredictable
> > places;
> > the current front end/back end structure doesn't allow this - which one
> > would
> > expect from a language that defines itself as "interpreted". And perhaps it
> > won't be implemented. It works in the 2.5 eu.ex.
> > 
> > CChris
> 
> NIL does not necessarily mean an error. It just happens naturally that
> sometimes some things are undefined or unknown. So IMHO it would be an
> advantage to have a clean and consistent way to express that. Just like
> there are atoms to express numbers and sequences to express e.g. strings.
> Maybe we won't get NIL in Eu, but the wish to have it is rather natural
> and obvious.
> 
> Regards,
>    Juergen

I completely agree, except that, even if NIL doesn't indicate an error, it
indicates a condition which will, in 99% of cases, lead to an error. And the
worst case is when the error doesn't occur.

CChris