1. Re: math.e and misc.e
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
