Unless

[Kazimir Majorinc]

In Newlisp unless is "pessimistic if" as Cormullion stated it in his free book.

(unless (= 0 1)(print "55")(print "66"))

is same thing as

(if (not (= 0 1))(print "55")(print "66"))

However, in CL and Scheme, unless is "pessimistic when."

(when (not (= 0 1))(print "55")(print "66"))

So, original expression prints 5566 in CL and Scheme and 55 in Newlisp.

It might be good to synchronize that with CL and Scheme, because difference can be source of the bugs and reason for complains, and because CL and Scheme semantics seems to be more beneficial - it spares one (begin) - while Newlisp version only change the order of the alternative s-expression.

Maybe some other keyword could be used for "unless" in the current meaning, if someone think it is useful.

[Jeff]

We could call it ifn't.

[Lutz]

Or 'pif' for pessimistic if :)

This kind of change would have to be announced in the next release before implementing it in the release after that, because it could break code.

[Jeff]

I don't have any real problem with if/unless being semantically paired rather than when/unless. In fact, I think I prefer it, as there are fewer instances where I would use unless if it did not have a negative form.

[rickyboy]

Well, as long as you're voting, I agree with Kazimir and vote for the semantic pairing of when/unless. And if can be paired with something else, like pif (what Lutz suggested). Other candidates can be nif, ifn (although American southerns think this is "if", as in "Be prepared fer if'n them kin folk stop by fer vittles."), nisi (for the Latin inclined), ifnot, et c.

Heck, start a contest! ;-)

[rickyboy]

By the way, between the following two people, who would win in a cage fighting match?

OR

Kazimir versus Bill Gates.

My money is on Kazimir. (Bill is not allowed to hire someone to do the fighting for him.)

:-)

[cormullion]

Well, as long as you're voting, I agree with Kazimir and vote for the semantic pairing of when/unless.

if symmetry is that important, I'll go along with it too. But it will break some of my code, and I'm not keen on breaking code just to be compatible with some other languages (neither of which I use or am interested in) or for the sake of symmetry (which is wonderful, in moderation).

If you made a list of all the things that Common Lisp and Scheme had that newLISP should have (or vice versa) I can't believe that this is the one area that should be addressed before all the others...

And if can be paired with something else, like pif (what Lutz suggested). Other candidates can be nif, ifn (although American southerns think this is "if", as in "Be prepared fer if'n them kin folk stop by fer vittles."), nisi (for the Latin inclined),

Aargh! Please no neologisms or contrivances... That doesn't seem to follow the newLISP way... About the only one I'd vote for is if-not. And I don't like that very much. But at least it's consistent.

[rickyboy]

Aargh! Please no neologisms or contrivances... That doesn't seem to follow the newLISP way... About the only one I'd vote for is if-not. And I don't like that very much. But at least it's consistent.

Ahh! What happened to your humour today? You're breaking my heart! ;-)

[Jeff]

if-not sounds good. I still like ifn't.

[Kazimir Majorinc]

That's me debugging.

Strange enough, it is not B. Gates on the picture you posted. But if I click on the right button of the mouse and save the picture on the disk, then Bill is on the picture. Try it, its fun.



Hm ... maybe I'm stronger, but my wife claims Bill is more attractive than Clooney guy. Women are incomprehensible!

[Kazimir Majorinc]

From the language design perspective I think it is important to continue improving, even if improvement is small and breaking code is extensive.

Otherwise language starts dying.

[rickyboy]

That's me debugging.

Hahaha!

I was going to airbush-out your index finger, so it would look like you were shaking a fist, ready to fight. ;-)

Strange enough, it is not B. Gates on the picture you posted. But if I click on the right button of the mouse and save the picture on the disk, then Bill is on the picture. Try it, its fun.

Yeah, that was weird. I have already changed the IMG url. Hopefully, this one will consistently display Bill Gates face. (Don't know if that's good or bad.)

Hm ... maybe I'm stronger, but my wife claims Bill is more attractive than Clooney guy. Women are incomprehensible!

