World: r3wp

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.

Of course in Red, the method for doing them would be completely different 
:)

It would be theoretically possible to make unary postfix ops in REBOL, 
as long as you used a different datatype or some flag in the op! 
value which could be set at op! creation time - the evaluation model 
of REBOL could allow such a thing. Ternary ops would be trickier: 
You would have to have the second word be a get-word parameter of 
the word! type be the underlying function's third parameter, and 
the third parameter of the op would be the fourth parameter of the 
function. All ternary ops starting with the same word would need 
to be implemented by the same function, which would behave accordingly 
based on which word is passed as its third parameter. The ternary 
op value itself would be assigned to the first word, because REBOL 
doesn't have multi-word bindings.

type be the -> type as the

The implementation of ternary ops would probably not have the slowdown 
that the optional ELSE had for IF in R1, since the arity would still 
be fixed.

A similar method could be used to implement unary postfix and ternary 
ops in Red, though the tricks would be in the compiler instead of 
the evaluator.

Strangely enough, if ops were implemented using the R2 method - DO 
swaps the op keyword for its prefix equivalent, instead if the op 
itself redirecting - then unary postfix and ternary ops would be 
possible right now with the current op! type, no new internal flags 
needed. Prefix functions can have infix keywords already, as long 
as they are not optional - the arity of the function needs to stay 
the same, but there's nothing illegal about infix keyword parameters 
in REBOL.

The only trick with ternary ops or infix keywords in REBOL would 
be that any syntax error that you might want to throw if the second 
word doesn't match the list of accepted keywords, you can't trigger 
that error until after the other parameters have finished evaluating. 
It would be preferable to trigger that error ahead of time, but impossible. 
Oh well.

I managed to bring up my wiki again .. and the SOAP stuff is here 
http://www.compkarori.co.nz:8000/Rebol3/AWS but Amazon is going to 
require https so not sure how that is going to work.

I find myself often needing to sort in a file system on date, when 
the file name contains a date, but I have to manually build a new 
date string, where the month is a zero padded number.


Does it not make sense to have a file-system and sort friendly date 
stamp?

dir /od

so we just need 'call

what does that do?