World: r3wp

is an extra  get /set that much effort?

but  i dont  like  funcs that  way. i read a and think  it is  evaluatet. 
leads  to confusion.

Volker, maybe not. But then we should just stick with

a: a + 1

shouldn't we?

if  it  looks like an operatorthat say  "exception"

but i prefer    a: + 1

or     inc 'a

a:  -  1 ; disambigius.

Volker, I follow you. Our normal way of thinking about functions 
and lines of code in REBOL is, that if we see a word, and we recognize 
it as a function, we look for arguments after the word. And we wouldn't 
think, those arguments would be changed. If words (variables) change 
value, we expect a set-word (like a:). Conclusion might be, that 
my suggestion will probably lead to more confusion. Falling back 
to ++/-- (or INC/DEC), those might be confusing too.

Problem with

a: + 1


is, that the plus sign can be seen as a unary plus. Because what 
should this mean?

a: + b

Same with unary minus as you point out.

yes, but if we think c,   += and  -=  are  a close accosiation.

unary + makes no  sense.  unary minus makes, thatis a  problem.

a+: 1
maybe?

Not good, because a+ is a valid word.

or  without space,  a:+  1

but these break syntax.

hmm yes ... and yes.

although, an operator-word! as datatype?

argh, it's hard to define a language! :-)

yep

a:+ is  already an url.

Geomol - your function posted in blog works without the set-word, 
so why you needed it to work via a set-word?

Because:

>> mult2: func [value] [value * 2]
>> a: 3
>> mult2 a
== 6
>> a
== 3

a isn't changed.

If ++/-- are introduced, they'll change a this way:

>> a: 3
>> ++ a
== 4
>> a
== 4

ah, I see ...

My argument is, that if something like ++/-- are introduced in the 
language, I as a programmer would expect, that I can make my own 
++/-- like functions very easily.

I keep thinking about operators (of type op!). It's not possible 
to make new operators in REBOL afaik. Why not? Can we come up with 
an easy way to make new user-defined operators?

I don't need such functions. IMO operators already break rebol left 
to right evaluation. IMO it only will cause more confusion. INC a, 
DEC a, is imo much more rebolish.

Its not possible because  Carl hardwired them in r2. AFAIK its posible 
 in r3.

Volker - how do you know? :-)

Because in some chat  somewhere Carl hinted it. IIRC  and  all.

Maybe something like:

>> root: operator [arg1 arg2] [arg1 ** (1 / arg2)]
>> 27 root 3
== 3


This define root as an operator, which will calculate a given root 
of a value. The 3th root of 27 is 3, because 3 * 3 * 3 = 27

Or maybe the operator should be defined the other way around, so 
I should write:

>> 3 root 27

But is it REBOLish? :-) Like Pekr is concerned with. REBOL is a different 
language. It's more of a human language than a computer language. 
I think, a key to decide the structure of the language is to look 
at the sentences, it's possible to write with the language, and then 
see if those sentences makes sense and are easy to read and understand.

Today I can define root as a function:

>> root: func [arg1 arg2] [arg1 ** (1 / arg2)]

and use it:

>> a: root 100 3
== 4.64158883361278


The question is, if it will be better to be able define root as an 
operator and then write:

>> a: 100 root 3
== 4.64158883361278

We can also look at it this way:

Anything is possible in dialects. It's possible to make a dialect 
parsing a block, where I can use root as an operator. If it's possible 
in a dialect, why shouldn't it be possible directly in the language? 
Of course it's then easier to make code hard to read and understand, 
but that's possible today with dialects. Will we as developers have 
the freedom to do almost anything, and then it's up to us to develop 
code easy to read and understand, or will we like restrictions? If 
the freedom is used the right way, it's also easier to develop code, 
that IS easier to read and understand.


My point of view is, that when the language has operators, it should 
be possible to make our own operators too.

If ++/-- are introduced, it should be possible in an easy way to 
make our own functions working the same way.

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