What happened to "if-not"?

[jopython]

I see that if-not has been deprecated in the manual. But  the code patterns document for 10.5.0 still mentions it.

[cormullion]

I hope not. No point in changing the basics of the language at this point, surely?

[TedWalther]

We already have unless. I support the loss of if-not.

[xytroxon]

We already have when. I support the loss of if. ;o)



Simply reversing the logic of a test is easy with if-not



(if test then else)

(if-not test then else)



Reversing the logic of a test is messy without if-not



(if test then else)

(if (not test) then else)



Typically, I use the then clause for the active code and the else clause for the exception code.



But...



When the execption becomes the rule: testing during development, short term changes, etc. if-not has saved me time when finding and undoing those changes later. Refactoring  code by swapping the then and else clauses is less than an optimal solution in those cases.



Also the dualistic truth - untruth nature of logic speaks to the need for the "if-not" to compliment the "if"...



"When you have eliminated the impossible (aka IF-NOT possible), whatever remains, however improbable, must be the truth." -- Sherlock Holmes



And while the "if" of matter fills most of the visible universe, it is the "if-not" of antimatter that matters the most when the chips are really down...



------------------



From Star Trek: 'Obsession'



Kirk : 'IF-NOT seems our only possibility.'



Spock : 'An ounce should be sufficient. We can drain it from the newLISP executable, transport it to the planet's surface in a magnetic vacuum field.'



Kirk : 'Contact medical stores. I want as much haemoplasm as they can spare in the transporter room in fifteen minutes.'



Garrovick : 'Yes sir.'



McCoy : 'I presume you plan to use the haemoplasm to attract the creature?'



Kirk : 'We must get it to the IF-NOT. It seems attracted to red blood cells, what better bait could we have?'



Spock : 'There is still one problem, captain'



Kirk : 'The blast, yes.'



Spock : 'Exactly. A newLISP IF / IF-NOT blast will rip away half the planet's atmosphere. If our newLISP program is in orbit and encounters those shock waves...'



Kirk : 'A chance we'll have to take, Mister Spock.'



------------



And finally...



The negatively biased, space monster destroying, scofflaw "if-not" is appreciated with approval and full support by a modern lisp.



-----------------------



ClojureDocs

http://clojuredocs.org/clojure_core/1.2.0/clojure.core/if-not">//http://clojuredocs.org/clojure_core/1.2.0/clojure.core/if-not



if-not

clojure.core



    * (if-not test then)

    * (if-not test then else)



Evaluates test. If logical false, evaluates and returns then expr,

otherwise else expr, if supplied, else nil.



--------------------------



Do not condemn the condemned "if-not" scoundrel to obscurity and a slow death... Law and order and cheaply produced 1960s TV science fiction would be adversely changed (--- insert overly dramatic silent pause here ---) forever... (--- insert eerie, fading, distant wind sound here ---)



-- Prof. Moriarity er. xytroxon

[cormullion]

:)



The function will "keep working for an indefinite time". More Doctor Who than Sherlock?

[rickyboy]

I support getting rid of if-not.  In short, I don't see how if-not can be viewed as a "semantic corollary" to if, in light of http://www.newlispfanclub.alh.net/forum/viewtopic.php?f=15&t=4383">the discussion about the semantics of if we had only a while ago.



Here's a recap: if is a general conditional which acts more like a cond in other Lisps, supporting multiple tests and corresponding consequents (i.e. what to evaluate when the test is truthy). In fact, newLISP's if is almost exactly like http://clojuredocs.org/clojure_core/clojure.core/cond">Clojure's cond, except newLISP's is slightly better: it doesn't need the :else syntactic sugar of Clojure's cond.



So, in newLISP you can say something like the following.

Code Select Expand

(if t1
    c1
    t2
    c2
    t3
    c3
    c4)
and whichever test is first truthy -- the tests being tried in order, first t1, then t2, then t3 -- its corresponding consequent will be evaluated and that will be the value of the if.  Pretty clear.



The traditional usage of if, namely

Code Select Expand

(if test consequent alternative)
is just a special case of the more general if that newLISP has.



So, in light of that, what does if-not now mean?  For instance what does the following mean?

Code Select Expand

(if-not t1
        c1
        t2
        c2
        t3
        c3
        c4)
Are we supposed to negate every test?  That is, does it mean the following?

Code Select Expand

(if (not t1)
    c1
    (not t2)
    c2
    (not t3)
    c3
    c4)
Or should it mean the following?

Code Select Expand

(if (not t1)
    c1
    t2
    c2
    t3
    c3
    c4)
Or should it mean something else?



Hence, in light of the semantics of if, if-not could be a very confusing expression for the coder to work with. Thoughts?

[cormullion]

Thoughts...



