World: r3wp

gabriele, what if the function is local, but must be used remotely 
(security is unimportant right now)

That is a good question, Henrik.

what is wrong with an extra assignment?
f:  func [a b /c] [either c [a + b][a * b]]]    f/c 1 2

do (f: func [a b /c] [either c [a + b][a * b]] 'f/c) 2 3

or a wrapper, an 'f-without-c and 'f-with-c.

volker, can't check right now if that works, but does it pack the 
entire function inside the block?

inside the parens

and then returns a path with a refinement. 'do gets the path, done.

You can put a 'use around it to avoid the temp

But not really sure what you want to do. somehow sending a function 
i guess.

well... if it's to be automatically called etc., i'd suggest avoiding 
refinements as much as possible. just use a logic arg.

if you really have to use refinements, you have to compose a path, 
no other way around in r2. (you see, that's why we've been asking 
for a low level apply native for so much time)

I see, thanks

After dealing with strings for so many years with various languages, 
I would say that TRIM should be default with any reading/writing 
functions, and when you don't want something trimmed then use a function.

a: "  my untrimmed string   "
write no-trim a

That doesn't make any sense to me as I hardly ever use trim.

In the case where TRIM is embedded into some functionality, disabling 
it becomes an exercise of varying difficulty.

eg. VID's TEXT style trims text automatically, unless you specify 
AS-IS. Discovering where this happens takes a little while.

I second Anton's statement... adding TRIM is EXTREMELY damaging to 
data.  100% of work I have done in the last year implementing transactional 
ticketing web services 100% implemented in REBOL would have been 
simply nightmarish if such data destruction would have occured.

just handling the ports is finicky enough!

as an example, I NEVER use parse without the /all refinement... its 
just so damaging... lengths become all screwed up and trying to separate 
clearly your tokens in the input strings becomes much harder.

Everyone has different needs. I can see the argument for auto-trimming, 
but neither behavior is clearly "better" IMO. In this case, I would 
vote not to auto-trim.

some things cannot be "undone" and such behavior unless it is switcheable 
is dangerous... I've had many problems with memory useage since Carl 
switch the object model so that it copies all series at each new 
instance... the old way was simple to copy... but now, its almost 
impossible to share data amongst peer instances. 


I know why he did it... but I think more explicit documentation where 
the feature was causing some unexpected effects for newbies would 
have been a better solution. and we still have many of the string 
sharing side effects in View anyways... so it didn't explicitely 
fix the main issue in the first place!

Agreed. Things that can' be undone are problematic.

so its a bit like the pre-reduce on apply debate... it can't be undone 
(unless a switch exists, then its ok)  in this case, that is what 
/only usually stands for.

I would call some person's submitted password with inadvertant whitespace 
as 'destructive' .. besides, there would be no 'data destruction' 
if you used no-trim, would there? As Gregg put it, everyone has different 
needs.  If you measured the trimming of strings vs not, I would imagine 
more are trimmed.

terry, it's not possible to implement a no-trim function.

what is the difference between copy and copy/deep?  I cannot seem 
to find any simple examples...

icarii, copy/deep copies series inside blocks, where copy only copies 
the blocks and series inside are referenced, like in the original 
block.

example?

a: [a b c [d e f]] - in this is [d e f] referenced?

when copy rather than copy/deep?

>> a: ["string"]
== ["string"]
>> append a/1 "2"
== "string2"
>> a
== ["string2"]
>> b: copy a
== ["string2"]
>> append a/1 "3"
== "string23"
>> b
== ["string23"]
>> c: copy/deep a
== ["string23"]
>> append a/1 "4"
== "string234"
>> c
== ["string23"]
>> a
== ["string234"]
>> b
== ["string234"]

not copying deep is a common mistake, when series inside blocks or 
objects don't behave or suddenly change contents where they shouldn't.

the lack of examples on rebol.com doesnt help either :(

is the above not clear enough? I'm not sure how else to explain it. 
If you want to copy everything inside a block, just go for copy/deep.

it is clear - i was just noting that there is nothing in the rebol 
docs at the moment - nor in wikibooks

I think deep is in fact default behaviour in R3, because plain copy 
introduces many mistakes for beginners.

a: [a b c [d e f]]
b: copy a
append a/4 'g
;b now has g
c: copy a
append a/4 'h
;c does not have h but b does.

tested and working fine here now :)  i generally use copy/deep with 
complex series but never stopped to wonder why..

something like the following would be useful for new people:
;given the following series
a: [a b c [d e f]]
;perform copy
b: copy a
probe b
>> [a b c [d e f]]
;b contains [a b c [{and references a/4}]]
;this can be seen by appending to a/4 and checking b again
append a/4 'g
probe b
>> [a b c [d e f g]]

;now on copy/deep an exact copy with no referencing of internal series 
is made
c: copy/deep a
append a/4 'h
probe c
>> [a b c [d e f g]]
;c does not have h but b does.
probe b
>> [a b c [d e f g h]]
append a 'i
;and neither b nor c will contain 'i as it is in the outer series
probe c
>> [a b c [d e f g]]
probe b
>> [a b c [d e f g h]]

wikibooks entry updated: http://en.wikibooks.org/wiki/REBOL_Programming/Programming_in_REBOL#Copy_vs_Copy.2Fdeep

Should we prepare for a revision of the REBOL wikibook, when R3 is 
out? Either change directly or make a now book copying over, what 
is ok and adding new?

Copy/deep is not the default in R3. Nor would I want it to be - I 
almost never use copy/deep, but use copy quite often, intentionally.

brianH, sorry, I just seemed to remember Carl talking about inverting 
the behaviour so you'd need a refinement to avoid copying deep.

Well, he hasn't done it yet. If he did I'd use that refinement all 
of the time - I almost never use /deep.

Brian - was there already any talk about rebcode on extended R3 testing 
team?

Yeah. It's not there yet, but its primary implementation technique 
has been generalized for wider use. Several of the dialects that 
have been implemented so far operate in the same way that rebcode 
did, including DRAW.

How do you set or reset objects within other prototype objects. i.e.
prot: make object![
	num: none
	names: make object![
		a: copy "A"
		b: copy "B"
	]
]

x: make prot[
	foo: 56
	;how do I set a to be different
	;how do I add a 'c here to set
]

okay.  I got it working.

x: make prot [
	foo: 56
	names: make names [
		a: copy "Different"
		c: copy "Added"
	]
]

Geomol, the book probably needs a good rewrite or rethinking. Only 
a few sections are still usable.

I'm trying to get a list of all the arguments to get-modes. But, 
right now, the online dictionary is broken for that function:
http://www.rebol.com/docs/words/wget-modes.html
Can anyone help?
(Meanwhile, I'll rambo the problem)