World: r3wp

Carl hasn't revealed that yet - which is why I keep asking for "in 
depth" explanations. This is another of those cases where Carl goes 
into a cave and comes out with something that is (usually) awesome. 
Design mode. He hasn't gotten to explanation mode yet.

Ok, thanks Brian.

The "new evaluation model" of the command! type is what I find most 
interesting. That would be the only way to do other forms, but there 
isn't enough info out there to know whether it does.

I don't understand your comment Brian. I am simply asking for R2 
DLL interface, but improved. I can understand that there is probably 
no need to introduce more than one way of how to interface external 
environment, but then I want R2 DLL like interface being a plugin. 
Of course, this capability is so basic though, that I want it inside 
of REBOL.exe

Brian: could such a "new evaluation model" help with something like 
rebcode replacement? :-)

The problem is that the R2 DLL interface sucked. One of the base 
requirements of the R3 plugin model wass that it be powerful enough 
that you cold write a generic wrapper dialect as a plugin, and then 
use that dialect to specify the API a DLL.

yes, that is what I want.

Of course that wouldn't be as good as actually writing a custom plugin 
for the DLL (or more likely using one that someone else wrote).

As for other blog - Objects as a base type ... is there any implication 
what it means for object semantics? IIRC you expected some changes 
in object semantics, but Carl states, that other types as ports, 
tasks, etc. share the implementation, so I wonder if you can really 
expect any change here?

To write a rebcode replacement all you need is user-defined types 
and the knowhow - it's on my todo list. However, user-defined types 
will probably need to be defined in plugins, and at the very least 
we couldn't even specify how to define them without a working plugin 
model. So it will help, indirectly :)

Objects as a base type blog = documentation of the way things have 
always been, not a sign of things to come. It was probably in response 
to bug#838 and my reply to it.

Once you have plugins and commands, there may be less need for rebcode! 
- you can just write natives if need be. The reason for a rebcode 
replacement then would be security (not rebcode's strong suit), since 
rebcode would be managed code.

security (not *the old* rebcode's strong suit)

OK, thanks for explanation. Looking forward to something more concrete 
= 1st plugin code example :-)

brian: what is Carl using for compilation... GCC?

He doesn't say, but I expect GCC on *nix and OSX, and I'd be surprised 
if he wasn't using MSVC on Windows. REBOL has been around much longer 
than GCC has been usable to build normal Windows apps. We'll seee 
soon :)

what do you call words such as "back" and "tail" and "next"?  Is 
there a special term were using for these?

I call them navigation functions, usually for series. I'm not aware 
of any official term.

I'm thinking about putting in an enhancement request.

or wish.

Interesting. For what do you wish? :)

if so, there should be a way to classify them in a helpful way in 
documentation and help

These functions have been part of the recent debate over series! 
and its types...

the nearest method is to search for functions that manipulate specific 
datatypes.

http://curecode.org/rebol3/ticket.rsp?id=844

I just submitted that wish.

there is a better way to write that request: AT should support block 
directly as index.

what you mean?

copy/part does that.

yeah but that is a copy.

BACK TAIL series sets the position - the AT is a noop in your example.

not sure what that means.

BrianH, not if the AT specifies a different series than the BACK 
TAIL.

if it isn't doable just update the ticket to state such.  I just 
wanted to get the wish in there in case I think of it again and forget 
we discussed it.

instead of writing:

at block1 index? block2

it could be:

at block1 block2

But those are supposing you know the index length.   I was hoping 
to avoid that with my request.

Specifically for dynamically allocated series.

you can always use skip -n if you want to jump relatively in a series.

to me it just seemed more REBOLish to use AT in the manner that I 
posted.

Follows the KISS principle to me.

I can update the ticket if you like. What would you like it to say?

INDEX? can return the result of your calculated position. Your example 
would be:
AT series1 INDEX? BACK TAIL series2

Wait a minute - Carl's method is simple things should be simple to 
do (STSBSTD).  A longer acronym.

You can write what you want.  It is just a placeholder for me to 
not suggest it again.

I'm not downplaying it, I'm just trying to clarify. At this point 
I don't understand what you want well enough to answer the question.

I don't understand it either... what should be result of your example 
code?

i think he wants AT working like COPY/PART (the index could be an 
integer or a serie aswell)

Well, if the index is a series offset, even a calculated one, then 
you can already have a reference to that offset without the AT.

It makes sense if the 2 series are differents.

but i agree, i don't see so much use cases for that.

>> series
== [1 2 3 4 5 6 7 8 9 10]
>> series: at series back tail series
>> series: [10]