World: r3wp

It can be really convenient though :)

What overhead?

It's similar to a THROW, setjump/longjump overhead mostly.

That is why returning a value as the last expression of a function 
is faster than using the RETURN function.

REBOL isn't compiled so it's not the same thing as in a native language.

Brian, is it possible to expand on that (setjump/longjump), or is 
there a Carl post that summarises?  This is good to know - specifically 
as it relates to R2 and R3 implementation...

For example, [return true] vs [true] or ["a" exit | other rule]

It's the same in R2. PARSE is diifferent though, but exit or return 
in the parens has the same overhead.

I don't see how the overhead of continue would be greater than the 
overhead of further evaluation where it isn't used.

I tried timing tests on my R2 ad R3 examples.
R3 runs in about half the time. 

Conclusion: 'continue is a good optimisation over loop 1 [...break...]

That does not say anything about the overheads of 'continue.....Just 
that an extra loop is an extra overhead.

>>  loop 1 [break blah: 1 blahblah: 2]
>> find first system/words 'blahblah
== [blahblah]

I think that Rebol first must parse the block to evaluate into 'tokens', 
that's why the words are defined as unset in the system/words

Exactly. It must load the block, so create the words. Then it can 
do it.

REBOL/View 2.7.6.3.1 14-Mar-2008
Copyright 2000-2008 REBOL Technologies.  All rights reserved.
REBOL is a trademark of REBOL Technologies. WWW.REBOL.COM
>> load [blah: 1]
== [blah: 1]
>> find first system/words 'blah
== [blah]
>> blah
** Script Error: blah has no value
** Where: halt-view
** Near: blah

REBOL/View 2.7.6.3.1 14-Mar-2008
Copyright 2000-2008 REBOL Technologies.  All rights reserved.
REBOL is a trademark of REBOL Technologies. WWW.REBOL.COM
>> loop 1 [break blah: 1]
>> find first system/words 'blah
== [blah]
>> blah
** Script Error: blah has no value
** Where: halt-view
** Near: blah

By the way, doing

	find first system/words 'any-word-you-like


will always succeed, because before the console evaluates this line, 
it first loads it, so the word will be added, and thus, be found.

A better test is:

	"any-word-you-like" = last first system/words

which does not introduce a new word before evaluation is done.

>> loop 1 [break blah: 2]
>> last first system/words
== blah

Anton, I think that would be a nice topic for a blog post.

Very Heisenberg; Call the post, Anton's Postulate for getting round 
the REBOL uncertainty principle.   ;)

How do I submit a request for Carl to include a feature in R3?

rebdev is the shortest path for now. I can relay it.

except, rebdev seems to be down. he said that some changes were going 
to be made... will see if it comes back up in a few hours.

Henrik my request is a change for ports.

You know the way we have open/lines function,  I would like to see 
open/blocks function.

have you worked with R3 ports yet? they are very different from R2 
ports.

No, I don't have access to it.

I just figure I hadn't seen it mentioned of having this feaure.

rebdev was up. the client was too old. :-)

Good are you making the request?

I'm not sure how to describe it.

wait... perhaps it's better to use Curecode if you have an account.

Basically it is open/lines  but instead of separating lines from 
the stream it would separate the blocks.

So a block of blocks would be returned.

I don't know what curecode is.

Never heard of it before.

Curecode is the R3 bug database. It's public.

Oh, didn't know that.  Got a link?

http://curecode.org/rebol3/view-tickets.rsp

cool, I'll see what I can do in that regard.

Thanks Henrik.

NP. Please study the reports. I think there are many regarding ports.

Hmmm, it doesn't let me register.

Oh it took my name but gave me an error.

I actually would only request it for the speed.  I already have the 
produced the functionality but it obviously isn't native so I figured 
we could gain some speed.

hmm, not sure there is going to be any /lines etc. for read.

besides that - line feed is pretty common delimiter, whereas blocks 
are only REBOL facility. I think it belongs to higher level parsers 
(decoders)

some few weeks ago I posted here xy links about new ports, read vs 
load etc blogs, which sum those issues up ...

so no more /lines?

READ of file and http ports is binary, so no /lines.