🚀 go-pugleaf

In Article <4ba738$rpq@gaia.ns.utk.edu> Matthew B. Kennel writes:
>Scott Wheeler (scottw@bmtech.demon.co.uk) wrote:
>:...
>: The problem comes in doing it efficiently and cleanly. I'd approach 
it
>: by writing a pre-processor to generate C++ code from an extended
>: version of the language.
>
>: <example deleted>......
>
>That missed what I think is the most crucial (and yet simple) part of
>Eiffel-style conditions.Namely that a violated precondition points out 
>a mistake in the CALLER.Therefore, precondition faults should do 
>something obviously *different*
>from generalized assertion violations or invariant or postcondition
>faults.

Agreed. Up to this point, it is easy to amend the example by using a 
different macro based on "assert", but containing different text. Of 
course in existing implementations of C++ one has the source in 
assert.h.

>   If some random "assert" goes off, who's fault is that?  With
>C or C++ and the typical use of "assert" it's hard to say. Was it bad 
>input data?  Was it a mistake in the code?  Was it because somebody 
>else didn't implement the full functionality?  Or what?

We can rule out bad data by using a specialised version of assert, 
which will only be used in Eiffel-style invariants and pre- and 
post-conditions. However it's not obvious how to get a stack trace in 
the same way as the existing Eiffel implementations without compiler 
support. It could probably be done, but not efficiently. Any 
suggestions?

Scott