Stephan Rudlof wrote:

> #sqAssert: is a workaround:
> We already have this nice ST #assert:, and I'd be happy to be allowed to use
> the same name for a C assert() with a related semantics.
> And it annoys me to be forced to avoid this name just since there is some
> platform specific include problem.
Well I have some sympathy with the attitude but I rather suspect it
would be lot simpler to roll over and just put up with having a
different name. Think of it as jujitsu programming, skilfully avoiding a
problem by moving slickly to one side of the monster.


> This gives me an idea: we already have #primitiveFailed and could possibly
> define #assert: to use it instead of a hardcore abort() (together with some
> logging stating than an assert has failed). What do you think about this?
Yes we could certainly do something like that. I'd suggest a form of
assert that can cleanly return a defined failure notification as well as
one that can do the "argh! I'm dead!" sort of failure.

I think a simple primitiveFail is a bit lacking in information content.
It is a simple matter to extend it to set a defined temp variable in the
calling context to some object that provides more info. We used a form
of this for the Interval project and it allows one to quickly owrk out
why the prim failed. BitBLT could use it to specify _which_ coordinate
was innapropriate, or which Form was invalid. A file prim could return a
sensible reason for why your attempt to open a file failed (file not
there? permissions? bad breath?). 

It has been argued that one could do this by having a get-last-error
prim and copy the errno() idea form unix. This is a poor idea for two
reasons:- copying a dumb idea from a daft OS is not sensible and unless
you propose to put some form of critical block around every prim call
you could not trust that the result of a separate prim has anything to
do with the one that failed.

The code changes to enable this are very simple but (unless one wants to
put tedious guard code around the place) it does have something of a
Heaviside function about it - an image expecting it can run on an older
vm, but an updated vm would crash an older image. It might be a good
thing to include in the list of image-format-breaking changes alongside
new compiled method format, blocks etc etc.

tim