Re: ? 1={}, is there really any other interpretation?
Jason Gade wrote:
>
> Pete Lomax wrote:
> > PS OK, the pop question may recurr at a later date "what does sq_eq()" do?
> > But
> > a core operator such as "=" should deliver one obvious answer and not, as
> > some
> > fools propose, vary between "if" and "assign" use, like "and" and "or" do,
> > where
> > this thread all started. (Keep the semantics clean.)
>
> Hey, now! That's not nice! ;)
>
> If you read the thread you can see that I've since amended my opinion on that.
>
> As someone who has been in the community for several years (but really hasn't
> written much of note) I've never needed to use compare() hence my
> unfamiliarity
> with its basics.
>
> So I still stick with the idea of switching equal() and compare() to compare
> sequences with other things (either atoms or sequences of different lengths)
> and leave =, !=, <, > to mean what they otherwise mean and return some
> kind of singular truth value.
>
> --
> "Any programming problem can be solved by adding a level of indirection."
> --anonymous
> "Any performance problem can be solved by removing a level of indirection."
> --M. Haertel
> "Premature optimization is the root of all evil in programming."
> --C.A.R. Hoare
> j.
I really think having a ternary logic (true/false/nil) would make a lot of
things easier.
nil would be a special value allowed for any type. Any operation involving nil
in its arguments should return nil (functions) or return immediately
(procedures).
(note: you can't test directly whether something is nil, since nil is neither
true or false - consider it as Not_a_Value, by analogy with NaNs).
The benefits:
* No longer need for functions to return special values on error, with subtle
problems arising from failing to check or wrong choice of the invalid value.
Return nil.
* No need to crash when a variable wasn't ever assignd a value and is being
read. Return nil.
* No need to crash when operating on sequences whose lengths don't match. Terms
in the result that don't make get sense are set to nil.
The caveats (I don't see them as drawbacks):
* There will be a need to introduce two extra flavours of the if statement:
+ if_nil condition then/elsif/else/end if will execute the then branch when
condition is nil.
+ if_not_nil condition then/elsif/else/end if will execute the then branch when
condition is true or false.
* The same has to be done on while statements.
* nil = not nil, which may be perceived as unusual. After all inf+1=inf, so is
it a problem?
* The problem: I expect some amount of code to break if this happens, since "if
not condition then" will execute the then branch only when condition is false,
and not when it is nil. For this reason I don't have much hope that nil will ever
make it in. But that's really too bad. Think about it twice before discarding it,
the advantages outweigh the issues.
CChris
|
Not Categorized, Please Help
|
|
