Re: math.e and misc.e

new topic     » topic index » view thread      » older message » newer message

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

new topic     » topic index » view thread      » older message » newer message

Search



Quick Links

User menu

Not signed in.

Misc Menu