World: r3wp

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.

The current version supports chat just fine.

there are a lot of things I'd setup as an OP.   the FROM example 
from geomol is a really good example of how this makes code sooo 
much more readable.

it also allows to alleviate some parens in expressions if the functions 
are ops instead.

There are some real limits to op! evaluation that makes them unsafe 
for general use for now. For one thing, the type of the first argument 
is not checked at call time relative to the typespec by the evaluator 
- it has to be checked by the function itself internally. This is 
not a problem with most existing ops because they map to actions 
(which have their type compatibility handled by the action dispatcher), 
or in some cases natives that perform their own internal type checking. 
I believe this was a speeed tradeoff. If you allowed full user creation 
of ops even with their current restriction to actions and natives, 
you could bypass the typespecs of natives and corrupt R3's memory. 
Adding in that typespec check to the op! evaluator would slow down 
op! evaluation a little, but would be necessary if you really wanted 
to make user-defined ops possible.

I don't mind since we need to build a stub anyways... its easy to 
add this checking there.

the to-op function could easily just raise an error if the first 
paramater has any type spec.   that' how I'd handle it.

this forces people to make the stub, so it becomes a programming 
error, not a language bug.

That would fail for = and all other functions that allow the any-type! 
value (for unset! and error! support), and make it difficult to understand 
the help of all op functions, which use the typespec of the first 
argument for documentation purposes. Plus, the argument list for 
the op! is taken directly from the function it is derived from - 
it can't and shouldn't be able to be specified separately.

brian we are talking an api issue.  what happens before application 
starts is irrelevant.   on init, let R3 do whatever it wants.


once we start running the script, have an api-minded function which 
just makes sure that any function you send to the core used as an 
op is safe.  I don't care for any limits... just document them and 
I'll live with.   whatever the core has which I can't have... who 
cares.


as far as error reporting goes, that is the reason for the stub. 
  IT will have to either handle the error appropriately or just raise 
an error.   


really, there is no technical reason for this not being done.  its 
just a question of doing it.    limited user ops are still infinitally 
better than none.

The other trick that would need to be accounted for is that the actual 
process of calling functions is different for every function type, 
and afaict the differences are implemented in the evaluator itself 
rather than in some hidden action! of the function's datatype implementation. 
This is why I was glad to figure out that the command! type was sufficient 
to implement what we needed user-defined function types for, because 
it appears that user-defined function types are impossible in R3, 
even potentially. The op! redirector needs to be able to understand 
how to call the function types it supports. R2 ops only understood 
how to call actions (technically, DO did the redirection in R2, not 
the op! code itself). R3 ops can also redirect to natives, which 
is why some functions are native! now that were action! in R2. In 
order to support making ops from user-defined functions, the op! 
redirector code would need to be expanded to support calling those 
function types.

I am not disagreeing with the need for and value of user-defined 
ops, Maxim, just saying what needs to be done to make them possible.