World: r3wp

yeah, i had the same feeling that it can be interpreted as the description 
of a non-complete boolean evaluation  (that was the name of the flag 
in turbo pascal ;)

with -> will

the original problem was not AND/OR but NOT

so IF NOT is not the same as UNLESS

(if im correct)

or actually it is but then AND/OR why not

capable of handling the same parameters as NOT?

the basic problem is that NOT isn't symmetric with AND/OR/XOR .  
  currenty, AND/OR/XOR are bitwise ops.  they are not language control 
flow ops.

it raises the question, well what are these ops... and the answer 
is that there are none.   its a strange hole in the language spec 
which has passed under the radar for a really long time.

its very possible that REBOLers think in a different way and using 
ANY/ALL is more natural, hence the unatention this has had.

I don't agree, they're only used bitwise, as this example illustrate:

>> a: 1 b: 2
== 2
>> if (a = 1) and (b = 2) [print "it's true"]
it's true

Geomol: I don't understand, why you say
REBOL does not have conditional AND and OR


Excerpt form the above definition of "conditional operator": "...being 
able to combine conditional expressions into more complex conditional 
expressions..."


The demonstration that AND and OR are not able to combine conditional 
expressions into more complex conditional expressions is easy

(and has been done already)

I just got confused by the wording. :-)

Is it correct to say, that AND and OR can be used as bitwise operators 
and to check on logic! values. And that e.g. IF can do more than 
this and then isn't really compatible with AND and OR?

geomol, logic types are single precision states.  on or off.  any 
operation between logic values are implicitly bitwise.

yep.

you just got the differentiation between conditional and logical 
comparisons.

Ah yes, you can say that about bitwise. Makes sense.

I'm just used to not think in bits when dealing with logics.

I am trying to use a slightly different formulation: IF can check 
not just logical expressions (yielding LOGIC! values), but conditional 
expressions (yielding any values). We do not have operators combining 
conditional expressions into more complex conditional expressions 
(ANY and ALL are dialects, not operators, although they can be used 
successfully).

Sounds good to me.

geomol,  I come from electronics background wrt logic... so I can't 
make the difference  ;-)   I studied logic as digital circuits vs. 
 analog circuits.

Is an analog circuit only partly true or false? :-)

maybe truish while probably falsy :)

Ladislav: very clear and concise description. i would emphasize the 
operator by saying "..don't have any op!s combining.."

to a digital circuit, an analog circuit is like quantum physics, 
it seems impossible, but it works .   ;-)

it's interesting to think about ANY/ALL as dialects...

so... can we say that analog is the future of digital ?   ;-)

I like analog more and more. Buying analog synths, trying to build 
analog circuits making sound.

onetom, I guess, you can see all functions taking a block as an argument 
to be dealing with dialects. The content of the block is just words 
until the function start to interpret it and give meaning to it.

Or maybe more correctly, the content of a block is datatypes (words, 
numbers, etc), and then the function start to make sense of it.

yeah, but in this case the default rebol evaluator is the 1st and 
almost only thing which touches that block, that's why i overlooked 
this

The fact, that ANY and ALL are natives, is maybe just to make them 
faster. It should be possible to create them as functions. One project 
of mine is to figure out, what minimum set of natives is needed for 
a REBOL like language, and the rest can then be implemented as functions.

it would be a nice groundwork for implementing rebol-like languages 
over others

like the lisps in javascript

we are off-topic though

What's the right group for this? Core maybe?

Red?  ;-)

isn't this what Red/system is all about?

It is definitely possible to implement ANY and ALL as functions if 
you use DO/next (either the R3 or R2 version).

You use the OP function to make op! values, and 'op gets unset after 
the mezzanines finish loading because of security/stability (I think 
OP doesn't have a lot of safety checks yet). TO-OP isn't defined. 
You can't currently make an op like Geomol's FROM because you can 
only currently make ops redirect to native! or action! functions 
- you can't make the necessary wrapper function. This is all afaik, 
based on conversations with Carl; I haven't tested this very much 
yet.

to-op is defined, but it doesn't accept function! values.

it would be really nice to have this... we can make a lot of things 
look like natural language with this.

Really? It's not defined at runtime. Maybe it gets unset after the 
mezzanines are done loading too.

fire up R3 and type:

>> help to-op
USAGE:
        TO-OP value

DESCRIPTION:
        Converts to op! value.
        TO-OP is a function value.

ARGUMENTS:
        value

Maybe you're using different builds?

I did that. TO-OP was unset.

ok,  it's probablly been removed then... I'm still using an ancient 
version for the chat.

It is planned to support making ops from other kinds of functions, 
but it hasn't been done yet.