World: r3wp

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.

In the blog and here I was in favor of adding property accessors 
to object types (think get and set handlers). There was much debate 
as to whether such a concept would be added to REBOL 3 - I was in 
favor.


If what you want is general redefinition of the actions associated 
with a type, what you are really asking for is user-defined types, 
and those have already been promised for REBOL 3.

they still boil down to pretty much the same thing... they could 
simple be the same api.

IMHO.

Brian: trampoline actions: interesting idea.
For:
- simplifies some scripts
Against:
- may complicate/slow down the interpreter
- may make debugging harder in some cases

so, I am neither 100% for nor 100% against it

Maxin, I like that there are two models for types, with different 
semantics:

- Datatypes: Classes with polymorphic methods handled by dynamic 
dispatch.

- Objects: Unique objects with methods directly associated, where 
you can emulate class-based or delegation-based systems at your whim.

The advantage of having two models is that you can balance efficiency 
versus flexibility. The only disadvantages are that there is a fixed 
set of datatypes (to be fixed with user-defined types), and that 
the usage patterns for objects are somewhat limited (which would 
be fixed by the get/set handler proposal if implemented properly).

Ladislav, another to add to the For list:

- Lets programmers used to imperative programming code using algorithms 
they already know, rather than having to adopt a functional style.

That may be one for the Against list as well, depending on your attitude 
towards such things.

I think I meant to say that I hope the api, can be uniformitised... 
so we decide if we want instance or class based method.

As for complicating or slowing down the interpreter, I don't think 
that it will. The trampoline code would be contained in the actions 
associated with two datatypes, not in the interpreter at all. The 
interpreter would not need any changes.

Maxim, what does it matter if the API is uniform, as long as the 
syntax is similar? You can't make the API completely uniform when 
you are supporting different semantic models.

The speed of datatypes comes from the fixed action list. It allows 
the dispatch to be a simple retrieval from a fixed offset into a 
function table, no lookup required. It is not the same thing as general 
class-based methods, which in a language with dynamically typed variables 
would need to do a lookup to figure out where to find the method 
to call, same as with instance-based methods.

- Lets programmers used to imperative programming code using algorithms 
they already know

 - there is no algorithm you cannot use in REBOL even now, those are 
 mainly C idioms as far as I can tell?

I meant style I suppose, though even C is expression-based. The idioms 
would actually be more assembler-like than C-like, for 2-address 
instruction sets like x86. Still, this wouldn't add anything to the 
language that isn't there through other means, except speed. And 
while it wouldn't complicate the interpreter, it would complicate 
the semantics of REBOL, making it harder to explain, debug or reimplement.

agreed

http://www.rebol.com/priorities.htmlIn the green little box, there 
is an item called "Deci". What's that?

A new deci! datatype for storing floating point numbers in BCD (Binary 
Coded Decimal) format.

Tanks Anton.

=> Thanks

good news about the STACK function: http://www.rebol.net/cgi-bin/r3blog.r?view=0075

hah! A percent datatype as well. :-)

yes... singing with Queens... I want it all, I want it all,I want 
it all, and I want it now:]

Oldes, how spooky, I have a Queen song running in the background!

I agree Queen songs are spooky ;-)

:-) Good to be back!

Hi Peter, sadly, this isn't reddit. I so want to vote your comment 
up :-D

Minor Bitsets - http://www.rebol.net/r3blogs/0077.html