World: r3wp

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?

Maxim: "geomol and others...  INC with lit-words is seriously flawed 
in actual use ... a: inc a..." If I understood you well, you are 
saying, that you don't like an expression of the type: inc 'a, since 
the 'a looks unnatural to you. How about inc pick [foo bar] 1 then?

...or inc first [foo] ?

what is:
inc pick [foo bar] 1

or rather, how often/when is this going to be used?

I have nothing against lit-words. But maybe would like more inc a 
to increment a and change the value of a as well.

what would be faster:
inc some/object/some/value
or
some/object/some/value: inc some/object/some/value
?

inc (evaluate_something) : if you cannot use it, then the language's 
orthogonality is "impaired" (the language is referentially nontransparent, 
there are places, where you cannot put/evaluate an an expression

in this case:

inc pick [foo bar] 1


there is nothing stopping inc from changing foo or bar also just 
like you?

do not understand your question...

I just ask why  inc A  would behave differently than inc 'A

obviously, if A contains something else than a scalar, an error is 
raised.

because it is exactly the same case as in:

a: 1
equal? a 1 ; == true


, where we don't want to compare the variable with one, but the result 
of the expression (a), which is one

if we had: equal?*: func ['value1 'value2] [equal? :value1 :value2], 
then such a function would be totally useless

...since 
>> equal?* a 1
== false

yes... but equal is a function... not an op ;-)

what? equal? is a prefix version of the = op

to be understood: I am not against side effects (changing the value 
of a variable), I am against nontransparency "impairing" the language

Maxim: I guess, that your anti lit-word contribution does not take 
this into account, does it?

    type? 'a ; == word!

well type? evaluates 'a right?  which really is a word... Am I right?

I'm not agains lit-word . But if I understand Maxim, he is scared, 
that in most cases we would use  inc 'a   because that's what at 
least the way I would used it - to change value of a

and to be correct, I would need to for example to change it in object: 
   inc some/object/a

and inc 'a complicates other things ...

I really don't like, that now I have to write  some/object/a: some/object/a 
+ 1

exactly what Oldes just illustrates

but I understand what Ladislav means by inc 'a  in evaluating 'a 
 means increment the word which 'a points to.

remove the inc 'a thing. Why would we need to check for lit words? 
it complicates things.

Yes, I understand it as well. So I was asking if we can than have 
 inc some/object/'a  (which I found quite cryptic)

whereas  inc a  means increment the content which is stored in a. 
 which could be a word, in which case, it will change the content 
of that word directly.

Maxim: "...I understand what Ladislav means by inc 'a  in evaluating 
'a  means increment the word which 'a points to" - actually not, 
I see it differently. INC 'a means, that before the INC obtains the 
argument value, an expression is evaluated and its value supplied 
as an argument. *if* you disallow that, then you disallow expression 
evaluation

and the funny thing is, that the lit-arguments don't disallow evaluation 
of all expressions, since the expressions of the :a type are evaluated!

I give up... I'm lost in theory :-)

just give me something better than:  some/object/some/value: some/object/some/value 
+ 1