Unless

[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).