Dear Robert,
instead of adding a *fatal-condition-exceptions*, I would much rather you use (and serious-condition #+clozure (not ccl:process-reset)) or something like that. You may have to add a case to match-condition-p to support lists as condition type specifiers.
This probably applies to the other handler-bind places where you catch serious-condition, too. git grep serious-condition is your friend.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Necessity is the plea for every infringement of human freedom. It is the argument of tyrants; it is the creed of slaves. — William Pitt, 1783
On 7/28/16 Jul 28 -8:24 AM, Faré wrote:
Dear Robert,
instead of adding a *fatal-condition-exceptions*, I would much rather you use (and serious-condition #+clozure (not ccl:process-reset)) or something like that. You may have to add a case to match-condition-p to support lists as condition type specifiers.
This probably applies to the other handler-bind places where you catch serious-condition, too. git grep serious-condition is your friend.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Necessity is the plea for every infringement of human freedom. It is the argument of tyrants; it is the creed of slaves. — William Pitt, 1783
Thank you, Faré. This is an obvious improvement.
Question: shouldn't I add this as
(deftype FATAL-CONDITION ...)
and try to use that everywhere, instead of writing duplicate code everywhere? That would also solve the "lists in match-condition-p" problem.
I think the CCL folks agree that it was a mistake to make PROCESS-RESET a SERIOUS-CONDITION, but we have to live with it.
Best, r
On Thu, Jul 28, 2016 at 5:08 PM, Robert P. Goldman rpgoldman@sift.info wrote:
Question: shouldn't I add this as
(deftype FATAL-CONDITION ...)
and try to use that everywhere, instead of writing duplicate code everywhere? That would also solve the "lists in match-condition-p" problem.
Indeed, that's an even better factorization.
I think the CCL folks agree that it was a mistake to make PROCESS-RESET a SERIOUS-CONDITION, but we have to live with it.
Yes. That's a good reason to export fatal-condition from uiop/image, since it's a generally useful abstraction perfectly fit for the purposes of uiop.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org To explain the unknown by the known is a logical procedure; to explain the known by the unknown is a form of theological lunacy. — David Brooks, "The Necessity of Atheism"
On 7/28/16 Jul 28 -10:47 PM, Faré wrote:
On Thu, Jul 28, 2016 at 5:08 PM, Robert P. Goldman rpgoldman@sift.info wrote:
Question: shouldn't I add this as
(deftype FATAL-CONDITION ...)
and try to use that everywhere, instead of writing duplicate code everywhere? That would also solve the "lists in match-condition-p" problem.
Indeed, that's an even better factorization.
I think the CCL folks agree that it was a mistake to make PROCESS-RESET a SERIOUS-CONDITION, but we have to live with it.
Yes. That's a good reason to export fatal-condition from uiop/image, since it's a generally useful abstraction perfectly fit for the purposes of uiop.
Hmmmm..... Actually, SERIOUS-CONDITION, as I read its documentation, is exactly the right abstraction -- it's just that CCL has broken it:
"All conditions serious enough to require interactive intervention..."
I don't want to export a new concept that is "Like SERIOUS-CONDITION, except patched for an implementation."
I'll fix this internal to ASDF and leave it at that. Some day I hope that FATAL-CONDITION will wither away.
Best, r
On Fri, Jul 29, 2016 at 9:41 AM, Robert P. Goldman rpgoldman@sift.info wrote:
On 7/28/16 Jul 28 -10:47 PM, Faré wrote:
On Thu, Jul 28, 2016 at 5:08 PM, Robert P. Goldman rpgoldman@sift.info wrote:
Hmmmm..... Actually, SERIOUS-CONDITION, as I read its documentation, is exactly the right abstraction -- it's just that CCL has broken it:
"All conditions serious enough to require interactive intervention..."
I don't want to export a new concept that is "Like SERIOUS-CONDITION, except patched for an implementation."
I'll fix this internal to ASDF and leave it at that. Some day I hope that FATAL-CONDITION will wither away.
By that token, all of UIOP would be private, hoping that someday the CL standard would fix pathnames, etc.
The whole point of UIOP is to provide ASDF and other CL programs with portability abstractions that actually work in the current CL landscape. Not to pretend that that CL landscape magically matches some imagined ideal when that isn't the case.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org We are always in anarchy. But we pay a hefty price maintaining the illusion that we aren't, and another one being misled by the illusion.
On 7/31/16 Jul 31 -6:12 PM, Faré wrote:
On Fri, Jul 29, 2016 at 9:41 AM, Robert P. Goldman rpgoldman@sift.info wrote:
On 7/28/16 Jul 28 -10:47 PM, Faré wrote:
On Thu, Jul 28, 2016 at 5:08 PM, Robert P. Goldman rpgoldman@sift.info wrote:
Hmmmm..... Actually, SERIOUS-CONDITION, as I read its documentation, is exactly the right abstraction -- it's just that CCL has broken it:
"All conditions serious enough to require interactive intervention..."
I don't want to export a new concept that is "Like SERIOUS-CONDITION, except patched for an implementation."
I'll fix this internal to ASDF and leave it at that. Some day I hope that FATAL-CONDITION will wither away.
By that token, all of UIOP would be private, hoping that someday the CL standard would fix pathnames, etc.
The whole point of UIOP is to provide ASDF and other CL programs with portability abstractions that actually work in the current CL landscape. Not to pretend that that CL landscape magically matches some imagined ideal when that isn't the case.
I think that's a stretch in this one case -- all the implementations agree on CL:SERIOUS-CONDITION, with the exception of CCL, and I believe they agree that they have simply made a mistake in their implementation.
I'm reluctant to build into UIOP a new type definition whose description exactly parallels the definition of SERIOUS-CONDITION in the spec.
Until now we have limited ASDF and UIOP to plugging holes in the spec (like the absence of good enough pathname support). We haven't been also adding a shadow implementation of the spec for cases where the implementations simply got it wrong. That feels like mission-creep to me.
The closest I'd be willing to go is to remove UIOP:*FATAL-CONDITIONS* and replace it with a type definition for UIOP:FATAL-CONDITION. But even that makes me feel bad. I guess we can keep this for now, but I'll be a lot happier when it's simply an alias for CL:SERIOUS-CONDITION.
Best, R
On Sun, Jul 31, 2016 at 9:52 PM, Robert P. Goldman rpgoldman@sift.info wrote:
On 7/31/16 Jul 31 -6:12 PM, Faré wrote:
The whole point of UIOP is to provide ASDF and other CL programs with portability abstractions that actually work in the current CL landscape. Not to pretend that that CL landscape magically matches some imagined ideal when that isn't the case.
I think that's a stretch in this one case -- all the implementations agree on CL:SERIOUS-CONDITION, with the exception of CCL, and I believe they agree that they have simply made a mistake in their implementation.
I'm reluctant to build into UIOP a new type definition whose description exactly parallels the definition of SERIOUS-CONDITION in the spec.
If *that* is your interpretation, then my reply is then that uiop/common-lisp should shadow SERIOUS-CONDITION and export its version that is (and cl:serious-condition (not ccl::process-reset)) or some such.
All UIOP and ASDF packages :mix uiop/common-lisp (which unlike other UIOP packages is NOT reexported by UIOP itself -- you have to explicitly :use it instead of :common-lisp if you want).
Until now we have limited ASDF and UIOP to plugging holes in the spec (like the absence of good enough pathname support). We haven't been also adding a shadow implementation of the spec for cases where the implementations simply got it wrong. That feels like mission-creep to me.
Oh yes we have been adding these shadow implementations: it's uiop/common-lisp.
The closest I'd be willing to go is to remove UIOP:*FATAL-CONDITIONS* and replace it with a type definition for UIOP:FATAL-CONDITION. But even that makes me feel bad. I guess we can keep this for now, but I'll be a lot happier when it's simply an alias for CL:SERIOUS-CONDITION.
I believe I added UIOP:*FATAL-CONDITIONS* so that users could customize the use of WITH-FATAL-CONDITION-HANDLER. I believe it's useful.
But please remove *fatal-condition-exceptions*.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org To have a right to do a thing is not at all the same as to be right in doing it. — G.K. Chesterton
On 7/31/16 Jul 31 -9:06 PM, Faré wrote:
The closest I'd be willing to go is to remove UIOP:*FATAL-CONDITIONS*
and replace it with a type definition for UIOP:FATAL-CONDITION. But even that makes me feel bad. I guess we can keep this for now, but I'll be a lot happier when it's simply an alias for CL:SERIOUS-CONDITION.
I believe I added UIOP:*FATAL-CONDITIONS* so that users could customize the use of WITH-FATAL-CONDITION-HANDLER. I believe it's useful.
But please remove *fatal-condition-exceptions*.
I have kept WITH-FATAL-CONDITION-HANDLER, but removed UIOP:*FATAL-CONDITIONS*.
I simplified W-F-C-H to be simply a handler for UIOP:FATAL-CONDITION, since we don't need to have a list-valued UIOP:*FATAL-CONDITIONS* -- we can simply define UIOP:FATAL-CONDITION with OR.
I'm running the tests now, and will then commit a proposed new version. I'll send out an email when it's done, and you can review it and let me know what you think, ok?
I think it's best for you to have a clear proposal to review, instead of just a description thereof. I look forward to hearing what you think.
Best, r
New candidate fix is available for review and testing as 3.1.7.5
Now we have the TYPE UIOP:FATAL-CONDITION, instead of UIOP:*FATAL-CONDITIONS*.
I was wishy-washy and kept (FATAL-CONDITION-P c) as an alias for (TYPEP C 'UIOP:FATAL-CONDITION).
I go back and forth on whether FATAL-CONDITION-P should go if we keep this refactoring. CL has both (TYPEP <foo> 'STRUCT-TYPE) and (STRUCT-TYPE-P <foo>) so there's precedent for redundancy here, and it is one less breaking backwards incompatibility.
best, r
-
Faré -
Robert Goldman -
Robert P. Goldman