AltME groups: search

We need a function that does not evaluate or do chain assignment.

But let's you access the elements as if they are an object and can 
already exist in a block style spec that can be passed to context.

I could simply just use a block if I want to access elements but 
that isn't ideal for conversion to an object when I decide I want 
that flexibility.

Ideally you would use a construct for assignments of values passed 
via cgi.

It sounds like you need a PARSE wrapper.

is this really a valid email?

 >> email? load "carl@.com"
== true

I could suppose that syntax is valid if I worked my ISP was a root 
server.

cc#1509 -- Thanks Brian for consolidating a whole handful of bug 
reports [and/or misunderstandings].
That should help focus the core RT crew into clarifying / fixing.

I am well aware that this would be a significant change in semantics.

But this may certainly make it too big a semantical change even for 
R3.

Carl or anyone else with access to the R3 source is certainly the 
final authority on implementation overhead, but I'd like to add to 
the speculations: I think improved error causation should be possible 
with only adding minimal overhead, mostly to the non-local exit functions 
themselves.


If we have a task-local error handler stack (of setjmp/longjmp buffers, 
for example) it's mostly a matter of adding a few bits to those handlers 
describing wether they are valid targets for each class of non-local 
exit. Those bits must be correctly propagated/manipulated in functions 
which add their own handlers (the bit manipulation adds only negligible 
overhead). The non-local exit functions themselves check those bits, 
raising different errors if the use of the non-local exit function 
was invalid (as described in detail by Brian in the bug report). 
Those checks add a minimal overhead to each non-local exit function 
(RETURN, EXIT, BREAK, CONTINUE, THROW).

I think dismissal is a good call on that one.

Andreas, I don't have a problem with that solution in principle. 
It's just that it wouldn't work, and wouldn't be task-safe. The handlers 
for those functions would be task-local, the code blocks not. Plus 
it would break code that uses code block references rather than nested 
blocks, code that uses those functions through function values, and 
any function with the [throw] attribute (which we will be getting 
back in R3 with different syntax), and all of those exist in R3 mezzanine 
code. Plus there's all the extra BIND/copy overhead added to every 
call to loop functions, startup code, etc., and don't think that 
you won't notice that because that can double the memory usage and 
executiion time, at least.


The solution I proposed in the ticket comments is to have DO, CATCH 
and the loops set a task-local flag in the interpreter state when 
the relevant functions become valid, and unset it when they become 
invalid, then have the functions check the flag at runtime before 
they do their work (which they could because they're all native). 
This would be task-safe, only add a byte of task-local memory overhead, 
plus the execution overhead of setting and getting bits in that byte 
in a task-local way. It's the execution overhead that we don't know 
about, whether it would be too much. It would certainly be less than 
your proposal though.

However, CATCH/name and THROW/name would need the additional memory 
overhead of a single block of words per task in the dynamic solution 
to store the currently handled names.

It's funny: While regular R3 code looks a lot like regular R2 code, 
optimized code looks a lot different because the balance of what 
is fast and what isn't has shifted. At least regular R3 code looks 
a lot more like optimized R3 code than regular R2 code looks like 
optimized R2 code. This is because we have been focusing on making 
the common, naive code patterns more optimized in R3, so that people 
don't have to do as much hand-optimization. The goal is to make it 
so that only writers of mezzanine and library code need to hand-optimize, 
and regular app developers can just use the optimized code without 
worrying about such things.

The first is the proposal for a change of semantics, which I'm mainly 
interested in as a though experiment.

Btw, non-local code blocks are a common optimization trick in mezzanine 
code, one which shows up a lot in Carl's code. It's probably the 
reason why REBOL supports the concept in the first place. And I've 
written code in REPLACE that uses the BREAK function as a function 
value, though I haven't checked whether other people use this trick 
:)

Great, I'd really like to see this improved, even if it's only a 
rare corner case.

If you want to see how weird really optimized R3 code can get, take 
a look at the source of LOAD and IMPORT - they are probably the most 
heavily optimized mezzanine functions. For the most part the rest 
of the mezzanine code is written for readability and maintainability, 
and the language optimized to make readable code fast. It's a good 
tradeoff :)

Most of the time, actually, otherwise the BIND/copy overhead would 
make it a poor optimization.

Do you have a succinct example of such a use for optimization purposes?

IMPORT uses code blocks as a way of reusing duplicate code, though 
it might not be affected either. And REPLACE would be affected because 
'break wouldn't be bound at the point it is used: Being in a function 
isn't enough, it's outside of the loop. BREAK is used to break out 
of loops, not functions.

That means that the BIND/copy overhead for BREAK and CONTINUE would 
happen at every call to a loop function, not just FOR, FOREACH and 
REPEAT. And 'break and 'continue would become keywords rather than 
function names, unable to be used for loop-local variables.

LOOP, WHILE, FORALL and FORSKIP don't currently have BIND/copy overhead. 
Which is why they are used a lot in R3 :)

Yup. But not all loop functions need binding, only the ones with 
a lit-word argument with a doc string that says "will be local" or 
some such.

Ah, REPEAT doesn't say that. I should submit a documentation bug 
report.

But all the loop functions that take a word argument have BIND/copy 
overhead, and the rest don't.

btw, map-each is a burden, adding blocks by default.
Should be an option:  'map-each/only' to insert blocks,
Like other actions creating blocks do.

Andreas: what you ask for has been discussed extensively when R3 
was started, by me, Ladislav and Carl. There are a number of disadvantages 
to that, starting from the fact that you need to bind/copy a lot 
more than you do now (eg. inside CATCH). It would also, unfortunately, 
not work in cases like this:

