World: r3wp

Pekr, that is not correct. Last writing was April 1st, 19 days ago.

Janko - Henrik is not right - Unicode "silence" lasted for 3 months. 
Unicode, Parse - those were controlled disappearances, yes. Not this 
one though.

Henrik - last writing where?

RM Asset private world.

I am still not happy with this:

    not none ; == true


, which means, that NOT handles NONE as a logic value. At the same 
time, it is not a logic value for other logic operators/functions:

    none or none

** Script error: or does not allow none! for its value2 argument


, and am tempted to put it to the CureCode. Am I the only one disliking 
this?

To be more precise: I dislike the incompatibility between logic functions, 
not any specific variant of the behaviour.

I can follow that and agree. But it's probably this way, because 
much code will make more sense? Functions returning none in case 
of no more data or the like. Then you can check against none, and 
if the function return ok, you have not none. Or?

I agree, when I look at AND help it states input types as:

(logic! integer! char! tuple! binary! bitset! typeset! datatype!)


none! should be added there and be considered 0 when scalar bitwise 
ANDind is done.

Hmm, Max, that would not help, in fact, keeping the incompatibility 
anyway.

>> if none [42]
== none

>> if not none [42]
== 42

actually, I assumed false was being used that way... it seems not... 

so I vote to have none! be == to #[false] in how logic ops treat 
none.

Geomol, the return value is because of IF...  'IF returns none when 
the condition isn't successfull

yeah, but imagine a function call in stead of none in my code. A 
function, that returns none when failure (like no more data).

Geomol: yes, there *is* a reason why the NOT function is comfortable 
being argument-compatible with IF. But, then, other logic operators/functions 
should be compatible as well. The functionality like typeset or typeset 
can well be left for the UNION function.

Yeah, I understand now. Makes sense to use NONE with OR etc. Because 
it could be the return of a function, we test with OR.

I can't figure right now, if it will lead to some problems in some 
cases.

OR AND etc, already return errors when you try to compare incompatible 
datatypes.  right now it seems very odd to me that #[none] is not 
comparable to logic values.


none is part of the logic! handling in conditionals and loops... 
IMHO it should be in logic ops and funcs too.

There are many funny things. Also why is there a TRUE? function but 
not a FALSE? function?

FALSE? function is NOT

any [none none]  is the none! aware version of ORing :)

i don't like infix much anyway

onetome... but its not an op   :-)

Yes, FALSE? is NOT, but then why do we have TRUE? There's no need 
for it, right? You can just ask on the operation, you're doing.

Yes, but just recently, a user had to choose between:

    any reduce [expr1 expr2]

or 

    (true? expr1) or (true? expr2)

, which are equivalent for him, but not nice.

if some-func OR other-func [] would be nice to support... though 
I ALWAYS use any/all... its become a habit  :-)

he could not use

    any [expr1 expr2]

, since he wanted EXPR2 evaluated.

Ah, and OR is binary OR, when used on integers, which justify TRUE?. 
:-) Still funny.

I guess, that it is more annoying than funny.

Geomol, TRUE? makes any "truthy" value and acutal #[ true ] value. 
  
which, as Lad just showed, is compatible with logic ops

its the newer name of  FOUND?  ;-)

I also prefer any [ ... ] instead of OR. I almost never us OR. But 
I always use infix operators in math, and I very rarely use ADD, 
SUBTRACT, etc.

Yeah, so TRUE? is kinda ok, but I would expect FALSE? to be there 
too then, to make it complete.

Geomol, in R3 we have: 
>> false? true
** Script error: false? has no value

>> true? true
== true

same here.. for some reason. but i miss the infinite arity of lisp 
for add, max, min

yeah, we should have block versions of the various math ops as standard 
in the language.  
 similar to any/all for conditionals.

something like:
sum [ 1 2 3 4 5 6 ]
min/max-of [ 1 2 3 4 5 6 ]
etc.

42 * [1 2 3 4]

[a b c d]: 42 * [1 2 3 4]

maybe too unreadable. :-)

its the newer name of  FOUND?
 - Max, that is an error. see this:

found? false ; == true
true? false ; == false

TRUE? is the "IF compatibility function"

If you want FALSE? just define:

    false?: :not

yes

Does anyone see any problem if logic ops support none! values? If 
not, go ahead and suggest it Ladislav.

It is not about supporting #[none!], it is more about not supporting 
other operations, that aren't logic-like

you don't want AND/OR to support   bitwise ops?

e.g. typeset or typeset is actually a union for me, and therefore 
should be performed using the UNION function preferably

you don't want AND/OR to support bitwise ops?
 - they are logic-incompatible

(in REBOL)

because 0 can be used to represent TRUE in REBOL, not FALSE

I expect   true == (0 AND 0)   if that is what you mean.

but I think I understand the deeper question you are hinting at.


AND/OR actually are two completely different ops rolled into the 
same wrapper.


on one part they act like a logical comparisons, on the other hand, 
they *also* act as a "bitwise" operators.  

because of this we cannot compare data *with* logical! or none! values.


I would gladly separate both as two sets of ops.   && ||  symbols 
come to mind to use as "bitwise" ops.  

I'd keep AND/OR as logical operations *only* allowing us to compare 
any data as logic comparisons.

AND/OR actually are two completely different ops rolled into the 
same wrapper

 - yes, that is the problem. I would even add, that not just two... 
 Such a setup *might* work, if the ranges were disjoint. But, in REBOL, 
 they are not disjoint, because any value can be used as logic by 
 IF.