Hahahaha! Yes, I too have given up on trying to guess what women will like. They are inscrutable!! :-)

[newdep]

In anycase... its time to have a "perhpas" or a "maybe" or a "couldbe" inside newlisp...
Just to make code more exiting from time to time when executing it ;-)

[Jeff]

How does that work? It gives an even chance of evaluation?

[DrDave]

Maybe "perhaps", "sometimes", "maybe", etc. could implement fuzzy logic rather than probablitities or random selection.

[Ryon]

Maybe we could implement a small subset of female logic in newLISP.

Instead of true/false, we could have "fine", as in "that's just fine", which is always more negative than a mere false. Conditionals could be based on "honey, do I look x" and feature a rich set of return values.

[DrDave]

Maybe we could implement a small subset of female logic in newLISP.

Instead of true/false, we could have "fine", as in "that's just fine", which is always more negative than a mere false. Conditionals could be based on "honey, do I look x" and feature a rich set of return values.

Plus, every statement parsed by the interpreter will produce the wrong meaning 99.9% of the time. The remaining 0.1% is interpreted exactly as intended.

And then when the results of the interpreter are actually invoked, there is another 99.9% of the time that the result is wrong. This is because the requirements can change before invoking, during running, and after the result is returned. Examination of the source code reveals that it has mysteriously changed, but no amount of tracking routines are able to prove that a change in source code actually occurred.

[cormullion]

Ricky! I appreciate your humour and take your posts seriously...! Doing both simultaneously is sometimes tricky. :)

To be serious for one more paragraph: I like the newLISP language and I think its current rate of change is evidence of its vitality. But I think that any changes to the core language that would break production code should be made only if there are significant benefits. Changes intended just to make the language tidier or to mollify some unspecified number of Common Lisp or Scheme users who would otherwise be unwilling to use the language (and who would be unable to code up their own equivalents using newLISP's 'so-called' macros) aren't really worth making. But I suppose it depends on whether you use newLISP for production code or just like playing with it!

[rickyboy]

Maybe we could implement a small subset of female logic in newLISP.

Instead of true/false, we could have "fine", as in "that's just fine", which is always more negative than a mere false. Conditionals could be based on "honey, do I look x" and feature a rich set of return values.

Plus, every statement parsed by the interpreter will produce the wrong meaning 99.9% of the time. The remaining 0.1% is interpreted exactly as intended.

And then when the results of the interpreter are actually invoked, there is another 99.9% of the time that the result is wrong. This is because the requirements can change before invoking, during running, and after the result is returned. Examination of the source code reveals that it has mysteriously changed, but no amount of tracking routines are able to prove that a change in source code actually occurred.

Hahaha! You guys had me laughing out loud with these. The guys next door to me in the office wondered what I was laughing about. I told them, after I first cleared the coffee out of my nasal passages, of course. :-)

[Jeremy Dunn]

My vote goes for nif. In most languages the negations of or and and are nor and nand, the n is added on the front.

[Kazimir Majorinc]

My vote goes for nif. In most languages the negations of or and and are nor and nand, the n is added on the front.

Fine. (fine nif).

It looks good reason to me. When you said it, nand and nor also couldn't harm. Not they are terribly missing, but they look like low hanging fruits.

[Jeff]

If we are looking to jive with common lisp on this, then we should not use nif. In CL, destructive versions of functions take the same name but prepended with n.

[Kazimir Majorinc]

If we are looking to jive with common lisp on this, then we should not use nif. In CL, destructive versions of functions take the same name but prepended with n.

I think it is not the best choice on their side, so that particular convention shouldn't be preserved. Maybe something like d as suffix for destructive, or even better, c as suffix for non-destructive could be better. As long as there is no "same name for different function," incompatibility with CL and Scheme is minor problem.

Any case, consistency is good thing, so this is also topic worth thinking about, since Newlisp has no defined naming policy about destruction, (for example, "reverse" is destructive, but "append" is not I think).