World: r3wp

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!

On the other hand:

>> a: 4
>> 3 + 1 = a
== true

It may break too much to change the order of evaluation.

The example inc/dec functions I wrote in the blog comments behave 
the way you are requesting, Geomol, at least the versions with the 
lit-word arguments. They treat inc a and inc 'a the same. Should 
I repost the functions here?

; INC/DEC with lit-word arguments:
increment: func [
    [catch] 'x "Value to increase"
    y [integer!] "Amount to increase by"
    /local t
] [
    throw-on-error [
        if path? :x [
            x: in do copy/part :x back tail :x last :x
        ]
        t: either any [word? :x paren? :x] [do :x] [:x]
        case [
            series? :t (t: skip :t y)
            number? :t (t: t + y)
        ]
        either word? :x [set/any x :t] [:t]
    ]
]
inc: func [[catch] 'x] [increment :x 1]
dec: func [[catch] 'x] [increment :x -1]
decrement: func [
    [catch] 'x "Value to decrease"
    y [integer!] "Amount to decrease by"
] [increment :x negate y]

; INC/DEC with regular arguments, must use lit-word! or lit-path! 
directly to get side effects:
increment: func [
    [catch] x "Value to increase"
    y [integer!] "Amount to increase by"
    /local t
] [
    throw-on-error [
        if path? :x [
            x: in do copy/part :x back tail :x last :x
        ]
        t: either word? :x [do :x] [:x]
        case [
            series? :t (t: skip :t y)
            number? :t (t: t + y)
        ]
        either word? :x [set/any x :t] [:t]
    ]
]
inc: func [[catch] x] [increment :x 1]
dec: func [[catch] x] [increment :x -1]
decrement: func [
    [catch] x "Value to decrease"
    y [integer!] "Amount to decrease by"
] [increment :x negate y]

which version do you like more, Brian? (I prefer the latter as I 
said before)

Order: yes, but  i  usually  write 
  if a = 1
  if a = 2
  if a= 3

and have then to reverse that to aveparens (not with 1 2 3, but more 
complex thngs)

Ladislav, I prefer the latter, but that's because I'm used to REBOL 
evaluation semantics and like metaprogramming. If you are incrementing 
a word returned from a function, other than in the most common case 
of the IN function for path access already covered by the code, you 
have to put the call to the function in a paren for it to evaluate 
properly. The latter functions will at least always behave the way 
you would expect REBOL to behave - no magic evaluation, pass-by-name 
for side effects, etc.


I think the lit-word argument form is a little awkward for anything 
other than interactive use, like HELP and SOURCE.

I still think that these need to be native or they will be useless, 
even if they follow the semantics of the latter set of functions. 
There's no point to these functions unless they are more efficient 
than the code they would be replacing, and that code is just a couple 
evals, a native/action/operator call and an assign. Even native, 
you can't expect the functions to be less than half of the overhead 
of the phrase they'll be replacing.

agreed, the efficiency gain may well be in shorter code too (maintainability/readability/...)

Sorry, I just realized that was a confusing answer (to anyone other 
than Ladislav :). To clarify:


By call-by-name, I meant passing a word or path value to the function, 
rather than passing the value it refers to. If you have 'a formal 
arguments then call-by-name is implicit - if you have regular formal 
arguments then you must explicitly express call-by-name by writing 
the 'a as the actual argument, at the time of the call.


When I was talking about having to put function calls in parens, 
I meant any function calls or expressions that return the values 
that would then be passed to the INC/DEC function in their first 
argument. The first version of the functions, with the 'a argument, 
would need to put any word or path generating expression in parentheses 
for it to work properly. The second version of the functions would 
not require such a hack - you could use normal REBOL evaluation patterns.


One of the normal REBOL evaluation patterns is that call-by-name 
is explicit for all functions, except interactive functions used 
for documentation like HELP and SOURCE. This is why I prefer the 
latter functions above, the ones with normal formal arguments: Their 
behavior is more REBOL-like.

... I see the SECURE function as an exception to this rule, alghough 
some may say it is meant preferably as a console function too

geomol and others...  INC with lit-words is seriously flawed in actual 
use ... a: inc a  ?? what's the point of it...


lit-words are not word values they are labels, they are not usable 
unless the word exists "somewhere else"  its not THE a you are evaluating 
but AN a somewhere... which is why this is as alien to rebol as anywhere 
else.


if all series can change values "in-place" like append... why not 
allow this for scalars (and others) too?  its already an integral 
part of REBOL ... I don't see the "confusion" in   INC a   changing 
THE a... its exactly like  append a, but for another type... hell, 
I've wanted in-place editing for many things which aren't series 
and it would speed up code, just like not having to copy series all 
the time like python. 

ADD-TO a 10


when you do INC 'a  you HAVE to declare 'A somewhere else... which 
is not in rebol's philosphy.  this is completely different thinking 
to rebol... its much closer to C style... where you expect a to exist 
somewhere...    the lit word syntax, just cause a big confusion within 
the normal chain of rebol coding IMHO its not simple, and certainly 
not obvious... most newbies don't even get what a lit-word is.  just 
like SET which is used only (usually) to implement other tricks in 
the language... we shouldn't be using SET in normal code.  INC is 
not a trick word... its something I'd be using in many scripts, unlike 
SET which I seldom need to.  

just giving my view on this topic.  ;-)

I know many of you are very technical and scientific, but this is 
a kind of detail, which is IMHO not in REBOL's mindset and don't 
mind a little bit of extra "precision" or "correctness".  but REBOL 
is not about being correct and strict... its about being simple and 
productive... so even if you are probably correct in your analysis... 
I do think its not a simple detail to understand for the vast majority 
of REBOLers.


The interpreter should addapt to use, not the opposite.  INC a means 
increment a, who cares what this means within the interpreter, words 
already are pointers internally, so its not such a big deal to implement 
anyways AFAICT.  in the end, we will be typing an extra ' all the 
time and really will be adding complexity elsewhere in the code, 
cause we have to "remember what a means, somewhere"


or end up doing a: INC a  which is sort of pointless.  Also, its 
an op, not a function.  just like + - = ... its not supposed to follow 
a function's tought pattern.

I must agree. Most of the cases I would use (inc a) is just faster 
replacement for (a: a + 1) which is exactly what is (a++) in other 
languages. And I'm missing (a+=5) as well.

would you mind?
 += a 5 (or rather add a 5)

cause then this could open door to a set of scalar ops which are 
not within rebol.  all following the same syntax.

but I understand, that if would be inconsistent with other Rebol 
actions like [abs negate ...]

but these are not ops.  they are functions.

maybe its time REBOL had a better support for ops.

I really don't know if there is any advantage, that (add a 5) doesn't 
change the value of a. But I'm not expert so will let the decision 
on someone else.

I'm sure I never used (a: add a 1)

exactly.  so current add is just useless luggage.

and using (a: add a 1) is slower than (a: a + 1) so I really would 
like to change it.

the only advantage is that I can write 10 * add a 1 instead of 10 
* (a + 1) - but as it's slower, why I should do it?