World: r3wp

ok, it passes for me.

in R3, USE VARIABLES BODY is equivalent to LET VARIABLES NONE BODY, 
while in R2 USE VARIABLES BODY is equivalent to LET VARIABLES #[unset!] 
BODY

The BIND? function was added partly to deal with the security issues 
with R2's self. You can't as easily spoof BIND?.

on the question, why do we really need self:


self is very usefull when you use objects within code, because there 
can often be binding clashes.   self assures one that a parameter 
is always from the context and not from the function.

self.x: x


has occured pretty often for me.  its also very usefull when you 
need to return the context from which a function was bound.  
I also use it to do indirection: 

obj: self
context [
	parent: obj
]


remove self, and we can't say that REBOL has objects anymore.  many 
things will become really complicated for no reason.

Yes, I can understand, where the first one becomes handy, but it 
can be done easily in selfless contexts as follows:

[
    self: bind 'self
    ...
    self.x: x
]


The second one is actually more annoying having implicit self, than 
it would be otherwise:

[
   class- name: 'my-name
    context [
        parent: bind? class-name
    ]
]

sorry, I meant BIND? not BIND above

But, nevermind, take it just as a comparison...

yeah, but using bind is an inherently advanced use.  though like 
you, I understand that its just comparison.  


I'm in favor of 'SELF simply because I woudn't want REBOL code to 
become riddled with binds for such simple things. 


AFAIK bind doesn't scale well, in the sense that when you are playing 
around a lot with your code, bind will often become a point of failure, 
since the littlest change will quickly change what BIND does.

This is not BIND, just BIND?

(sorry again)

oooh... sorry I didn't see that nuance (my fault) ... I didn't even 
realize we had bind? in R3.   hum.  this opens up many doors.  I 
think my mind mistook every use of BIND? as a  call to  [ not not 
BIND? word].  

(like   found?  vs  find)

Same here...  BINDING? would work better, although longer

There was a long discussion about it a few years ago. I think it 
used to be BOUND? but that implies a LOGIC! result

I'd have gone with BINDING? too

Yeah. But it is still used in logic contexts, which is why BIND? 
returns true for function bindings.

(true or false, false meaning in fact the same as true, with a distinction, 
that the function is not running)

