Avoid Raised Errors in PACK! (But Feel The Power!)

[hostilefork]

@hostilefork

Honestly this seems wrong. I allow you to PACK a PACK, and that's okay. But glossing over the error at time of packing I do not like.

I much prefer:

>> pack [take block, 10 + 20]
** Script Error: Can't TAKE, no value available (consider TRY TAKE)

@hostilefork

So Forget About Raised Errors in PACK!

It's a terrible idea. I'm making PACK abrupt fail if you try to put a raised error in it.

Well, hmmm.

I still believe that PACK should not just assume a definitional error is intentional by default.

However, it seems to me that in practice, not allowing you to put raised errors in packs at all creates stifling situations where you have to add refinements to every function that wants to speak generically about raised errors, to make them speak in META-protocols e.g. EVAL/ENTRAP

So I'm adding PACK* which can be used in cases where it is warranted, and it will put raised errors in. But I suggest trying to avoid it, unless you are writing a truly general routine along the lines of EVAL. I've shown above that there's usually other ways to attack the problem.