World: r3wp

Sorry, that was awkwardly phrased. If there was a better way of explaining 
that to newbies that didn't require a full article, it would be in 
the docs.

it's just that your explanation dig out more interesting questions. 
But i'm too tired tonight

Basically, the functions that you see in REBOL aren't necessarily 
the functions that are actually called. For each function type DO 
calls them a little differently, and this eventually gets to the 
actual function code. For most functions the argument spec type checking 
is done by DO, not the function itself. For natives (or mezzanines 
with explicit type checking) there can sometimes be some extra checking. 
Apparently all actions have to do some extra internal type checking 
because the argument compatibility rules are too weird to be expressable 
using the REBOL function spec syntax, so that syntax doesn't tell 
the whole story sometimes - the source of many dismissed documentation 
bug tickets, I'm afraid.

I should start to register some quotes of you an Carl, to be able 
to think about, afterward.

like that one i saw some day ago, about EMPTY? calling TAIL? IIRC

EMPTY? doesn't call TAIL?, they are the same function assigned to 
two different words :)

Are you sure ?

yep tested

But I remember an odd bu

... bug when trying to use EMPTY? as an actor in a scheme

It throwed an error about TAIL?

Port actions are mostly redirected to the scheme, but not (directly) 
the ones that implement the port model itself, afaict.

As for EMPTY? and TAIL?, a function has no way of knowing what it 
is called. That error message generated from within the TAIL? port! 
action guessed wrong.

Oh, it gets trickier (in theory - I've had to do a lot of scientific 
method on the internals, not decompiling). I think that DO does some 
of the function call work, and the function type itself does the 
rest through an internal action. DO handles the evaluation rules 
and builds the stack frame, then passes along that stack frame to 
the function dispatch action of the function type for it to redirect 
to the real code in a type-specific way.


Now it definitely works that way, the only question is whether the 
type-specific dispatch code is built into DO itself, accessed through 
the action dispatch mechanism, or action code called directly without 
going through the action dispatch mechanism. Only Carl or a decompiler 
could say for sure. But really, it doesn't matter because the behavior 
is the same in any case.

Working with schemes, i saw another one thing really disturbing.
Seems that LAST and FIRST use PICK.

But LAST and FIRST are natives and PICK is an action. I always thought 
that ACTIONS may use NATIVES but not the reverse.

Nope, at least not in R3. Natives can call actions, and even call 
function! functions too.

And apparently the type-checking of the left argument of an op! is 
done differently that the type checking of other arguments. Since 
this type checking is apparently done by DO, the type spec of the 
op! or action! function specs is apparently there for documentation, 
not actually used. Instead, DO checks whether the corresponding action 
is supported by the type and goes by that, rather than duplicating 
effort.

Mezzanine functions called by native functions are generally called 
"intrinsics", and there are several of them. DO, MAKE module! or 
port!, and the startup code call intrinsics.

This is how LOAD can be a mezzanine, btw, and still be called by 
DO. And it's how the module system can be mostly mezzanine too.

yep, i begin to know them really well.
Btw, i think make-port should be corrected in some ways

when i construct ports with a spec block, i would rather prefer to 
use dialect (using delect) instead of passing a prototype of the 
spec object

Yeah, I've cleaned up begin and make-module a bit, and rewritten 
DO completely many times, but make-port is still on my list.

i.e.
open [ 10.45.12.12    2450]
instead of
open [scheme: 'tcp host: 10.45.12.12 port-id: 2450]

It actually does use a dialect already, that just resembles an object 
spec.

not really a dialect, just a bunch of case/if

using  DELECT would allow a more versatile syntax.

MAKE-SCHEME is earlier on my list though.

I'm not doing anything with DELECT until after it's settled. A complete 
rewrite of DELECT with a new dialect model is scheduled for the next 
host kit release.

i take the risk (using delect), I onl

I only hope the rewrite will just add more capabilities

Maybe we should also have a set! datatype ( need to use a different 
name though ) to indicate a unique unordered collection

And that dialect you mention is ambiguous - you need the keywords.

it was an just example. We can have default behaviour for several 
data-type, and use keywords only to  allow  disambiguation

a tuple is an IP by default,
an integer is a port-id by default.
etc...

And a scheme is nothing by default.

userid and password and domains are ...the same

a word is scheme by default :)
open [http 12.34.45.56 80]

Graham, we have set functions that work with the block! type, we 
don't need a set! type. There is a budget for built-in types - we 
can only have a limited number of them. There has to be a major need 
that can't be handled easily enough otherwise for a new built-in 
datatype to be added. A set! type might merit a user-defined datatype, 
or a spoofed datatype like the ones I added to 2.7.7+, but it's not 
an extreme enough difference from the behavior of block! with set 
functions to merit a full datatype.

Seems a bit of overhead if you're trying to maintain a set if you 
have to check each time you add something if it already exists or 
not.

Which is why I want an INCLUDE function, the opposite of EXCLUDE.

bitsets are exactly what you need graham (only working with sets 
of integers or chars, though)

Maps work well for that too, using #[true] as the value or #[none] 
for not there. Works great, works with FOREACH.

but heavy :)

For other types than integers or chars, it's really not that heavy. 
The space to store one extra value slot each is nothing incomparison 
to the overhead of bitsets for sparse data with poor locality.

Remember, bitsets include the zeros, maps don't necessarily include 
the nones.

true, but bitsets have  lightning speed in comparison.

there is nothing faster

Only for integers and chars. And can be hundreds of megabytes in 
RAM for some datasets.

It's best to pick one based on your data.

sure