>> bind? do has [a] ['a]
== true
Nope, still bound.

isn't this a recent change?

Yeah, only a few years or so old.

It's to allow words bound to function contexts to be used in the 
same conditional statements that words bound to regular contexts 
can be. For those occasions when BIND? means BOUND? rather than BINDING?.

That is OK, I just thought, that I saw false as a result of BIND?

If you can replicate that, let us know in a CC ticket.

seems I am unable to replicate it now, so it might be an issue that 
is already corrected

If so, cool. Keep us aprised.

>> w: has [a] ['a]
>> get/any w
** Script error: a word is not bound to a context
** Where: get
** Near: get/any w

>> get/any unbind 'a
** Script error: a word is not bound to a context
** Where: get
** Near: get/any unbind 'a


A question: wouldn't it be better to have an "out of scope" error 
instead?

Probably so. Request it.

A more direct way to cause a basic error might be very useful. Currently, 
if you don't want/need to give any thought what an appropriate error 
might be you'll do:

    cause-error 'user 'message "error message"


Which is a lot longer than `make error! "error message"` was in R2. 
Having written the above in R3 a lot, recently, I now use a CAUSE-USER-ERROR 
shorthand, which might be nice to have in general:

    cause-user-error "error message"

(Of course, when you don't care about the error message at all, there 
is another simple way:

    assert [false "error message"]

Depending on your needs, that might be sufficient or even better. 
Here's how those two errors are presented:

>> cause-error 'user 'message "foo"
** user error: "foo"

>> assert [false "foo"]
** Script error: assertion failed for: [false "foo"]
** Where: assert
** Near: assert [false "foo"]

You can still do this in R3: do make error! "error message"

The only difference from R2 is that you have to DO the error to trigger 
it.

Nice trick on the ASSERT message - I'm going to have to remrmber 
that one :)

I would like to see some support for automatic logging of events.


Rebol currently has two "hooks" to allow "Front-end" code to execute 
automatically in the REBOL.r and USER.r files.

I would like to see another "hook" to allow "Back-end" code to execute 
automatically whenever Rebol stops its current evaluations for any 
reason such as encountering the HALT, QUIT, or any error which causes 
Rebol to stop evaluation.  


This could allow for some kind of automatic logging of  QUIT, HALT 
or ERROR as well as capturing the error messages.  It would be nice 
to allow capturing of any other information such as the script name, 
computer name, current timestamp, and where in the script the evaluation 
stopped, and how it stopped.


I would use this to log all of my scripts that is invoked (put the 
code in REBOL.r file) and then the termination conditions defined 
so they could be triggered automatically.  With such a function, 
I could even have certain selected scripts send an automatic SMS 
messages to my phone if certain scripts errored out etc.



I'd like to propose a new function called WHEN that can be used to 
trigger code at a terminating event.

WHEN  block  /all

For any specified terminating condition, evaluates what follows it.

Arguments:

block [block!] - Block of terminating events (conditions followed 
by values)
Refinements:

/all - Evaluate all terminating conditions (do not stop at first 
true terminating condition)


The WHEN command would be used to define code to be evaluated whenever 
a termination condition of any kind occurred in which continued evaluation 
will stop.

Examples:
WHEN/ALL [

 HALT?	[ print "This script will HALT now" ]  ; code to be evaluated 
 before the HALT is evaluated

 QUIT?	[ print "This script will QUIT now" ]   ; code to evaluate 
 befoe the QUIT is evaluated 

 ERR?	[ print "An error was discovered"  ]   ;code to evaluate after 
 an error is captured, but before the message is printed
	END?	[
		  print "Script about to end"
		  if  now/time  >  23:00:00  print "Stopped after 11 pm"

  ]                                                              ; 
   code to evaluate whenever the current evaluation has stopped for 
  any reason
	]


Note:  HALT?, QUIT?, ERR?, END? are all logic values which become 
true depending upon how evaluations will be stopped.

END? will always be true and one of the other terminating conditions 
will always be true.

What do you think?

The WHEN functions is modled on the CASE function, but with terminating 
conditions defined instead of any conditions

Sounds like a great idea, except the function name.

yep, I already use it for other purposes :-)

something like  INCIDENTAL more suited

incidental thought

Perhaps something related to the timing of the event. The code specified 
here would only be able to be executed at the end of the interpreter 
process - intercepting a QUIT or HALT is a tricky business. Perhaps 
FINALLY would be a better name.

Would TERMINATION be a good name as well.  


I would imagine that Rebol would have a common exit point (a place 
in the executable where all terminations go) before control is handed 
off to the OS.  If that is so, then the suggested code could be placed 
there, which should simplify intercepting QUIT or HALT.  To be more 
consistant, I'd like to amend my ERR? proposal to be "code to be 
evaluated after an error is captured and printed" instead of before 
being printed.

The only thing that cannot be intercepted is when the OS itself closes 
rebol for any reason.  An example would be a user clicking on the 
[X] box to close the window.  Although it would be great to have 
a CLOSE? termination condition, I certainly understand that Rebol 
would not be able to intercept that.  Now that I think about it, 
the only way that Rebol could intercept a CLOSE? condition is if 
the window panel itself is under Rebol control through the GUI -- 
but even then, that may be a difficult proposal to implement.

WHENEVER is also a suggested name.

No, because it isn't whenever, it has to be at a particular time. 
Termination is good.

It isn't difficult for Rebol to intercept the window close event. 
Carl Sassenrath was asking recently (within a few months ago, I think) 
about whether to   allow interception of this event.

it could intercept other events as well imho: http://www.codeproject.com/KB/system/OSEvents.aspx

>> length? 4

** Script error: length? does not allow integer! for its series argument


I am proposing that this return NONE for any type which it can't 
deduce a length.


this is both usefull in practice and would make length? a truthy 
function.

Hmm,  I respect that you find it useful, but what if other users 
(like me) find it unuseful?

this is the easiest way to know if a data element can be traversed 
via pick without having to first know if the datatype can be traversed.


the issue is that many types have indexed content but are not series 
(i.e. no "current" index).  so we can get the value or deny listing 
in one function call.

ex:

print-tree: funct  [data][
	i: 0
	either len: length? :data [
		repeat i len [print-tree pick :data i]
	][
		print mold/all :data
	]
]

this doesn't break any code, except if one relies on error handling 
to detect if data has length

and if your code doesn't handle the none case it will still raise 
an error, so you aren't even really breaking that capability.

Aha, interesting, and what if we just defined properly a dataset 
like:

    pickable!: make dataset! [series! ...]