You may indeed be technically correct - and there may indeed be some logical semantic justification for removing it. However:

The main difference to other programming language philosophies is, that some of newLISP's traits are influenced by thinking that is normally not found in the community of programming language geeks.



I think it is less about "consistency" or "it has feature x" as it is about categories like "beauty", "feeling right", "intuitivity", "learnability" etc. whereby the judges of these categories are not the only the geeks but the average user. People who are experts in other areas which are not programming languages...

(then the author goes off the rails a bit... :).



You've not persuaded me that if-not should be removed at some unspecified time in the future, breaking not a few pieces of code in the process, requiring the inserting of a more complicated construction, plus consequent testing, uploading, etc., just to make an important semantic point, or to remove one of the thousands of ways a new user can write bad code. I can't see any other benefit for removing it (from the code base or from the documentation) - how many bytes will it save?



I missed any discussion of this proposal before - but I do remember arguing against changes that broke code for no good reason. Anyway, ricky, if-not was http://www.newlispfanclub.alh.net/forum/viewtopic.php?f=5&t=2388">your idea in the first place!

[rickyboy]

Anyway, ricky, if-not was http://www.newlispfanclub.alh.net/forum/viewtopic.php?f=5&t=2388">your idea in the first place!

Ah! It was all that svengali Kazimir's fault! :)



Seriously, that issue was about aligning unless (the old "if-not") to when, and not about having an if-not in the first place, because in fact, we always had an if-not: it was just called unless before.

You may indeed be technically correct ... You've not persuaded me that if-not should be removed at some unspecified time in the future ... just to make an important semantic point, or to remove one of the thousands of ways a new user can write bad code.

I think this is my fault.  Sorry. I didn't mean to be arguing a pedantic point (but I did).  Here is the practical argument: I asked what (if-not t1 c1 t2 c2 ...) should mean, at the end of my last comment.  I had not tested this before, but apparently in the current newLISP, it means that all arguments beyond the third one are ignored (i.e. if there is a third argument, it always will be "the else clause").

Code Select Expand

> (if-not 1 2 3 4 5 6)
3

At the present time, it definitely does not mean the following.

Code Select Expand

> (if (not 1) 2 3 4 5 6)
4

Oops. :)



So, the semantics of if versus if-not are not as similar as one might think, and this could be the source of confusion.



But really, I don't have a dog in this fight.  To my recollection, I have never used if-not (the old unless), and I like the way that if works; I can live with that happily.  So, from a personal standpoint, I couldn't care less if if-not stays or goes.  But you give a convincing argument for it to stay.  For instance:

I can't see any other benefit for removing it (from the code base or from the documentation) - how many bytes will it save? I missed any discussion of this proposal before - but I do remember arguing against changes that broke code for no good reason.

And about "I missed any discussion of this proposal before," I too did not see any invitation to discuss this.  AFAIK, people were not generally aware of if-not being deprecated -- I did not know until jopython mentioned it by opening this thread; so I think Lutz did not invite us to a discussion about it (or I missed it).



Hence, you have convinced me that if-not should stay, as if I had a choice in the matter.  :)



If if-not is kept, I recommend to Lutz then to make it clear in the manual, so as to minimize confusion about the semantics, that if-not is not "cond-ish" and only takes at most three arguments, unlike if which is "cond-ish" and takes any number of arguments.



For your sake, either Lutz changes his mind about disappearing if-not, or you'll have to write your own if-not macro.  The latter case of course just minimizes -- but doesn't eliminate -- the suckage involved in making sure your existing code doesn't break. :(  And again, I think this is a good enough reason to keep it.



I'm curious to hear now from Lutz about it, and if he has another reason, which we haven't covered, to get rid of it.  Thanks, Pete.  Very good discussion.  --Rick

[cormullion]

Good points, Ricky. And of course the confused user can't unconfuse themselves by looking in the manual, so, if they find some code of mine which uses if-not, they might not be able to work out how to get my code running. (Not that many people bother.. :).) I do think I use if-not rather like a Perl die: if something's not right, abandon ship. Besides, I never use if in that ladder-like way anyway...



I just get a feeling that this sort of discussion is energy going in the wrong direction. Forget this type of infelicity, leave unbroken things unfixed, and write some code, or a blog post, or something beneficial. That's what I'd say if I were in charge.:)



(Typed in haste on an iPad while eating dinner...!)

[rickyboy]

Besides, I never use if in that ladder-like way anyway...

Hehehehe.  Touche to my "I don't use if-not." :)

I just get a feeling that this sort of discussion is energy going in the wrong direction. Forget this type of infelicity, leave unbroken things unfixed, and write some code, or a blog post, or something beneficial. That's what I'd say if I were in charge.:)

