World: r4wp

red>> do *
Error: feature not implemented yet!
bash-4.0#

I tried avoiding the error propagatin, but it's too complex, so it 
will stay as is until error! is implemeted.

The changes I made in the interpreter for not exiting the console 
on errors have a very bad side-effect: some errors are passing silently 
through the unit tests and are not reported! :-/

Hm, well, I suppose it's good practice for implementing error! ;-)

I can't on error! until next week, my planning is full.

<work>

This one has an assortment of effects:

red>> do [z:]
== 
*** Runtime Error 23: illegal operand
*** at: 09DB50F2h

I simply get an "*** Script error: action..." message here.

Again, in console-pro

red>> load x 
*** Error: word has no value!

*** Runtime Error 1: access violation
*** at: 08079DD7h

red>> load x/y
*** Error: word in path has no value!

*** Runtime Error 1: access violation
*** at: 08079DD7h

Kaj, I'm really don't see this approach working. The HALTs in the 
runtime code *do* have a purpose, they protect the user from running 
its code after an error that sets the stack in an undetermined state. 
It's a (temporary) protection barrier until we have proper error 
handling. Removing them will just make me chase false errors.  I 
can't patch the whole runtime code to make it look like it has error 
recovering while it has not...

I told you that the cleaner option would be: write a input data validation 
routine to, at least, catch those undefined words.

I think I'll put the HALT back to avoid making the runtime code unstable 
(and avoid those nasty silent errors in unit tests).

I have no idea what you're talking about. What approach? What HALTS? 
What input validation?

I'm just reporting crashes that I observe

Is there any point to continuing testing at the moment? I'm not sure 
now what reports you want

My point is: an undefined word error is a user error, and exiting 
the interpreter with an error message is currently the best thing 
to do. I've removed the exit points after such errors because you've 
asked me to for making your demos run without exiting. But I shouldn't 
have done that.

I don't really understand. The interpreter never halted on undefined 
words, only undefined paths

Same thing.

Paths error out because there's an undefined word in them.

I know, but you didn't remove a HALT from word evaluation because 
I asked

Well, actually, I did. :)

But I will them all back, user errors should make the app exit, currently 
it's the best way.

That's why I told you before to validate the user input in order 
to avoid errors as much as possible.

(Until we can catch them properly with TRY)

I don't remember you saying that, but I'm looking into it

But it seems we misunderstood each other. :)

Obviously

See my post on Sun 23:49

Oh, I see, you were going to implement VALUE? for validation. I just 
didn't think you meant checking the entire input; I thought you were 
talking about the result

I meant the whole user input, mainly for catching undefined words/paths 
and hanlding the error out of DO.

Maybe I will do it myself in the console script...

Thinking about it, that would reject any user code that uses words 
as symbols, wouldn't it?

I have a loop written that does the evaluation, even without VALUE? 
but it doesn't seem like a good idea to me

red>> x: load "view button" forall x [print unset? get x/1]      
     
false
true

Undefined single words were never a problem in the interpreter before. 
That's why I could write Redpages with a header:

Red []

They were simply ignored. After I requested the warning message, 
the Red word produces such a warning, so for now I write:

'Red []

By the way, are get-paths supposed to work?

Nope, not yet.

DO doesn't support a Red header yet.

You should strip it from a LOADed block before passing it to DO.

I know, but it worked

I need to fix some interpreter issues revealed by Peter's port of 
~2500 tests to the interpreter. There's about a dozen failing tests 
to fix.

Once that done, I will have a look again at those error reporting 
issues.

I agree that it is not yet possible to deeply validate user input. 
I'll see if I can find a cheap workaround for the release.

OK, thanks