Re: math.e and misc.e
- Posted by Juergen Luethje <j.lue at gm??de> Aug 03, 2007
- 474 views
Pete Lomax wrote: > Juergen Luethje wrote: > > > > introduce a NIL value in Euphoria. > > > > ...returned ... to unambiguously tell ... there was an error. > > I was thinking about some way to implement this without major impact > everywhere, > while fretting over the "unambiguous" part. My first thought was to use one > of the "unused : 011xxxxx xxxxxxxx xxxxxxxx xxxxxxxx" values (see execute.h) > but I realised that would break almost all the low-level tests. > > <font color="#330033">My next idea was </font><font color="#0000FF">to > </font><font color="#330033">create a </font><font color="#0000FF">constant > </font><font color="#330033">in the C source which was basically the string > </font><font color="#00A033">"NIL"</font><font color="#330033">, > but have a special test (isNIL</font><font color="#993333">(</font><font > color="#330033">x</font><font color="#993333">)</font><font color="#330033">?) > </font><font color="#0000FF">to </font><font color="#330033">test whether it was > the C </font><font color="#0000FF">constant > or some other "NIL" in the user code, but then realised that }}} <eucode> > global function get_element(sequence s, integer idx) > if idx<1 or idx>length(s) then return NIL end if > return s[idx] > end function > </eucode> {{{ > causes an ambiguity problem with get_element({1,2,NIL},3): you cannot tell > whether > you got NIL from idx out of bounds or s[3]. > > Trying to say "you cannot embed NIL in a sequence" causes another whole raft > of problems, and, general disagreement about this sort of code being shipped > in the standard libraries aside, if someone wants to return {ERROR,NIL} in > their > own code, they should be allowed to. > > Finally, it dawned on me there is probably a better way: > }}} <eucode> > -- file getelement.e > constant NIL="NI"&'L' -- avoid constant pooling > > global function get_element(sequence s, integer idx) > if idx<1 or idx>length(s) then return NIL end if > return s[idx] > end function > > global function is_my_NIL(object x) > return x===NIL > end function > <EOF> > </eucode> {{{ > Notes: > 1) the "avoid constant pooling" trick is need to prevent some other constant > NIL="NIL" pointing at the same object in memory. Any similarly calculated > float, > or a repeat() should work, but not a short int. > > 2) Since the NIL shown above is local to getelement.e, it is much less likely > it will end up in a sequence passed back to get_element, though: > }}} <eucode> > get_element({get_element({},0)},1) > </eucode> {{{ > would do the trick. Much better than a single language-level NIL anyhow. > > 3) Lastly, the === operator (or some other syntax) just instructs the compiler > to use EQUALS_IFW_I etc despite the fact the parameters are not initialised > integers. Hello Pete, I enjoyed reading your interesting thoughts. > In summary, instead of a single language-level NIL, allow multiple > user-defined > "unique" constants, and some "unique" test which can return true or false in > cases that equal() would always return true. Unfortunately, I did not understand how is_my_NIL() can distinguish a "NIL" that should signal an error from a string "NIL" that is by chance part of the data. Regards, Juergen