World: r3wp

you should add it to the above CC ticket as your proposal, I guess

or, if you do not want to, I can do it

Done.

Yeah, that "intrinsic properties" is the softest part of the rule, 
and only really applies to core mezzanines. It is a little more accurate 
to say that for the container access functions that are in core, 
which are *all* legacy functions, the -of is implicit. If the alternative 
is putting a ? on the word, definitely use -of instead for new functions 
if they aren't for use in conditional contexts, or in some other 
way are a question.

I'll edit the comment accordingly.

The choice isn't between FACES? and FACES-OF, it's between FACES-OF 
and FACES.

And it wouldn't be INDEX-OF-MAXIMUM?: First of all, the ? is inappropriate, 
secondly, it returns the series, not the index. FIND-MAX isn't less 
descriptive because it references the behavior of MAX (which we have 
already learned means maximum) and FIND (which we know returns the 
argument series at the position of the thing found). We don't only 
get our conceptual context from English, we also get it from the 
rest of REBOL.

ChristianE, AT-MAXIMUM and AT-MINIMUM are much better, I'll relay 
that suggestion.

Guys, anyone knows if this was discussed as 'intended behaviour' 
by Carl or looks like inconsistency/bug to you?

>> a: make object! [b: []]
== make object! [
    b: []
]

>> c: make a []
== make object! [
    b: []
]

>> d: make a make object! []
== make object! [
    b: []
]

>> same? a/b c/b
== false

>> same? a/b d/b
== true

The choice isn't between FACES? and FACES-OF, it's between FACES-OF 
and FACES.

 - actually, not. The FACES? word is the one used now, which is created 
 in accordance with the current function naming wording, since we 
 defined a function collecting the faces contained in a panel.

Cyphre, Something never tried before can't be categorized as a bug.
It's a feature :-)

well, in R2 'copies' in both cases..so its either intended change 
in R3 or bug

>> d: make a make object! []
same behavior than 
>> d: append make object! [] a

But I agree, it's quite unexpected.

my mistake, same as
>> d: copy a

I vote for inconsistent.
>> make object! object! 
Should that be allowed, to begin with ?

It was allowed in R2 so why not?

Never saw that before. I don't understand the expected behavior to 
begin with.

http://www.rebol.com/docs/changes-2-5.html#section-85

Hum ok, it's cleared stated then. It's a feature

*clearly

R2 session:
>> a: make object! [b: []]
>> c: make a []
>> d: make a make object! []
>> same? a/b c/b
== false
>> same? a/b d/b
== false


So if this was changed in R3 I'm asking if it was intended or not. 
I don't care much what is the 'right' way but asking mainly because 
if the change was intended it should be well noted and documented 
otherwise it can make headache to people.

OH, I see your point now.

I think it's a bug now, It's doing the reverse of the R2 behavior.
>> d: make a make object! []
R3 reverse the parameters at some point and performs 
>> d: make object! [] a

inconsistent anyway

the difference I was pointing out is:


make <object> <block> ;copies the block values inside the prototype 
object

while


make <object> <object> ;doesn't copy the block values in prototype 
object

that is in R3...in R2 it was consistent

yeah it's what I understood

In R3 
>> d: make obejct1 object2
should behave like
>> d: append object1 body-of object2

But yeah, the first form is more concise and faster.

Do you know this document?

http://www.rebol.net/w/index.php?title=Copy_Semantics&redirect=no

There was a big discussion before it, so I would guess it's intended, 
although I'm not sure

Maxim should know the details, because he pushed for changes in object 
copying

I think the point was to have programmer control over the copying 
of an object that is being cloned

yes copy control was implemented because of real world issues trying 
to use early R3 alphas and also because the lack of control in R2 
makes many big data sets very hard to manage in R2.

Ladislav, FACES? was created in accordance with the current documentation 
of the function naming standards, not the current function naming 
standards. The documentation needs fixing.

So, could you tell me what your preferences are?

(regarding the wording)

If it's a function that takes a face or gob as a parameter and returns 
the faces inside of it, I prefer FACES-OF. If it is a member function 
(assigned to a field of a face and bound to it), FACES. Those look 
best to those familiar with English. We're trying to cut down on 
*? for functions that aren't questions or part of the help system.

I thought, you did not intend to change the wording of of 


http://www.rebol.com/r3/docs/concepts/scripts-style.html#section-11

, did you?

Aha, that "if it is a member function" was what you meant. It is 
not, currently.

If necessary, yes. The noun-OF convention should be added, and some 
sensible *? conventions should be mentioned too. In particular, the 
"is it a question?" criteria is a good thing to mention.

I don't have the time this week to do so, and am waiting on some 
more community understanding before I jump in. The "intrinsic property" 
thing likely won't survuve the cut, being replaced by the "implicit 
-of" thing.

But, the 

    Face/faces


was used before the change, and it was not a function, but a block 
"storing" the faces

Then FACES-OF would be the best name for the function, letting 'faces 
be used for variables, and maybe letting FACES? mean "does it have 
faces?".

It definitely wasn't based on any C convention, definitely on English 
:)

Where should be stored equivalent to R2's system/user/name and system/user/email 
?

Also do we have any standart way how to specify that a script requires 
R3 in script's header?

There's no mail functionality yet

Graham's SMTP protocol doesn't seem to have a place for them, either

I'm not looking for mail functionality, but where will be stored 
the user info.

Another question... if I want function which converts integer to 
one byte, is there better way than:
	copy back tail to binary! 60