World: r3wp

Port should not be in it, to allow functions to behave as scheme 
actors

It's not a type, it's a collection of types (typeset!). In this case 
a collection of the types that act like objects.

i'm aware of that, don't do a disgression

It's just there so you can use it in function specs for functions 
that act on objects to let them act on other object-like things, 
when they are being sed in object-like ways.

I'm not sure, but i just think there is a difference in the way of 
treating the argument any-object! and object!
In the first case the port is populated like an object.
In the second, the function is usable as an actor for schemes.
It's really different use cases, I hope i'm wrong here.

If you want FOREACH to work on ports in a certain way, you need to 
write a ticket for that. Mentioning it here won't accomplish anything, 
as Carl almost never sees the stuff we write here.

see the arguments of COPY by example

copy don't use any-object! because of that

COPY hasn't been changed to use any-object! - that may yet happen, 
but any-object! is too new for it to have propagated yet.

I doubt it, as COPY doesn't act on error! and task! in an object-like 
way.

if i understand correctly how Carl managed generic behavior for the 
any-object! argument, COPY will never be changed like you think

I doubt it

Because it would remove the use case of COPY as an actor.

Um, no it wouldn't. It would just allow error!, task! and module! 
to be copied too (which would be a bad idea).

we will see, i just hope you're right here

Typesets are just shortcuts for adding all of the types they contain 
to the function spec. They have no inherent meaning.

ok

so actually they

you say Typesets are useless :)

hi


as far as I know it is possible to convert binary to decimal in R3. 
Is there already a reverse conversion?

to binary!

Typesets are really useful - do you want to write all of that out? 
Plus, they are implemented as bitsets, so they are really efficient.

The backported version of typesets in R2-Forward is implemented as 
blocks of datatype! values - not as efficient.

find any-object! type? :value
Uhm cool, i completly forget that point

ok i changed my mind, it's useful

working with parse as well ?

interesting that to-binary works for decimal, but not money.

bah, you can store a fixed point decimal, what the need to store 
money ?

A lot of stuff doesn't work for money! yet - we have a stack of deferred 
tickets for money!, not as many as for vector! though.

vector vector vector, FIRST !!!!

We'll get to them - right now we're working on lower-level stuff.

no rush on money from my perspective. just pointing it out.

something lower than vectors ?
What could it be... neutrinos ?

Lower-level in terms of core functionality. R3 is weird - there are 
some mezzanines that are lower-level than some datatypes :)

What !!! Some mezzanines are lower ?
it's a joke right ? ahah

(i forgot that LOAD was a mezzanine now)

to binary for money: it does not make as much sense as for the decimal! 
datatype, since the datatype is accurate. what would you need it 
for?

For that matter, half of DO is mezzanine, or rather "intrinsic" - 
what we call REBOL code called internally by native code.

Ladislav, I have no idea. What do you need to-binary on decimal for?

file storing in a compact format

We will have rebin for that.

rewhat ?

yes in some decades

ReBin - binary encoding for REBOL values. Carl is working on it now 
- as the new host interfaces require it. We will have it very soon.

to-binary on decimal is actually the only method how to obtain the 
precise representation of a decimal. For money! mold suffices

If Rebin store slot values, it will not be compact, same memory overhead.

To binary! furnish a more compact way to store data, with a speed 
issue indeed

Don't assume that it will store slot values. The reason that Rebin 
is being used in the host interface is to make the internal layout 
of the slot values something you don't see, so that it can change 
for different platforms.

Rebin is supposed to be compact - that is its other purpose (reducing 
line overhead for network protocols).

ok ok, nice draft

Could it mean that we will store complex data structures (nested 
series and object without duplicated values, like MOLD do) ?