World: r3wp

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)

I think I just see the nuance in our statements... you're talking 
about the word supplied to the function I'm really talking about 
its value.  so yess I agree.

except my example was wrong

I'm with Ladislav on the C front, but it can be said that words are 
associated with their values, so they are pointers to them.

yes, that is OK

you never get the actual word submitted to the function, even in 
the lit-word arg passing, you still get a new word within the function. 
 but its pointing to the same value.

ah.. what a little scribble on a piece of paper would do in these 
instances  ;-)

...that is the "pass by value" business

one exception regarding "pointer business" in REBOL: only words bound 
to a context can "point" to values

yes... the act of binding creates the association (to use Anton's 
term :-)

question: do you think that the binding "act" changes the word in 
question?

well, my research (of making a single block with 3 word of the same 
spelling with 3 different contexts and values) lets me to think that 
it only really sets the word with 2 values.  1) its context 2) its 
offset within that context (thus the data it should manipulate). 
 otherwise, it stays in place...

I did not do a lot of tests with aliases, cause I never found them 
of "obvious" use  (man I like that word, since terry used it so often 
 ;-)

I guess everybody would agree with you regarding the "obious" use

obvious
, sorry

hehe

Okay, what then if INC/DEC are introduced in the language in a way, 
so they work more like we're used to with e.g. NEGATE, but at the 
same time allow, that variables can be changed? We have to use call-by-word 
(the REBOL way of call-by-reference) to have the variables changed. 
Like this:

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


So INC has to check, if it's called with a word, and then get it's 
value before adding one, and in the end do a set-word. We could have 
the same with NEGATE and other functions (actions) of the same kind:

>> negate a
== -5
>> a
== 5
>> negate 'a
== -5
>> a
== -5

Does that make sense? And is it REBOLish?

but this tricky word usage usually breaks in situations like path 
notation

a word, and a literal word are two things.  using a literal to access 
the associated word in the current context, means you can hardly 
break free of that word's spelling.

and it gets hard to support when going through loads and parse, and 
all that.

referentially nontransparent argument passing always "breaks", since 
it disallows you to use a result of an expression and therefore I 
don't like it

My suggestion is close to Ladislav's ++ function above and is something 
like:

>> inc: func [x] [either word? x [set x 1 + get x] [x + 1]]


But as Maxim point out, there are ploblems with paths. But what is 
the path representing? A block or an object or what? If it's in an 
object, it'll work this way:

>> o: make object! [a: 0]
>> inc in o 'a

It's harder to deal with values inside blocks.

that is the real one for me... using literals as words is not predictable, 
or limited, or complicated.

And why this cannot be correct:    inc o/'a ?

maybe it's just too cryptic

in this special case: does it make sense toincrementsomething except 
a word or path? Everything else is a constant.

The thing is, if the argument to INC is written as a word (representing 
a value) or as a lit-word.
>> inc a
or
>> inc 'a

With my INC function, the first example wont change a, while the 
second example will. Or did you mean something else, Volker?

Did not notice the lit-word, may make sense. Personally I would restrict 
it to lit-words only and use "+ 1" otherwise.

Would confuse me, sometimes side-effect, sometimes not.

Yes, side-effects can be confusing (often are). But INC is maybe 
a special case. Normally when we call a function with a word holding 
an integer, we don't expect the value of the word (our variable) 
to change.

>> a: 4
>> negate a

doesn't change a. So should "inc a" change a?

No, IMHO itshould be a  bug.

i would only allow   inc 'a  .

hmm,,    
   repeat i dec length? string
   repeat i  (length? string) - 1
i drop that. makes sense.

I think, we agree. :-) Both "inc a" and "inc 'a" should be allowed, 
and the latter should change a. It would be nice, if NEGATE work 
the same way. And we can probably find some other natives, we would 
like to work this way. Then we just have to convince Carl. ;-)

A question about operators:
wouldit make sense  toevaluate them  from right to left? so that
   a = 5 * 3
would be
  (a = (5* 3))

i think that is more native. and more in line with functions, which 
evaluatethe right  part first.

Do i overlook something? Except that it  breaks all current  code.

Initially I'll suggest these of type action! to accept 'arguments:
abs, back, complement, head, negate, next, tail
Maybe also: first, second, ...

And what if SORT was changed, so it both took arguments as today, 
but also lit-words, and only change the series, if it got a lit-word? 
Same with TRIM.

>> a: 4
>> a = 5 * 3
** Script Error: Expected one of: logic! - not: integer!

So your suggestion is maybe quite ok!