World: r3wp

Ladislav, in the sentence: "An argument that is declared as a lit-word" 
can only apply to 
 - 'argument [any-type!]

But it's ok if you say the contrary, I'm not good enough with enligh 
anyway, so I will not argue against that.

Ladislav, in the sentence: "An argument that is declared as a lit-word" 
can only apply to 
 - 'argument [any-type!]

But it's ok if you say the contrary, I'm not good enough with enligh 
anyway, so I will not argue against that.

Dou you speak Frenglish ? :-)

Not really :(

'Ladislav, in the sentence: "An argument that is declared as a lit-word" 
can only apply to 

 - 'argument [any-type!]' - interesting, why do you think so, taking 
 into account, that the meaning of "an argument that is declared as 
 a lit-word" is pretty much standard in many contexts (programming 
 languages), not just in REBOL

Not really - they say that about variables, but for arguments that 
is considered an ambiguous term, depending on which proglang community 
you're talking about of course.

How about all programming languages descending from ALGOL including 
C?

(for me it does count as "many contexts")

In the English papers written about such languages, the phrasing 
is inconsistent (it is English, so that's to be expected), and there 
are cultural patterns in the communities associated with different 
programming languages, colleges, etc. There is no really consistent 
phrasing for this distinction.

Which distinction you mean?

Thanks Ladislav,  I know my job very well but I continue to think 
that you're only arguing about: 
- This idea can only be expressed my way with my words.  

You don't recognise the simple fact that same words have different 
meaning inside different contexts.
Vernacular languages are polysemous, it's a fact.

Good point Brian

Which distinction you mean?

 - Between a calling convention and a datatype, if the terms overlap. 
 Between the type of a variable, the type of a value, and the set 
 of types accepted by a function parameter, in languages where these 
 concepts are distinct. There's lots of subtle distinctions that need 
 to be made, and for many languages some of these distinctions are 
 different, tied to the particular semantics of the language. REBOL 
 has it worse than most because it's weird when compared to most mainstream 
 languages.

This idea can only be expressed my way with my words.  

 - an error, again. This is not about "my words", this is about the 
 official documentation. You are free to not read it, and argue it 
 does not even exist, but that is not an argument for me

The official documenbation  suffer the same bias. You're reacting 
like a monk in front off the holy bibble.

suffers the same bias
 - do not understand what "bias" you mean

It's nice to have an official way to express a concept, but that 
doesn't help much if it isn't the common way that the community uses 
to express that concept. It doesn't help to refer to the manual if 
that manual has been rewritten since the last time the person you've 
been talking to needed to read it. Accept that there are community 
standard terms, and hopt that the better terms in the manual win 
out eventually, or at least before the manual is rewritten again 
with even better terms.

To add more confusion to the mix, lit-arg(ument) and get-arg(ument) 
worked fine as terms in the past :)

hopt -> hope

the bias of having english words which can express several different 
concept

Andreas, I like those :)

Steeve, the bias of using an ambiguous language like English to discuss 
a precise topic :(

+1

Andreas, yes, those terms existed for quite some time....

Those are my preferred terms as well.

what is the fastest way to deep copy a large object?

Try:
>> new: make object! third <object>

it does not work for nested objects.

Then, you probably have to write an recursive function that will 
copy all nested objects. Have you looked for such function on rebol.org 
and in power-mezz package?

I need special functionality, so I will write my own.

Turns out it's far too slow.

object creation/duplication in Rebol is very slow, the binding just 
kills it.  can you re-build your system with block?

(or parts of it ?)

I'm going to copy the parts I need instead.

>> select [1 2 2 3] 2
== 2
>> select/skip [1 2 2 3] 2 2
== [3]

Why the second returns a block?

iirc this is known behavior/issue in R2...has been unified in R3

Oldes, try it with a skip of 3 or 4 to see why a block is returned. 
Not very handy in the 2 case though... but I guess there was a desire 
to avoid special cases.

/skip return records
i.e.  
>> select/skip [1 2 3 4 5 6] 4 3
== [5 6]

I'm just missing MAP! in R2:

>> m: make map! [1 2 2 3]
== make map! [
    1 2
    2 3
]

>> select m 2
== 3

Fortunately the /skip in SELECT/skip is ignored for map! in R3, so 
you can just use it in both.

Darn the R2 version does a copy/part. Silly differences.

in R2:
>> make map! []
== make hash! []
>> m: make map! [1 2 2 3]
== make hash! [1 2 2 3]
>> select m 2
== 2

which is not what I woul expect

Seems like map! is just redirected to hash! . Can be seen with
	? datatype!
, and that's probably confusing, as they behave differently.

Can also be seen with
	? "map!"

>> source to-map
to-map: func [value][to hash! :value]

Is there an official documentation of
	make struct! ...
?

Is there documentation of constructs like #[none] ?

http://www.rebol.com/docs/sdkug.html

see "External Library Interface"

There it was, thanks!

I don't see doc about C datatypes in struct! spec block. I guess, 
it's the same rules as in routine spec block?