World: r3wp

Do we?

I don't know of a construct refinement that drops all strings.

Then we just make sure they get assigned to the proper place don't 
we?

yes, we do. with PARSE and dialects.

And that's what you should do too, Paul.

I do Andreas, I have to currently use more bloat just like all of 
us do to handle it.

That's not bloat, that's application specific code.

And no, it's not "all of us", as none of us have those specific needs.

Just as you don't seem to have the need to drop all strings ...

bloat is in the eye of the beholder.  To me where it takes more code 
to do something that could be done elsewhere is bloat in my book.

You all have that need.

if it made general purpose sense then it probably would be looked 
at, but with the amount of discussion here, how generic is it exactly? 
it helps with some code examples that significantly reduce the code 
size in a general way.

I vote against the proposed change to CONSTRUCT. I believe the need 
is better served with a mezz. If it becomes popular and useful, then 
consider making it part of the standard distro.

I'll add the solution to another power type mezz package.

Tbat is what is great about NO!

Anyone know how Lua handles this?

http://host4.altme.com/altweb/rebol3/chat771.html

sorry

wrong place to paste

trying to do a bit of marketing/advocacy

There is a plan to create a library of community-supplied modules 
full of useful code that isn't generally useful; we've been calling 
it R3/Plus. Code that would go in /Plus is called library code, as 
opposed to code that gets built into R3 itself, which is called mezzanine 
code. Paul's suggestion seems like a good candidate to be library 
code.

Carl, if you make RETURN and EXIT definitionally scoped, it would 
help if the throw: attribute would disable that, so functions like 
USE would work properly. Also, please keep BREAK, CONTINUE and THROW 
dynamically scoped - most of the functions that they break out of 
don't do definition, so making them do so would add unwanted BIND/copy 
overhead.

I am not sure I understood the plan, is it so, that the plan is, 
to have two types of functions depending on an attribute:
-functions with dynamically scoped Return/Exit
-functions with definitionally scoped Return/Exit
?

BrianH, definitonally scoped Return/Exit need not be disabled, it 
would "automatically" work as expected, that is the beauty of the 
approach

(my article discussing function attributes illustrates that)

http://www.compkarori.com/vanilla/display/Function-Attributes

What's the quickest way to detect R3 vs R2 for hybrid scripts?

 - see e.g. http://www.rebol.org/art-display-article.r?article=w24v

Note to the "Should we catch unwinds?" question in the http://www.rebol.com/r3/notes/errors.html
article - the subject of the CureCode #1506 is, that it is (or should 
be) possible for the interpreter to find out, whether the unwind 
would cause a "No catch for throw" type error, and, that Try should 
catch such an "unhandled" unwind.

Excellent article Ladislav. Thanks for taking the time to write that.

I wrote a few comments to the blog, explaining the advantages of 
the definitionally scoped RETURN and EXIT proposal. The optional 
function attribute we would need would not change them to dynamically 
scoped, it would just tell the function to not redefine RETURN and 
EXIT within, allowing them to keep their existing bindings. No dynamic 
scoping of those functions would be needed at all.

Adjusted the wording of bug#1509 to reflect the new documentation 
of the unwind functions.

(Continuing from "Rebol School".)


I've thought about TRY/EXCEPT too, since it popped up a few days 
ago. My thoughts are more about design. Why do we have TRY? Why not 
make /EXCEPT a refinement of DO? DO can do any type, TRY only works 
on blocks. If you wanna do a script on the net, and it can go wrong, 
we have to write:

try/except [do <url>] [<handle error>]

With /EXCEPT on DO, it could be:

do/except <url> [<handle error>]


My point is: is it good to have all these words in the language? 
It may add depth, but it also add confusion and complexity. Maybe 
the depth could still be there with fewer words, and the language 
would be easier?

I don't miss a simplification of DO/TRY as much as structures for 
sequential tests that may or may not fail. REBOL doesn't have anything 
here, so you have to roll your own. Say you're trying to connect 
somewhere in a protocol and one of 50 things can go wrong, so you 
have to state 50 tests, 50 error messages, 50 exit routes. That's 
a lot of lines of almost identical code.

There may be another concern with this. How do we get the error in 
the except block, so we can handle it? A common way is:

if error? result: try [1 / 0] [probe result]

This doesn't work:
(Remember to clear result, if you did the above first.)

result: try/except [1 / 0] [probe result]

And having /EXCEPT on DO is the same problem.

Henrik, yes, what you explain is a common problem. The best way to 
handle it, as I see it, is with a foreach loop, like this:

foreach [code handle-error] [
	[do something] [handle-error-1]
	[do something-else] [handle-error-2]
	...
] [
	if error? err: try code handle-error
]

Ah, maybe handle-error-1, -2, ... shouldn't be in blocks. But you 
get the idea.

that's possible, although you need to break at the error. at least 
that's how I would want it

Agree, gotta break out of the FOREACH loop too.

A better example of the foreach loop:

foreach [code handle] [
	[1 / 0] [print "error 1"]
	[2 / 0] [print "error 2"]
] [
	if error? try code [do handle break]
]

If last error was kept in a system variable (so we could get it there), 
the /EXCEPT refinement would make better sense.

Maybe it is in system/state/last-error

No, doesn't seem to work, if you handle the error yourself.

Geomol, set-word assignment uses the SET function, which by default 
doesn't accept error! values (by design). If you want to assign error 
values then use SET/any.

Geomol, maybe you're missing that /except accepts a function, ie. 
try/except [...] func [error] [probe error]

Gabriele, yes, I didn't see that. So it should be possible to do, 
what I considered.

Brian, no, it works here (version 2.100.95.3.1). Do this:

if error? result: try [1 / 0] [probe result]

It's unset!, SET can't set, not error!.

Weird, that shouldn't work. That should be reported.

It looks like untriggered errors are assignable with set-words in 
R3. I wonder if that was an intentional change. It should be reported 
as a bug, with a request for Carl to say whether it was intentional.

I reported the bug in #1515, recommending that it be declared not 
a bug. However, when combined with #1509 it turns into a nasty security 
bug (similar to #1004). We really need to fix #1509 asap.

Brian, why do you think that errors should not be assignable with 
set-words?