World: r3wp

that doesn't work for this issue

>> a: construct/only [c: d: 1]
== make object! [
    c: 1
    d: 1
]

Chained assignments aren't an issue, they are an intended feature.

I understand that but we need a feature in which they are NOT.

>> construct/only [a: b:]
== make object! [
    a: none
    b: none
]

that is still a chained assignment

But that's not a problem.

Ok, it doesn't seem your following me, so let's forget about construct.

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.

So it would be similiar to construct except without the chain assignment.

CONTEXT does chained assignment too, btw.

Yes, so does almost everything in REBOL since day 1.  Surely your 
not thinking I just stumbled upon that discovery.

Do you need to access the elements as if they are in an object, or 
elements that are actually in an object?

I'm just seeing room for improvement here to make REBOL even more 
safe.

But there are no safety issues with chained assignment.

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.

Not so my friend.

That is where your wrong.

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

While those items are string values it could still potentially be 
exploited in my opinion.

It sounds like you need a PARSE wrapper.

Or we just make sure that such assignment is not chained -       
       ;-)

bbl

If the CGI data is parsed properly it should never generate anything 
other than pairs. If it ever generates chained assignments that is 
an error in your parse rules, not CONSTRUCT.

By "pairs" I mean name-value pairs, not pair! values.

On the other hand, you can APPEND to objects and maps in R3, so you 
don't need the block at all.

And appending to objects doesn't chain assignments.

I'll create my own function.

problem solved.

is this really a valid email?

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

It doesn't check whether the email address is valid, just that the 
syntax is valid.

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

Paul, creating your own func is the way to go for that. And emails 
can be very complex. REBOL doesn't try to validate against the true 
grammar, it just looks for @.

actually the smallest valid email in Rebol is 1 char + @
>> type? 1@
== email!

:-)

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.

Paul, I usually test email entry using simmilar code to this:
if any [
    not email? try [email: first load/next cgi/email]
    all [
		not read join dns:// email/host
		not read rejoin [dns:// "smtp." email/host]
		not read rejoin [dns:// "pop." email/host]
		not read rejoin [dns:// "mail." email/host]
		not read rejoin [dns:// "www." email/host]
		...
	] 
][
	print "email is not valid or your email server is unavailable"
]


Worked well in most cases for me but I bet others might have more 
sophisticated solutions.

Thanks, Sunanda, never would have figured it out without your help.

Sunanda, you're still seeing this the wrong way. ATTEMPT never returns 
an error. the "error" you are talking about happens outside of ATTEMPT, 
so it can't guard against it.

Yes, Gabriele, that's how things are currently implemented.

The question is, should the error occur inside the attempt instead?

I think that RETURN, EXIT and BREAK, CONTINUE should be only available 
in their respective contexts (functions, and loops). CATCH/THROW 
will need special treatment. QUIT, Q, HALT can be left as is.

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

Brian claims that "most of the code we call in REBOL is non-local, 
meaning not directly nested in blocks". I on the other hand think 
that for the specific functions under consideration (RETURN, EXIT, 
BREAK, CONTINUE) this is mostly not the case.

Wherever "non-local code" is used in those cases, adjustments in 
binding of the non-local code will _already_ be made (i.e. for non-local 
code to be able to use the function arguments or the loop variable 
as if it was local code). This binding manipulation will have to 
be extended to also cater for the binding of control transfer functions.

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

---

This said, and leaving the discussion of improved semantics aside, 
I think that the implementation of improved error causation as described 
by Brian in bug#1506 would be very worthwile and should be pursued.

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).