Re: math.e and misc.e
- Posted by CChris <christian.cuvier at agricult?re.gouv.?r> Aug 05, 2007
- 592 views
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