World: r3wp

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! ...]

we still need to add an extra if before the length? all the time.


its funny because the recent discussion on naming and *? words has 
made me realize that the length? and many others could in fact be 
altered to support this idiom if its done consistently.

we have two questions answered in one function.  using if/either/unless 
allows to filter based on capacity and the result allows us to act 
on the actual value.

another example, but this time applied to the index? function.
		
get-item: func [data][
	either i: index? data [
		pick data i
	][data]
]


note that this can be done differently, but I think this is the easiest 
to read because its almost like an algorithm.


i.e. "if this has an index, get its item at that index, otherwise 
just return the value."

it also prevents us from having to create sets of predefined filters 
which will:

    -be unknown and forgotten quickly (e.g. more things to remember, 
    bad)

    -might only really be usable by a very few functions to begin with. 
    (not very usefull)


(this relates to the alternative that ladislav pointed, using a dataset)

changing many of these functions would make them satisfy the *proposed* 
style convention that *? functions should be truthy, if possible. 
  


in many cases, this is the case, because there is no "possible" none 
return value and errors are returned instead.

we still need to add an extra if before the length? all the time.

 ... actually you would just move the IF to the native part and you 
 will use the IF also in cases where you are pretty sure it's a series 
 and want just its length.

not sure I undestand what you mean   ' :-/

never mind.. I'm wrong.. the condition must be in the native anyway 
so it's fine just to return none.

sorry.. I'm babysitting here.. should first think some time before 
I write.

hehe... nah just say the kid/baby took over the keyboard  ;-)

unless its a cat!

On one hand, I like the idea that a none LENGTH? means "this value 
has no length", on the other the idea of a pickable! typset (maybe 
a different name though) gives us the ability to use it in func specs 
and such.

I'm not ready to say change LENGTH? without further thought.

Max, your plan is unrealistic

note, that this proposal is strictly related to functions which have 
an '? at the end.  


if we go ahead with changes to the style convention which clearly 
define what a "truthy" function is and state that ****? is generally 
used to define such a function, I think that we could clean up a 
lot of the guess work in how to handle this often recurring case.

in what sense is it unrealistic?

e.g.:

a: make object! [a1: 1]
length? a
pick a 1

, etc....

well, if an object has a length? why can't I pick it?  that is the 
error IMHO.  though this is not the debate I want to start ;-)

You already did

There are many such cases you don't like

obviously not all cases will fit perfectly.  and the above was just 
one (simple) example, where you can get 95% of the work done in one 
line and then tailor the few special cases after.

Maxim <If an object has length, why can't I pick it?>
Maybe they are like SQL tables.....
A table has a length, so this is valid

   select count(*) from ....   -- to get the length of the table (ie 
   number of rows)

But, in the absence of an ORDER BY the rows do not have a user-accessible 
sequence, so

  select first from ....   -- is not valid syntax, nor (without an 
  ORDER BY) is it even meaningful

(Sorry, I know you did not want that debate)

btw the fact that pick can't use objects isn't related in any way 
to what length? can or cannot do.


I just gave an example to *illustrate* how clean it is to use thruty 
returns in real code.

whatever the algorithm or functions we use we will always have to 
handle the special cases (like 0 in maths)

The fact, that the code actually cannot be used means, that your 
idea is not supported by a real usage example, and is not completely 
thought-out.

Taking into account, that the disadvantages of the change are real, 
while the advantages are just virtual, it is hard for me to support 
it.

Lad you are well placed to know that iterating over ANY random data 
list in ERBOL will require special cases in EVERY single algorythm 
you can think of.  every datatype has its own idiosyncracies.  


in a way, this is the point of datatypes in REBOL. They aren't generic. 
 so I don't expect them to behave so in the first place.

give me your perceived disadvantages.  I've been pulling my own weight, 
but I'm not seeing alot of points related to LENGTH? and other such 
funcs...  I'm not talking about a specific function chain.

Generally, it looks, that REBOL is headed towards "less error triggering" 
approach, and I don't feel any of the changes as a problem, so, you 
may be right. But, there should be some limits, where to stop. One 
of my limits is the usage of NaNs in REBOL, I prefer clean errors 
triggered to NaN dissemination. So, in that case, I know where my 
preferred boundary is. In case of LENGTH? and INDEX? function, I 
am not totally sure, but I am sure, that any change to the existing 
state is expensive (postponing the release, taking resources needed 
to solve more important problems, ...) So, I would support such a 
change only when I would get really convincing arguments.

yes, in such a sense (expensive change), I understand.  


I will wait for brian to step up and get his opinion.  I know we've 
spoken about this somewhat before, but not as head-on, for myself... 
 With the recent talk about naming, IMHO it has put a new light on 
the possibility for this to be a bit more appreciated, adding ? at 
the end would now mean something concrete.


let it be known that I do like errors, I am not against errors, I 
have been putting less and less error recovery in my code to make 
sure it crashes and I fix bugs early.


its just that I can see many if not most ****? functions (my own 
included) being truthy and this is very usefull to facilitate  control 
flow.  This, as oposed to always putting error handlers in places 
where the error is only used as a negative reply, for which we can 
supply, IMHO, a reasonable value/standard.