Re: math.e and misc.e
Pete Lomax wrote:
>
> CChris wrote:
> >
> > NIL wouldn't be unique?????? I hope I misunderstood you.
> NIL need not be unique, though there is nothing to stop you making a unique
> global constant named NIL.
>
This makes no sense.
The purpose of NIL is to define "something" - not a value - which would be
distinguishable automatically from any other type of regular Euphoria values.
> Multiple NIL might lead to safer code, and/or as an application coder you may
> actually WANT to distinguish between the NIL from beeble() and the one from
> bobble(), assuming you defined one in each.
I'm not sure. What is needed is a unique is_nil() test and any required variants
of it. Granted, the value may not be unique as it might carry any metadata.
For instance, s[0]=x would cause s to be "assigned to" NIL with a tag of "index
out of bounds (0), writing to a sequence". Again, you cannot assign NIL because
it is not a value.
>
> My reasoning is that it is technically a nightmare to implement NIL in the
> core
> language - there are some spare bit patterns but the number of things you
> would
> break attempting to use them completely rules it out.
>
I'm contemplating a brute force attack against the backend code 
It is well written enough, so that all the bit fiddling is inside macros. The
number of defined macros and macro calls is finite - the find-in-all-files search
option in COntext is a crude and effective xref tool for all #define first, then
all the calls that are of interest. Dynamic macro calls would be a problem, but I
don't remember there's any.
Rob, perhaps do you have this information on some scrap of paper? What is needed
is not simply the pattern list as provided, but the exhaustive list of all
combinations of tests actually used.
Once this is done, we can determine exhaustively which bit patterns are used and
how, and reorganise them so as to have more room for additional types, one of
them would be NIL.
> Instead, grant the application coder a "uniqueness" test, and let them worry
> about it, and maybe use it for other interesting stuff.
>
> What I am also saying is that NIL should not be part of Eu at all, unless the
> application coder defines one much like you would integer i or j.
Sorry, but I really think the opposite. For code to be reliable, the NIL should
not rely on any definition from the coder to be active or detectable.
It is definitely a core system feature. Otherwise, such a scheme is already
implemented by value(), for instance, and not everyone is happy about it.
CChris
> You could of course ship a "nil.e" standard include file, which I would
> neither
> support nor argue against.
>
> Regards,
> Pete
|
Not Categorized, Please Help
|
|
