World: r3wp

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

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.

what I say is bad is to disallow expression evaluation, since REBOL 
is an expression - based language, as you may recall

Ok, that I understand.

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)

Oldes, how about:
    inc 'some/object/some/value
or:
    increment 'some/object/some/value 5

The second version of my functions without the lit-word formal parameters 
will do just fine.

I already solved the path situation. Read the code.

The relevant portion is:
    if path? :x [
        x: in do copy/part :x back tail :x last :x
    ]

This retrieves the word to be updated and puts it into the x local 
variable, just as if you had called the function like this:
    increment in some/object/some 'value 5

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?

why not allow accessors for any types?

(and actually per instance, for some types)

Well, because only series, any-word and object types have internal 
state that could be changed.

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

All of the modifiable types already have accessors, they're just 
awkward in some cases.

(read all as on types which this is logically possible, althouh in 
pure OOP languages you can set the accessor fof any type.)

fof-for

Carl had talked about allowing some set-word functions but I'd rather 
have a full set of accessors (set get pick poke skip, etc)

so second 13  could be made to return 3  :-)

The situation is the same for OOP languages too. None of those have 
modifiable numbers either, just modifiable variables that can hold 
numbers.

in a specific context (not by default)

Second in what base? In what byte order? Second what, bit or byte? 
If you don't specify, the function has no meaning.

this is what the use of accessor IS  :-) this is where you decide, 
what such things relate to.

Ah, but where there are clear default answers to those questions, 
accessors already exist.

there are no accessors in rebol, they are defined internally and 
cannot be changed.

I mean, the concept of an "accessor" is the fact of changing them 
externally.

this allows you to remove the complexity of an API and integrate 
it within the normal flow of a language.

There are no object! accessors, to be sure, except for field setting 
and getting. It definitely makes sense to add them to object! types, 
but it doesn't make sense to add them to non-object types.

why not?

conceptually, in rebol all the types are private classes.  if we 
had access to the accessors of integer, we could fix/adapt the "out 
of bounds" conditions, for example.

I understand that this raises some points as to the loading part, 
but within an application this is not an issue, it does not change 
REBOL itself, it changes the application of a type within a specific 
use.