> If you have the process quit it definitely stops them from being false though.
The assertion remains false for the final process state, before the process quits. Outside of the process, the assertion is simply meaningless (neither true nor false), because the assertion's free variables are only bound inside the process.
>The assertion remains false for the final process state, before the process quits.
Which is inconsequential. Programmers don't expect automatic "recovery" from assertions, they expect them to notify them of the violated constraint, and/or to ensure that a program wont go on and use a value that violates an assertion further down -- which program termination achieves.
>Outside of the process, the assertion is simply meaningless (neither true nor false), because the assertion's free variables are only bound inside the process.
> He meant from being false subsequently in the program.
But, you see, the assertion is no less false just because the process was aborted. The fact remains that there exists a reachable state for which the assert fails. So apparently what I meant is no more obvious to you than it was for JonnieCache.
>But, you see, the assertion is no less false just because the process was aborted. The fact remains that there exists a reachable state for which the assert fails
Yes, Captain Obvious, and that reachable state is exactly what every programmer who uses an assert() statement expects when he writes it.
If there wasn't the potential for such a state, assert statements would do nothing ever in the first place -- so it would be kinda silly to even have them in.
The assertion remains false for the final process state, before the process quits. Outside of the process, the assertion is simply meaningless (neither true nor false), because the assertion's free variables are only bound inside the process.