AltME groups: search

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

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 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.

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

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

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

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.)

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: 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

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

but thats a rebcode-case anyway.

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.

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.

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.

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.

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).

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

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

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

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

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  ;-)

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

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 
 ;-)

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?

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.

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.

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

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?

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  .

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?

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.

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.

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)

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?

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

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

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!

lost in theory? It is simple. INC is supposed to be a function. It 
either allows evaluation expression using normal argument, or it 
disallows expression evaluation using lit-argument.

that still may mean you may be able to write: inc 'a/b

(but don't forget about complications, when A is a function!)

There might be options to solve the path situation:
inc some/object/some/'value
inc some/object/some/('value)
or maybe
inc '(some/object/some/value)
Just suggestions.

If you think, "inc a" should change a, then think about these, that 
we have today:
negate a
- a ; unary minus
abs a

Also many math functions, like:
exp a
log-e a
etc.

Why don't all those change a?

I guess it is a rhetorical question, but allow me to answer: because 
we need NEGATE, EXP, etc. to be able to process a result of a REBOL 
expression

like exp (a + b)

Ladislav, your point about SECURE using lit-word formal parameters 
is a good one. It is interesting to note that the parameter in question 
is a keyword, and that its binding or any references are ignored. 
Clearly lit-word formal parameters are useful for keyword arguments.

While we're at it Ladislav, I'd like your opinion about an idea I 
posted on the blog comments. I was thinking about the possibility 
of adding trampoline actions to the word! and path! datatypes.


When an action is called, execution is forwarded to a native function 
associated with the data type of the first argument, the action handler. 
In other languages this is called dynamic dispatch. My idea is to 
add action handlers to the word! and path! datatypes that would lookup 
any referenced value and forward execution to that value, and then 
possibly change the reference of the word to the result before returning.


This proposal would, in effect, add seamless support for side effects 
to REBOL evaluation. For instance, if there was a trampoline for 
the ADD action, increment would be basically this:
    add 'a 5


The disadvantage is that side effects won't be as clearly limited 
to set-word expressions and SET functions, so you would have to trace 
the dataflow to know whether the a in:
    add a 5

refers to a number, or to a word that refers to a number. There are 
other places in REBOL that need similar dataflow analysis to understand 
your code though - the consequence of dynamic typing.

What do you think?

Number and character types are not modifiable. When you change a 
number, you actually replace it with a new number.