Page 1 of 1

Unless

Posted: Thu Jul 17, 2008 4:07 am
by 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.

Posted: Thu Jul 17, 2008 12:13 pm
by Jeff
We could call it ifn't.

Posted: Thu Jul 17, 2008 1:28 pm
by 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.

Posted: Thu Jul 17, 2008 2:10 pm
by 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.

Posted: Thu Jul 17, 2008 5:08 pm
by 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! ;-)

Posted: Thu Jul 17, 2008 7:43 pm
by rickyboy
By the way, between the following two people, who would win in a cage fighting match?

Image OR Image

Kazimir versus Bill Gates.

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

:-)

curmudgeonly...

Posted: Thu Jul 17, 2008 9:56 pm
by cormullion
rickyboy wrote: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...
rickyboy wrote: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.

Re: curmudgeonly...

Posted: Thu Jul 17, 2008 10:10 pm
by rickyboy
cormullion wrote: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! ;-)

Posted: Thu Jul 17, 2008 10:38 pm
by Jeff
if-not sounds good. I still like ifn't.

Posted: Thu Jul 17, 2008 10:48 pm
by 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.

Image

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

Posted: Thu Jul 17, 2008 11:05 pm
by 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.

Posted: Fri Jul 18, 2008 2:22 am
by rickyboy
Kazimir Majorinc wrote: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. ;-)
Kazimir Majorinc wrote: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.)
Kazimir Majorinc wrote: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!! :-)

Posted: Fri Jul 18, 2008 6:43 am
by 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 ;-)

Posted: Fri Jul 18, 2008 11:37 am
by Jeff
How does that work? It gives an even chance of evaluation?

Posted: Fri Jul 18, 2008 12:21 pm
by DrDave
Maybe "perhaps", "sometimes", "maybe", etc. could implement fuzzy logic rather than probablitities or random selection.

Posted: Fri Jul 18, 2008 3:38 pm
by 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.

Posted: Fri Jul 18, 2008 4:11 pm
by DrDave
Ryon wrote: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.

Posted: Fri Jul 18, 2008 4:17 pm
by 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!

Posted: Fri Jul 18, 2008 6:34 pm
by rickyboy
Ryon wrote: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 wrote: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. :-)

Posted: Fri Jul 18, 2008 7:17 pm
by 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.

Posted: Fri Jul 18, 2008 8:31 pm
by Kazimir Majorinc
Jeremy Dunn wrote: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.

Posted: Fri Jul 18, 2008 8:36 pm
by 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.

Posted: Fri Jul 18, 2008 10:07 pm
by Kazimir Majorinc
Jeff wrote: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).