I agree with you in general about "leav[ing] unbroken things unfixed."  Well, this discussion may be good for something: to save if-not!  The alternative -- not having a discussion -- only leaves us on a cliffhanger about when (if ever) if-not bites the dust.



O Luuuuutz!  You there? :)

[Lutz]

Cannot remember having seen anybody actually using if-not, except myself. People just seem to prefer (if (not ...). It never worked with multiple true-clauses as the normal if does and if it would, it could be confusing. As the manual says: The function will keep working for an indefinite time.



indefinite as in definition 1. and 2. :

Code Select Expand


Indefinite In*def"i*nite, a. [L. indefinitus. See In- not,
     and Definite.]
     [1913 Webster]
     1. Not definite; not limited, defined, or specified; not
        explicit; not determined or fixed upon; not precise;
        uncertain; vague; confused; obscure; as, an indefinite
        time, plan, etc.
        [1913 Webster]
 
              It were to be wished that . . . men would leave off
              that indefinite way of vouching, "the chymists say
              this," or "the chymists affirm that." --Boyle.
        [1913 Webster]
 
              The time of this last is left indefinite. --Dryden.
        [1913 Webster]
 
     2. Having no determined or certain limits; large and
        unmeasured, though not infinite; unlimited; as, indefinite
        space; the indefinite extension of a straight line.
        [1913 Webster]
 
              Though it is not infinite, it may be indefinite;
              though it is not boundless in itself, it may be so
              to human comprehension.               --Spectator.
        [1913 Webster]
 
     3. Boundless; infinite. [R.]
        [1913 Webster]
 
              Indefinite and omnipresent God,
              Inhabiting eternity.                  --W. Thompson
                                                    (1745).
        [1913 Webster]
 
     4. (Bot.) Too numerous or variable to make a particular
        enumeration important; -- said of the parts of a flower,
        and the like. Also, indeterminate.
        [1913 Webster]
 
     Indefinite article (Gram.), the word a or an, used with
        nouns to denote any one of a common or general class.
 
     Indefinite inflorescence. (Bot.) See Indeterminate
        inflorescence, under Indeterminate.
 
     Indefinite proposition (Logic), a statement whose subject
        is a common term, with nothing to indicate distribution or
        nondistribution; as, Man is mortal.
 
     Indefinite term (Logic), a negative term; as, the not-good.
 
     Syn: Inexplicit; vague; uncertain; unsettled; indeterminate;
          loose; equivocal; inexact; approximate.
          [1913 Webster]


If you have never used it don't start using it. If you happen to work on some code which has it, then change it. The VIM editor highlights it as deprecated.

[rickyboy]

Cannot remember having seen anybody actually using if-not, except myself. People just seem to prefer (if (not ...).

So, I'm curious if you think that this reason alone is sufficient to deprecate if-not.



Also, leaving aside the number of people who like to say (if (not ...) ...), what about the people who prefer to say (if-not ...)?  In other words, deprecating (i.e. planning to get rid of) if-not doesn't affect the (if (not ...) ..)-ers at all, but it does adversely affect the (if-not ...)-ers.  However, continuing to support if-not will not adversely affect anyone.



And, what about the following as a reason?

It never worked with multiple true-clauses as the normal if does and if it would, it could be confusing.

I agree.  However, since if-not isn't cond-ish anyway (and probably wasn't touted as such in its manual entry), there wouldn't be any confusion on that point.



The confusion could only arise if someone somehow incorrectly assumed that if-not is cond-ish.  But this confusion is very likely to be a rare one.  Manual readers are not likely to fall for it.  Manual avoiders, on the other hand, wouldn't be likely to know that if is cond-ish in the first place; so they wouldn't have that as a basis to assume/guess incorrectly that if-not is cond-ish also.  And, such confusion can be avoided or minimized with the manual readers by explicitly saying in the if-not manual entry -- if you should deem if-not be re-established as an official primitive -- that if-not is not cond-ish.



So now I'm curious if there are other reasons that would compel you to deprecate if-not.  Thanks in advance for your response.

[cormullion]

Cannot remember having seen anybody actually using if-not, except myself.

Well, these days you don't have to rely on memory - just search the internet. For example, on Github, two repositories not unknown to the newLISP community - Artful-Code, and Dragonfly - both make use of this function. I use it too. So when the "indefinite" time comes, everyone who has used those repositories will be inconvenienced, for no very good reason (that you've given).

The VIM editor highlights it as deprecated.

Ah, so we all have to use VIM now?

[Lutz]

if-not will not be removed.

[xytroxon]

"To if-not or not to if-not..."



KING CLAUDIUS er. Lutz



    It shall be so:

    Madness in great ones must if-not unwatch'd go.



The Tragedy of Hamlet Cormullion, Prince of newLISP Act 3 Scene 1





-- xytroxon ;o)