World: r3wp

Actually we're already used to the way INC/DEC would work, just with 
other datatypes. If I wanna sort a series, I e.g. write:

>> blk: [3 5 2]
>> sort blk
== [2 3 5]
>> blk
== [2 3 5]


The block is changed directly by the sort command (function). Without 
this mechanism, I would have to write:

>> blk: sort blk

In this regard, it makes very much sense to be able to write:

>> a: 4
>> inc a
== 5
>> a
== 5

Geomol: your arg: suggestion can't work. (to say it another way: 
it would require very deep changes to rebol)

also, how is that different from using a 'arg and set?

Everything should be made as simple as possible, but not simpler.

I prefer
mult2: func [value:] [value * 2]
over
mult2: func ['value] [set value (get value) * 2]

Also the former might be able to handle
mult2 4

, where the latter gives an error. So using today REBOL, I need to 
handle different datatypes in my function. But if it requre deep 
changes, maybe it should be left out.

require

A function being able to handle numbers and words (holding numbers) 
might be (in today code):

mult2: func ['value] [
	either number? value [
		value * 2
	][
		set value (get value) * 2
	]
]

Just doing:
mult2: func [value:] [value * 2]

is much easier.

The operator
*
works with Type: number pair char money time tuple

We have to check for all those, when defining a mult2 function today. 
(Or catch the error.)

Ah, it might be sufficient to check for word!:

mult2: func ['value] [either word? value [set value (get value) * 
2] [value * 2]]

A function increasing something by 2, which can handle direct values 
and words holding values and series, today have to be something like:

inc2: func ['value] [
	either word? value [
		either series? get value [
			set value skip get value 2
		][
			set value (get value) + 2
		]
	][
		value + 2
	]
]

With set-word arguments, it might be:

inc2: [value:] [
	either series? value [
		skip value 2
	][
		value + 2
	]
]

With INC, it could be:

inc2: [value] [inc inc value]


Maybe an increase function taking two arguments should be native 
too (like INC and DEC):

increase value 2


All these are just ideas to think about, when you guys create REBOL3.

Geomol wrote:

mult2: func ['value] [...]


as I said many times I am wholeheartedly against this nontransparent 
argument passing variant. I consider

mult2: func [value] [...]

always better than that

Geomol: again, what you ask for needs at least a couple new datatypes, 
and breaks the evaluation semantics... you may see it as "simpler" 
but i see it as a huge complication of the language (a useless one, 
too)

Hm, maybe I didn't explain myself well enough. All this come from 
Carl's blog about ++/--. He writes

count: 0
++ count ; add one


I see ++ as a function with calling-by-reference. ++ isn't called 
with the value of count but with it's reference, so ++ can change 
the value of count. My point is, that if ++ is introduced in the 
language, it may be a good idea to implement a method, so programmers 
easily can make their own ++ kind of functions.

That's all.

And the other way around, if it isn't easily possible to introduce 
such a method (calling by reference), then it may not be a good idea 
to introduce ++/--.

the lit-argument passing method is already present in the language 
(although I am against it, to express my preferences, since ++ 'count 
looks good enough to me being referentially transparent - try to 
write ++ pick [a b] 1 using the nontransparent argument passing method), 
so you are indeed requesting much more than that complicating the 
languge without offering an advantage that would justify it

You can also not write your own 'do. IMO itis ok that  some things 
 are only possible at native level. Its  not  lisp.

inc/dec/shift are essential enough for speed and commodity, these 
could be an exception. (Maybe  evenn '<< and '>> as  operators, and 
allowed  in parser?)

as opposed to that, I guess that these cannot save much time anyway

four interpreter-steps instead of one? in a tight  search-loop?  
 until[pair? ++ blk]

btw i prefer post-increment.

but thats a rebcode-case anyway.

i dont like  the repitition when incrementing, moving. the two 'count. 
But  i have no good syntax :(

Geomol: as ladislav said, that method is already there. rebol does 
not have "by reference", so if you want passing "by reference" you're 
going to change the language a lot.

Yes, I see.

I understand, why Carl is concerned, if he should include ++/-- or 
not. I don't think, we have something similar today working on scalar 
data types. An action like NEGATE doesn't change the variable holding 
the scalar data type:

>> negate 4
== -4
>> a: 4
>> negate a
== -4
>> a
== 4

So I bet it'll be confusing, if ++/-- does change the variable.

What would this be called, then?  (I remember it came up before - 
I mean, what's this kind of variable passing called, if not "by reference" 
?)

>> ++: func ['X][set X (1 + get X)]
>> foo: 5
== 5
>> ++ foo
== 6
>> foo
== 6

another variant demonstrating the advantages of "transparent" argument 
passing:

++: func [x] [set x 1 + get x]
foo: 5
++ 'foo ; == 6
foo ; == 6
++ pick [foo bar] 1 ; == 7
foo ; == 7

Izkata: you cannot call it "by reference", since you are actually 
passing the value you are manipulating - the word, not a reference 
to it

ladislav, that in C is just what a reference is... you pass not the 
value, but the pointer which refers to it... in REBOL that is a word. 
 under the hood, in REBOL everything really is a pointer to a value, 
with an offset within a context, no?

ladislav, that in C is just what a reference is

 - that looks like an error to me - references are in C++ actually. 
 Pointers are passed "by value" in C

in REBOL everything really is a pointer to a value, with an offset 
within a context, no?

 - you can explore how REBOL values look using my hints in this world 
 and at REP

lad: a reference to a number is a common usage term which means get 
the pointer to the memory area where the number is contained... not 
the value at that pointer.  in C series variables have to be pointers, 
but numbers aren't usually pointers.  thus the reference to that 
number is its pointer.

if you pass the reference, and chance the value at that adress and 
change it in place... all "references" to it will change.

so I think you are both talking the same language, but with different 
terminology.... based on your usage of C..  :-)

(or C++)

what you are saying is terminologically misleading. "Pass by value" 
has got a broadly accepted meaning as well as "pass by reference". 
If you pass a pointer in C, then you pass it "by value" according 
to the definition.

hehe, but you are passing the "value by reference"  ;-)

hehe isn't programming fun?  :-D

Isn't the real difference between passing a pointer by value or by 
reference is that when you are explicitly passing a pointer it is 
by value and when you are implicitly passing a pointer then it is 
by reference.

(Well that is my understanding from the difference in Pascal).

that is correct

but what about values which are not defined as pointers like an int.

so what, are you trying to convince me, that in REBOL ints are "passed 
by reference"?

(if you speak about the C/C++ family then it is easy - in C++ you 
can pass int by reference, in C you cannot)

REBOL passes values unless the function requires a "pointer" to them. 
 (not really a pointer, but in use pretty much the same result).

so I guess in your terminology, only series can be "references" in 
rebol right?

Surely one of the distinctions of pass by value and pass by reference 
is that in pass by value you work on a copy of the value not the 
value originally refered to:

>> a: 1                          
== 1
>> b: func [a [integer!]][ a: 2]
>> print b a                     
2
>> a: 1                         
== 1

yes.

series can be references
 - actually not

so in your terms, how could a reference be "simulated" in rebol?

or can they?

why not?, but it does not influence the fact, that when you are passing 
a word to a function, then you are "passing it by value", not by 
reference, I can easily show you a proof

(almost the same Peter wrote above)