World: r3wp

The text is not a function. The *handler* for the text is a function.

yes, but then the methods are Transcode, To-block, etc. the #[...] 
texts are only data for them

so, the distinction is, that "#[...]" actually is data (argument/arguments) 
for a constructor, not a constructor

TRANSCODE calls the action. I am talking about internal code here.

And it's not text - bug#864 proved that.

yes, I understand, there is a constructor (there has to be one), 
but the "#[...]" text is not a constructor, just data for a constructor

Ladislav, if you think that I am saying that the lexical form #[...] 
is a function call, you are wrong. I am saying that the processing 
of that lexical form is handled by an internal function call that 
constructs a value of a particular datatype. That is what I have 
always beenn saying.

And since then I have been trying to clear up that misunderstanding.

yes, that is correct, of course. What I mean by saying, that #[...] 
is not a constructor is, that the function is "somewhere else" (in 
C or internal Rebol code, I do not exactly mind in this case)

Well, the function "somewhere else" is all that I have been talking 
about, not the lexical form.

BTW, what do you think about the END! datatype? is there really a 
reason, why it has to be "exposed"?

There is a reason to reserve it, but not expose it per-se. It would 
need to be used by internal code and a lot of that internal code 
is written in REBOL in R3. From what I know about blocks (minimal), 
it seems like the nul character for C strings, but less required.

There are other internal datatypes, like handle! and frame!.

I do know one use for the END! datatype, but am not sure, it should 
be "exposed" this way, taking into account, that it is an "implementation 
detail" in fact. The same applies to handle! and frame! or e.g. the 
symbol! datatype n earlier interpreter versions.

You are prejudging on what is exposed: Most of the code hasn't been 
modularized yet :)

aha

yes, that is why I wondered

Same about Pekr's complaint earlier about LOAD-PLUGIN. We aren't 
prematurely modularizing the code so as to avoid setting up artificial 
barriers. It is better to let the code grow and see where the natural 
bondaries are. Alpha :)

do/next matters to me, but, I don't count for language features (Carl 
put me in the 0.1% basket ;-)


What I would like is a "break out"of a block much like throw, that 
allows me to re-enter even in nested blocks.

Continuations, basically. Sorry :(

e.g.   pos: reduce/do/try/...  [ some code [ nested [ and then some 
[ break! some more more ] more ] really ] more ]

And then: "into" pos

I think a closure over the evaluation with an "into" would do it. 
It is easy to see parse with into do this.

That's a continuation.

Maarten, yes that jump out and back again into the same state would 
be very cool but it seems a very core thing that is either possible 
or not

We removed those from REBOL with the R1 to R2 rewrite. Sped up REBOL 
by around 30 times as a result.

It is possible at the data manipulation level. REBOL is a data language 
after all.

Brian, I don't buy that argument.

Brian .. is there a way to get current local state inside function 
as a block and store it somewhere?

Besides, we have sped up hardware more than that since then ;-)

I mean list of variables / words defined in a function and their 
values?

I would be happy with just breaking out of a nested block and having 
a "deep" reference instead of only the one from the lastly traversed 
inner block

Janko, store it, yes, more or less with the STACK function. Restore 
it, no.

Rebuild it?

there is stack function? .. is it R3 only?

Yes, and restricted by PROTECT.

aha interesting

can you also somehow access your current position in the block of 
code like as if it's a serries? *B*: none a: does [ 1 + 2 *B*: get-current-pos 
5 + 3 ] ?

Brian, when you get to tasks, pleae look at the queue/multiprocessing 
module in Python 2.6 I can help you on that. I think they have done 
it right, and it feels very REBOLish.

Maarten - you should be instead ready with your proposal for R3 tasking 
:-) Then no continuation is needed, no?

If you want to resume continuations you have to build your runtime 
around the concept, which basically turns your language into Scheme 
with a different syntax - that's R1. Like R1 and early Schemes, your 
language will be slow. Scheme solved this by compiling the code and 
letting the optimization phase remove the continuations, where possible 
- where not possible, Scheme is still slow.


REBOL doesn't have this option because code is data *at runtime*, 
rather than having the input syntax be data, but the runtime code 
the result of compilation. Code that relies on this (and there is 
a lot of that) is not compilable in any direct sense.

The days of hardware getting faster is going away - now the hardware 
is staying the same speed, but more hardware (more cores) are being 
added. You get more speed through parallelism. Slow langages are 
getting made faster or dying out.

Brian, I only want to exit a deep block and get a position back, 
like [ 1 5 7 ]  which would mean:
 

at position 1 there is a block, inside at position 5 another, move 
to position 7 now.

Think at/deep [ [ [ ]]]  [1 2 3]   - that would be all.

There is no continuation involved there.

Just data? You threw me with the "exit", which doesn't really apply 
to data.

Maybe AT with a path! indexer?

Let me be more specific:

at with a path indexer!  at [ ] 1/2/3


And inside parse break providing a path indexer. That would do many 
tricks

a: parse [ ..... break .... ]
>> a
1/2/3

The parse break op means something else, though that should be extended 
to breaking to the next loop op out. I'm not sure what the value 
of the parse one would be if you can't resume the parse where you 
left off. You can set the position in the data, but not the rules 
or any nested parse blocks.

brian .. I am looking at stack in R3 .. do you have any idea how 
you could return arguments names and their values? I get the values 
..


>> a: func [ b ] [ probe stack/args 0 probe stack/args 1 probe stack/args 
2 ]
>> a 123
[0 none none none true none none none]
[123]
none
== none