I think that the implementation of improved error causation as described 
by Brian in bug#1506 would be very worthwile and should be pursued.

 - again, this is a thing I discussed with Carl quite long ago, but 
 it seems, that Carl disliked the fact, that the implementation would 
 have to be more complicated, than it currently is, while the effect 
 Sunanda would like to achieve is probably achievable even now

No, it just means that he wants to start the conversation from a 
good baseline.

We've been able to find out a lot from stuff posted so far and the 
scientific method though :)

I think a lot of the problems would be solved by just letting developers 
plug in their own recovery code into the console handler, and that 
would be more efficient too.

Yes. Or more generally, a special CATCH version (along with a proper 
predicate) that allows us to set up our own catch-all default handler.

You can already have a catch-all handler:

do does [catch [attempt code]]

add a loop 1 somewhere :-)

Yes, except for bug#851, which creates a no-catch situation

PS: I've always agreed on that.  The question is how best to implement 
such a thing.

A new section added: True Error Capture.

And also, because it was a hot topic above... with many of the key 
people chatting on it. So, good time to get it finalized.

The example just below that sentence with definitional scoping: I 
agree on that.


I ran into exactly this issue just last night in an attempt to wrap 
some function bodies in a primitive callstack mechanism (R2 code) 
so I could debug it easier. The debugging mechanism kept crashing 
there, because it ran straight through the first 'return and "returned" 
twice.


R3 of course doesn't need function scoped return for that reason, 
since I can already see the stack trace on an error, but for other 
reasons (correctness?).

Or it should be an refinement to DO?

do/on-error


But then it's a question, if TRY should be there in the first place.

*a* refinement

I see, TRY already has a refinement called /except.

How about allowing: clear object!


This could set all object! words to none. Would be a nice way to 
reset an object! into a clean state.

don't waste our time, do a mezz if you prefer ;-)

using clear would imply that an object is a series.

That was this one:

>> a: construct [b: c: 2]
== make object! [
    b: 2
    c: 2
]

Just so that we can do some dynamic building of blocks with set-words 
and pass it to construct and not worry about a set-word getting assigned 
a value from the chain.

yes, maybe a refinement that allows me to suppress the chaining for 
constructs

Paul, just iterate through the block before you construct it and 
whenever a set-word! is followed by another set-word! insert a none 
in between.

Yeah I could do that Anreas, just like most functions we can usually 
do some prework but thought it would offer something a bit safer 
built-in.

Write such a function and offer it to be included as mezzanine.

Any chance we can promote a feature of REBOL that looks more secure 
or performance oriented out of the box is a marketing plus in my 
opinion.

I could Andreas but thought it would be more bloat than a refinement 
would incurr.

So often I think that mezzanines are not the answer sometimes to 
what could just be added as a refinement to an existing function. 
 Don't like to do that much to functions that are often invoked in 
looping or iteration routines.

Chris, I had an issue where I was putting data into a block dynamically 
and then had a skip pattern over it so that every other word was 
turned into a set-word and then passed to construct.

As you can imagine that did a chain evaluation that I didn't want.

Then make sure to prepare a block that does what you want.

There was actually a bit more that it did in removing some data but 
anyway the point is that it cause some values to get the next value 
in the chain.

Shouldn't always be about - just creating a new mezzanine.  Think 
about the cost of the mezz verses an enhancement to existing code.

construct/as-is [a: b: 2]

Paul, set-word!s are syntax for SET. [a: b: 2] is syntactical short-hand 
for [SET 'a SET 'b 2]. SET returns sets a word to a value and returns 
that value. If you don't want to pass the result of (SET 'b 2) as 
argument to SET 'a, then just don't do it.

Now for real, it was just a request for something rather not as complex 
as the fear around it.

Great, then write /as-is as a mezzanine for now and propose it to 
be included.

Paul, you're basically asking for REBOL to do a fundamental change 
to its syntax inside construct.

with 2 blocks it's easy, one for the definition, one for the assignement.

>> assign: funco [spec vals][append construct spec vals]
>> assign [a: b: c: d:][c: 2]
== make object! [
    a: none
    b: none
    c: 2
    d: none
]

That you want a peculiar change to set-word! semantics.

From (a: (b: (c: 2))) to ((a:) (b:) (c: 2))

That's a fundamental change...

And now I would ask you why add that function to R3 when you already 
pass a spec to contruct in the first place?

I guess that's what you want. Now adding that as refinement to construct 
is a question of wether it would be of general utility. If not, it 
would just be bloat.

My point is that if we just adding your entire function to R3 verse 
a refinement to construct - we would be adding MORE bloat

Maybe your confortable with it.  Oh well.  But if you don't think 
the chain evaluation should be a safety concern then I think your 
not being rational.

let's say you have a service oreient protocal that is sending unencrypted 
blocks of data that is getting sent into contstruct on the other 
end.   All I have to do is capture it midstream alter the block and 
forward on and I can cause your code to behave differently.

why is that a safety concern? in that case REBOL would be one big 
security hole as this is standard syntax.

Paul, construct is using standard REBOL syntax in this case. If that 
is a safety concern for your purposes, that's outside the scope of 
CONSTRUCT.

Paul, you don't create services that carelessly evaluate data that 
is potentially manipulated by an attacker. That's a security hole 
and bad coding. That's one of the good things about dialects.

Agreed, and that's what this is - a dialect - as Rebol's sop is chaining...

I'm saying to offer a case where we don't chain.

Why not also offer a case where we drop all strings encountered?

Or a case where we double all integers?

Are the strings a concern?

are single integers a concern?

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

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.

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.

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.

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.

(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
]

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.

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

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.