Here are a couple changes to ASDF that I made in the process of creating an ASDF browser for CCL's IDE:
• system-source-file now works for systems without their own .asd • optional parts of systems (version, maintainer, etc.) don't leave their slots unbound
Greg Pfeil wrote:
Here are a couple changes to ASDF that I made in the process of creating an ASDF browser for CCL's IDE:
• system-source-file now works for systems without their own .asd • optional parts of systems (version, maintainer, etc.) don't leave their slots unbound
The first of these looks good, but I'm less fond of the second change. I've been bitten repeatedly by bugs caused by initforms that caused slots not explicitly set to have some value that hides a mistaken failure to fill the slot.
I'd rather have us handle slot-unbound on those optional parts of the system instead of stuffing a bunch of NILs in there.
If one is expecting strings here one must still handle checking for NIL, so having to check for slot-boundp doesn't seem that much more onerous.
On a related topic, I'd be inclined, more for documentation than efficiency, to stick :type string on a bunch of these. Of course, if I'm wrong about the above, this would have to be (or null string)....
best, R
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 9 Jul 2009, at 13:08, Robert Goldman wrote:
Greg Pfeil wrote:
Here are a couple changes to ASDF that I made in the process of creating an ASDF browser for CCL's IDE:
∙ system-source-file now works for systems without their own .asd ∙ optional parts of systems (version, maintainer, etc.) don't leave their slots unbound
The first of these looks good, but I'm less fond of the second change. I've been bitten repeatedly by bugs caused by initforms that caused slots not explicitly set to have some value that hides a mistaken failure to fill the slot.
Yeah, I should have sent these as separate patches. The first one is more important, IMO, and the second is definitely debatable.
I'd rather have us handle slot-unbound on those optional parts of the system instead of stuffing a bunch of NILs in there.
When you say "us", do you mean implementing the accessors explicitly in ASDF to handle the condition, or having the caller handle/avoid the condition?
If one is expecting strings here one must still handle checking for NIL, so having to check for slot-boundp doesn't seem that much more onerous.
Checking slot-boundp has a number of problems:
∙ you have to export the slot names ∙ it breaks the accessor abstraction because the slot names don't match the accessor names (when (slot-boundp foo 'asdf::description) (system-description foo)) ∙ it breaks the accessor abstraction again because not everything that follows the accessor pattern has a slot (when (slot-boundp foo 'asdf::pathname) (component-pathname foo))
The default value could just as well be "" as NIL. I chose NIL because you can kind of distinguish a system explicitly having "" as the value versus the case where the slot isn't set. If the distinction isn't worthwhile (which it probably isn't in this case, "" may be just as good.
On a related topic, I'd be inclined, more for documentation than efficiency, to stick :type string on a bunch of these. Of course, if I'm wrong about the above, this would have to be (or null string)....
Or use "" as the default.
Again, this is much less important to me than the system-source-file change (well, other than the fact that I'm loath to use non-exported symbols in CCL), so if that could be committed separately, I'd appreciate it. I'm happy to send a new diff with only those changes if that would help.
Greg Pfeil wrote:
On 9 Jul 2009, at 13:08, Robert Goldman wrote:
Greg Pfeil wrote:
Here are a couple changes to ASDF that I made in the process of creating an ASDF browser for CCL's IDE:
system-source-file now works for systems without their own .asd optional parts of systems (version, maintainer, etc.) don't leave their slots unbound
The first of these looks good, but I'm less fond of the second change. I've been bitten repeatedly by bugs caused by initforms that caused slots not explicitly set to have some value that hides a mistaken failure to fill the slot.
Yeah, I should have sent these as separate patches. The first one is more important, IMO, and the second is definitely debatable.
How about sending that first patch while we work through the second issue. Even if we add the initforms, seems like it's still worth discussing the tradeoff b/w "" and NIL as defaults. I'd be inclined to prefer the latter, even at the expense of :type (or null string), so that an unsupplied value is readily distinguishable from an empty value.
The argument for slot-unbound is that it makes an error when you think you have set a slot, but you haven't. For example, let's say I misspell an initarg so that the value quietly vanishes. Then I'd rather the system hurl an error instead of quietly going off and doing something I don't expect.
I'd rather have us handle slot-unbound on those optional parts of the system instead of stuffing a bunch of NILs in there.
When you say "us", do you mean implementing the accessors explicitly in ASDF to handle the condition, or having the caller handle/avoid the condition?
The latter.
If one is expecting strings here one must still handle checking for NIL, so having to check for slot-boundp doesn't seem that much more onerous.
Checking slot-boundp has a number of problems:
you have to export the slot names
Is this really an issue? Would someone outside the ASDF package really be looking into these things? I suppose possibly so...
it breaks the accessor abstraction because the slot names don't match the accessor names (when (slot-boundp foo 'asdf::description) (system-description foo))
(handler-case .... (slot-unbound () ...)
avoids this problem, if you know that you want to quash unbound slots.
it breaks the accessor abstraction again because not everything that follows the accessor pattern has a slot (when (slot-boundp foo 'asdf::pathname) (component-pathname foo))
See above. If you just handle that error, then you don't need access to the slot names.
The default value could just as well be "" as NIL. I chose NIL because you can kind of distinguish a system explicitly having "" as the value versus the case where the slot isn't set. If the distinction isn't worthwhile (which it probably isn't in this case, "" may be just as good.
It's possible that these slots are optional enough that I'm being over-cautious here. As I said, this is a reaction born of hard to find bugs, probably mostly on attributes more important than these.
If it were easier to catch this kind of error when the system is defined, that would be better, and the initforms would be benign.
So I'd suggest either:
1. We reject my concern, add NIL initforms, and add (or null string) type declarations (as documentation, more than anything else).
2. We could leave the slots unbound, or default to nil, and add accessors that use the (<accessor> object &optional error-p) pattern so that people who expect these slots to be set can see errors.
Best, r
On 12 Jul 2009, at 11:17, Robert Goldman wrote:
Greg Pfeil wrote:
On 9 Jul 2009, at 13:08, Robert Goldman wrote:
Greg Pfeil wrote:
Here are a couple changes to ASDF that I made in the process of creating an ASDF browser for CCL's IDE:
system-source-file now works for systems without their own .asd optional parts of systems (version, maintainer, etc.) don't leave their slots unbound
The first of these looks good, but I'm less fond of the second change. I've been bitten repeatedly by bugs caused by initforms that caused slots not explicitly set to have some value that hides a mistaken failure to fill the slot.
Yeah, I should have sent these as separate patches. The first one is more important, IMO, and the second is definitely debatable.
How about sending that first patch while we work through the second issue. Even if we add the initforms, seems like it's still worth discussing the tradeoff b/w "" and NIL as defaults. I'd be inclined to prefer the latter, even at the expense of :type (or null string), so that an unsupplied value is readily distinguishable from an empty value.
Here's the system-source-file patch.
The argument for slot-unbound is that it makes an error when you think you have set a slot, but you haven't. For example, let's say I misspell an initarg so that the value quietly vanishes. Then I'd rather the system hurl an error instead of quietly going off and doing something I don't expect.
I'd rather have us handle slot-unbound on those optional parts of the system instead of stuffing a bunch of NILs in there.
When you say "us", do you mean implementing the accessors explicitly in ASDF to handle the condition, or having the caller handle/avoid the condition?
The latter.
If one is expecting strings here one must still handle checking for NIL, so having to check for slot-boundp doesn't seem that much more onerous.
Checking slot-boundp has a number of problems:
you have to export the slot names
Is this really an issue? Would someone outside the ASDF package really be looking into these things? I suppose possibly so...
it breaks the accessor abstraction because the slot names don't match the accessor names (when (slot-boundp foo 'asdf::description) (system-description foo))
(handler-case .... (slot-unbound () ...)
avoids this problem, if you know that you want to quash unbound slots.
You know, I considered this, but quickly dismissed it as too verbose. However, while
(handler-case (system-description foo) (slot-unbound () ""))
is worse than the
(or (system-description foo) "")
that I wanted, it's still better than the
(when (slot-boundp foo 'asdf::description) (system-description foo))
I was afraid of. I'm happy to use that pattern.
I'd still prefer optional values to not signal slot-unbound, but I understand the tradeoff with catching errors in initforms, etc.
I sent this patch a while ago, but from a different address. It was held for moderation, but I don't know if it was ever received, as it hasn't been applied yet.
Begin forwarded message:
From: Greg Pfeil greg@technomadic.org Date: 12 July 2009 13:33:08 EDT To: Greg Pfeil greg@clozure.com Cc: Robert Goldman rpgoldman@sift.info, asdf-devel@common-lisp.net Subject: Re: [asdf-devel] patch system-source-file
On 12 Jul 2009, at 13:11, Greg Pfeil wrote:
Here's the system-source-file patch.
<system-source-file.diff>
Whoops, that patch is wrong. Here's the correct one:
Hi Greg.
I just found your patch in the mailing list limbo (and apologize for the delay in processing).
I'm planning on some ASDF hacking over the next several days.
Thanks for the patch.
On Jul 12, 2009, at 1:33 PM, Greg Pfeil wrote:
On 12 Jul 2009, at 13:11, Greg Pfeil wrote:
Here's the system-source-file patch.
<system-source-file.diff>
Whoops, that patch is wrong. Here's the correct one:
<system-source-file.diff> _______________________________________________ asdf-devel mailing list asdf-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
-- Gary Warren King, metabang.com Cell: (413) 559 8738 Fax: (206) 338-4052 gwkkwg on Skype * garethsan on AIM * gwking on twitter
Greg Pfeil wrote:
On 12 Jul 2009, at 11:17, Robert Goldman wrote:
Greg Pfeil wrote:
On 9 Jul 2009, at 13:08, Robert Goldman wrote:
Greg Pfeil wrote:
Here are a couple changes to ASDF that I made in the process of creating an ASDF browser for CCL's IDE:
system-source-file now works for systems without their own .asd optional parts of systems (version, maintainer, etc.) don't leave their slots unbound
The first of these looks good, but I'm less fond of the second change. I've been bitten repeatedly by bugs caused by initforms that caused slots not explicitly set to have some value that hides a mistaken failure to fill the slot.
Yeah, I should have sent these as separate patches. The first one is more important, IMO, and the second is definitely debatable.
How about sending that first patch while we work through the second issue. Even if we add the initforms, seems like it's still worth discussing the tradeoff b/w "" and NIL as defaults. I'd be inclined to prefer the latter, even at the expense of :type (or null string), so that an unsupplied value is readily distinguishable from an empty value.
Here's the system-source-file patch.
The argument for slot-unbound is that it makes an error when you think you have set a slot, but you haven't. For example, let's say I misspell an initarg so that the value quietly vanishes. Then I'd rather the system hurl an error instead of quietly going off and doing something I don't expect.
I'd rather have us handle slot-unbound on those optional parts of the system instead of stuffing a bunch of NILs in there.
When you say "us", do you mean implementing the accessors explicitly in ASDF to handle the condition, or having the caller handle/avoid the condition?
The latter.
If one is expecting strings here one must still handle checking for NIL, so having to check for slot-boundp doesn't seem that much more onerous.
Checking slot-boundp has a number of problems:
you have to export the slot names
Is this really an issue? Would someone outside the ASDF package really be looking into these things? I suppose possibly so...
it breaks the accessor abstraction because the slot names don't match the accessor names (when (slot-boundp foo 'asdf::description) (system-description foo))
(handler-case .... (slot-unbound () ...)
avoids this problem, if you know that you want to quash unbound slots.
You know, I considered this, but quickly dismissed it as too verbose. However, while
(handler-case (system-description foo) (slot-unbound () ""))is worse than the
(or (system-description foo) "")that I wanted, it's still better than the
(when (slot-boundp foo 'asdf::description) (system-description foo))I was afraid of. I'm happy to use that pattern.
I'd still prefer optional values to not signal slot-unbound, but I understand the tradeoff with catching errors in initforms, etc.
I take your point. My earlier suggestion was to offer, e.g.,
(component-version component &optional error-p)
However, it occurs to me that this would foil uses of WITH-ACCESSORS, so is quite likely undesirable. :-(
I am coming around to a modified version of your PoV: have default values, let them be NIL, and add :type (or null string) to the relevant slots. Then NIL is a quasi-exception, and readily distinguishable from "", which would be reserved for an explicitly-supplied empty value as opposed to an implicitly-supplied default value.
Ideally, we could catch bad initializations at initialization time, but that objective is foiled by the quite important objective of extensibility, which seems to force &allow-other-keys upon us.
[BTW, Greg, I get a signature verification failure on that email. Not sure why.]
Best, r
hello;
i am not sure, exactly to which message to reply - i suspect i'm missing parts of the thread. in any case,
1. when dealing with a large system, latent unbound slots are insidious. an initialization protocol should either provide a default value which is within the class contract, or it should signal an exception - most likely an error. that is, in the minimal form, either the slot should be defined as
(slot :initarg :slot :initform (error "SLOT required."))
or initialize instance should be specialized to effect
(defmethod initialize-instance (instance &key (slot (error "SLOT required."))) (call-next-method))
in which latter case there can be logic for the use case where a presence constraint applies to some combination(s) of a set of slots.
absent such guards, the slot-unbound error will eventually occur at some point much later in the computation, far from the initialization time and site, in a manner which complicates the problem and obscures its resolution.
2. the slot type should be extended to (or NULL string) only if there is some form of slot-group interaction - as noted above, or if the value NIL is really acceptable to allow operators to produce correct results. the same for "".
3. the relation between extensions and &allow-other-keys does not come through in the messages i've been able to find for the thread. is it described succinctly somewhere?
4. if one would like to see the code at the version which constitutes the current approach to this issue, which revision should one pull?
thanks,
On 2009-07-14, at 17:21 , Robert Goldman wrote:
Greg Pfeil wrote:
On 12 Jul 2009, at 11:17, Robert Goldman wrote:
Greg Pfeil wrote:
On 9 Jul 2009, at 13:08, Robert Goldman wrote:
Greg Pfeil wrote:
Here are a couple changes to ASDF that I made in the process of creating an ASDF browser for CCL's IDE:
system-source-file now works for systems without their own .asd optional parts of systems (version, maintainer, etc.) don't leave their slots unbound
The first of these looks good, but I'm less fond of the second change. I've been bitten repeatedly by bugs caused by initforms that caused slots not explicitly set to have some value that hides a mistaken failure to fill the slot.
Yeah, I should have sent these as separate patches. The first one is more important, IMO, and the second is definitely debatable.
How about sending that first patch while we work through the second issue. Even if we add the initforms, seems like it's still worth discussing the tradeoff b/w "" and NIL as defaults. I'd be inclined to prefer the latter, even at the expense of :type (or null string), so that an unsupplied value is readily distinguishable from an empty value.
Here's the system-source-file patch.
The argument for slot-unbound is that it makes an error when you think you have set a slot, but you haven't. For example, let's say I misspell an initarg so that the value quietly vanishes. Then I'd rather the system hurl an error instead of quietly going off and doing something I don't expect.
I'd rather have us handle slot-unbound on those optional parts of the system instead of stuffing a bunch of NILs in there.
When you say "us", do you mean implementing the accessors explicitly in ASDF to handle the condition, or having the caller handle/avoid the condition?
The latter.
If one is expecting strings here one must still handle checking for NIL, so having to check for slot-boundp doesn't seem that much more onerous.
Checking slot-boundp has a number of problems:
you have to export the slot names
Is this really an issue? Would someone outside the ASDF package really be looking into these things? I suppose possibly so...
it breaks the accessor abstraction because the slot names don't match the accessor names (when (slot-boundp foo 'asdf::description) (system- description foo))
(handler-case .... (slot-unbound () ...)
avoids this problem, if you know that you want to quash unbound slots.
You know, I considered this, but quickly dismissed it as too verbose. However, while
(handler-case (system-description foo) (slot-unbound () ""))is worse than the
(or (system-description foo) "")that I wanted, it's still better than the
(when (slot-boundp foo 'asdf::description) (system-descriptionfoo))
I was afraid of. I'm happy to use that pattern.
I'd still prefer optional values to not signal slot-unbound, but I understand the tradeoff with catching errors in initforms, etc.
I take your point. My earlier suggestion was to offer, e.g.,
(component-version component &optional error-p)
However, it occurs to me that this would foil uses of WITH- ACCESSORS, so is quite likely undesirable. :-(
I am coming around to a modified version of your PoV: have default values, let them be NIL, and add :type (or null string) to the relevant slots. Then NIL is a quasi-exception, and readily distinguishable from "", which would be reserved for an explicitly-supplied empty value as opposed to an implicitly-supplied default value.
Ideally, we could catch bad initializations at initialization time, but that objective is foiled by the quite important objective of extensibility, which seems to force &allow-other-keys upon us.
[BTW, Greg, I get a signature verification failure on that email. Not sure why.]
Best, r
asdf-devel mailing list asdf-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
james anderson wrote:
hello;
i am not sure, exactly to which message to reply - i suspect i'm missing parts of the thread. in any case,
- when dealing with a large system, latent unbound slots are
insidious. an initialization protocol should either provide a default value which is within the class contract, or it should signal an exception - most likely an error. that is, in the minimal form, either the slot should be defined as
(slot :initarg :slot :initform (error "SLOT required."))
or initialize instance should be specialized to effect
(defmethod initialize-instance (instance &key (slot (error "SLOT required."))) (call-next-method))
in which latter case there can be logic for the use case where a presence constraint applies to some combination(s) of a set of slots.
absent such guards, the slot-unbound error will eventually occur at some point much later in the computation, far from the initialization time and site, in a manner which complicates the problem and obscures its resolution.
This is a good description of the general problem, but it overstates the problem here. Nobody should be setting these slots after they are set (or not) in the defsystem form, so a slot-unbound error will not be difficult to resolve. However, it /might/ create a cumbersome nuisance for code that wishes to process asdf components.
Unfortunately, these slots are not required and are often left unset.
I think our debate boils down to figuring out what it means to "provide a default value which is within the class contract" in a way that won't make too much of a nuisance for asdf component object consumers.
- the slot type should be extended to (or NULL string) only if there
is some form of slot-group interaction - as noted above, or if the value NIL is really acceptable to allow operators to produce correct results. the same for "".
- the relation between extensions and &allow-other-keys does not
come through in the messages i've been able to find for the thread. is it described succinctly somewhere?
We need to provide &allow-other-keys because people could, at any time, add new subclasses of system. OTOH, this isn't such a big problem because at the end of the day the keyword arguments get passed into make-instance, so will cause an error. So this was a red herring (which I introduced and for which I apologize).
- if one would like to see the code at the version which constitutes
the current approach to this issue, which revision should one pull?
I don't have a good answer for this, sorry.
I think that James clearly states the issues. I propose we just try to come to consensus on something like the following:
1. We specify which of the system string initargs are actually optional.
then either
2a. We specify these as being of type string and specify that they take "" as a default. Supplying NIL would be a type error. For the benefit of non-type-checking lisps, we could add :after methods on initialize-instance to reject non-string values.
2b. We specify that the type is (or null string) because we want to be able to distinguish unsupplied from explicitly empty.
These both seem reasonable alternatives, as long as we state one of them clearly.
If someone will express a clear preference that isn't shouted down, I'd be happy to provide help either documenting or coding up support.
best, r
thanks,
On 2009-07-14, at 17:21 , Robert Goldman wrote:
Greg Pfeil wrote:
On 12 Jul 2009, at 11:17, Robert Goldman wrote:
Greg Pfeil wrote:
On 9 Jul 2009, at 13:08, Robert Goldman wrote:
Greg Pfeil wrote: > Here are a couple changes to ASDF that I made in the process of > creating > an ASDF browser for CCL's IDE: > > system-source-file now works for systems without their own .asd > optional parts of systems (version, maintainer, etc.) don't > leave > their slots unbound The first of these looks good, but I'm less fond of the second change. I've been bitten repeatedly by bugs caused by initforms that caused slots not explicitly set to have some value that hides a mistaken failure to fill the slot.
Yeah, I should have sent these as separate patches. The first one is more important, IMO, and the second is definitely debatable.
How about sending that first patch while we work through the second issue. Even if we add the initforms, seems like it's still worth discussing the tradeoff b/w "" and NIL as defaults. I'd be inclined to prefer the latter, even at the expense of :type (or null string), so that an unsupplied value is readily distinguishable from an empty value.
Here's the system-source-file patch.
The argument for slot-unbound is that it makes an error when you think you have set a slot, but you haven't. For example, let's say I misspell an initarg so that the value quietly vanishes. Then I'd rather the system hurl an error instead of quietly going off and doing something I don't expect.
I'd rather have us handle slot-unbound on those optional parts of the system instead of stuffing a bunch of NILs in there.
When you say "us", do you mean implementing the accessors explicitly in ASDF to handle the condition, or having the caller handle/avoid the condition?
The latter.
If one is expecting strings here one must still handle checking for NIL, so having to check for slot-boundp doesn't seem that much more onerous.
Checking slot-boundp has a number of problems:
you have to export the slot names
Is this really an issue? Would someone outside the ASDF package really be looking into these things? I suppose possibly so...
it breaks the accessor abstraction because the slot names don't match the accessor names (when (slot-boundp foo 'asdf::description) (system- description foo))
(handler-case .... (slot-unbound () ...)
avoids this problem, if you know that you want to quash unbound slots.
You know, I considered this, but quickly dismissed it as too verbose. However, while
(handler-case (system-description foo) (slot-unbound () ""))is worse than the
(or (system-description foo) "")that I wanted, it's still better than the
(when (slot-boundp foo 'asdf::description) (system-descriptionfoo))
I was afraid of. I'm happy to use that pattern.
I'd still prefer optional values to not signal slot-unbound, but I understand the tradeoff with catching errors in initforms, etc.
I take your point. My earlier suggestion was to offer, e.g.,
(component-version component &optional error-p)
However, it occurs to me that this would foil uses of WITH- ACCESSORS, so is quite likely undesirable. :-(
I am coming around to a modified version of your PoV: have default values, let them be NIL, and add :type (or null string) to the relevant slots. Then NIL is a quasi-exception, and readily distinguishable from "", which would be reserved for an explicitly-supplied empty value as opposed to an implicitly-supplied default value.
Ideally, we could catch bad initializations at initialization time, but that objective is foiled by the quite important objective of extensibility, which seems to force &allow-other-keys upon us.
[BTW, Greg, I get a signature verification failure on that email. Not sure why.]
Best, r
asdf-devel mailing list asdf-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
asdf-devel mailing list asdf-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
On 2009-07-14, at 18:56 , Robert Goldman wrote:
james anderson wrote:
hello;
[...]
This is a good description of the general problem, but it overstates the problem here. Nobody should be setting these slots after they are set (or not) in the defsystem form, so a slot-unbound error will not be difficult to resolve. However, it /might/ create a cumbersome nuisance for code that wishes to process asdf components.
my experience is that you can change "might" to "did".
[...]
- if one would like to see the code at the version which constitutes
the current approach to this issue, which revision should one pull?
I don't have a good answer for this, sorry.
I think that James clearly states the issues. I propose we just try to come to consensus on something like the following:
- We specify which of the system string initargs are actually
optional.
then either
2a. We specify these as being of type string and specify that they take "" as a default. Supplying NIL would be a type error. For the benefit of non-type-checking lisps, we could add :after methods on initialize-instance to reject non-string values.
2b. We specify that the type is (or null string) because we want to be able to distinguish unsupplied from explicitly empty.
These both seem reasonable alternatives, as long as we state one of them clearly.
If someone will express a clear preference that isn't shouted down, I'd be happy to provide help either documenting or coding up support.
i propose, 2b iff some operator depends on the distinction. otherwise 2a.
thanks,
james anderson wrote:
On 2009-07-14, at 18:56 , Robert Goldman wrote:
james anderson wrote:
hello;
[...]
This is a good description of the general problem, but it overstates the problem here. Nobody should be setting these slots after they are set (or not) in the defsystem form, so a slot-unbound error will not be difficult to resolve. However, it /might/ create a cumbersome nuisance for code that wishes to process asdf components.
my experience is that you can change "might" to "did".
[...]
- if one would like to see the code at the version which constitutes
the current approach to this issue, which revision should one pull?
I don't have a good answer for this, sorry.
I think that James clearly states the issues. I propose we just try to come to consensus on something like the following:
- We specify which of the system string initargs are actually optional.
then either
2a. We specify these as being of type string and specify that they take "" as a default. Supplying NIL would be a type error. For the benefit of non-type-checking lisps, we could add :after methods on initialize-instance to reject non-string values.
2b. We specify that the type is (or null string) because we want to be able to distinguish unsupplied from explicitly empty.
These both seem reasonable alternatives, as long as we state one of them clearly.
If someone will express a clear preference that isn't shouted down, I'd be happy to provide help either documenting or coding up support.
i propose, 2b iff some operator depends on the distinction. otherwise 2a.
Here are the initargs from which we have to choose:
:licence :license :maintainer :author :long-description :description :default-component-class :if-component-dep-fails :components :properties :pathname :parent :do-first :in-order-to :name :version
Of these, I believe our discussion pertains primarily to
:license/:licence :maintainer :author :description and :long-description :version
Are these all truly optional? Personally, I wish that :version wasn't, and/or that we enforced some standard on values supplied there, since it's easy to put in something that will cause version-satisfies to choke.
How about we confine our attention to all of these EXCEPT :version, which is worthy of a discussion of its own.
These are all going to be used primarily by software which simply displays information about the systems, and all of that software (unless there's a 'describe' method) is going to be external to ASDF proper, which means it's hard for me to answer James' "some operator depends on the distinction" question.
Best, r
On 2009-07-14, at 19:35 , Robert Goldman wrote:
james anderson wrote:
[...]
- if one would like to see the code at the version which
constitutes the current approach to this issue, which revision should one pull?
I don't have a good answer for this, sorry.
I think that James clearly states the issues. I propose we just try to come to consensus on something like the following:
- We specify which of the system string initargs are actually
optional.
then either
2a. We specify these as being of type string and specify that they take "" as a default. Supplying NIL would be a type error. For the benefit of non-type-checking lisps, we could add :after methods on initialize-instance to reject non-string values.
2b. We specify that the type is (or null string) because we want to be able to distinguish unsupplied from explicitly empty.
These both seem reasonable alternatives, as long as we state one of them clearly.
If someone will express a clear preference that isn't shouted down, I'd be happy to provide help either documenting or coding up support.
i propose, 2b iff some operator depends on the distinction. otherwise 2a.
Here are the initargs from which we have to choose:
:licence :license :maintainer :author :long-description :description :default-component-class :if-component-dep- fails :components :properties :pathname :parent :do-first :in-order-to :name :version
Of these, I believe our discussion pertains primarily to
:license/:licence :maintainer :author :description and :long-description :version
Are these all truly optional? Personally, I wish that :version wasn't, and/or that we enforced some standard on values supplied there, since it's easy to put in something that will cause version-satisfies to choke.
How about we confine our attention to all of these EXCEPT :version, which is worthy of a discussion of its own.
These are all going to be used primarily by software which simply displays information about the systems, and all of that software (unless there's a 'describe' method) is going to be external to ASDF proper, which means it's hard for me to answer James' "some operator depends on the distinction" question.
none of author, description, long-description or maintainer are referenced in the asdf code (nb i'm still with 1.130) i worry about the potential use-case, that some app would want to impute values from a module to its components. this argues that NIL should be the default.
i don't know of the uses to which one puts license, but were it to matter, one could argue, that asdf should enforce canonicalized license keywords. i've no idea where to find such a thing, but there must be one "out there". this might require the addition of a "license-description" field (with a "" default).
version, on the other hand, is used internally. i have never used it. the predicate reads as if it requires a string to compare and interprets an unbound slot as a wildcard. that is not good. a distinguished value would be better. it reads as though improvements to the logic to supported internal wildcards and/or interval expressions in the version specification would not hurt its utility.
as to the others: default-component-class : is cl-source-file if-component-dep-fails : is :fail components : are there any arguments against an empty module? if not this should default to NIL. properties : is NIL. pathname : the version i have reads as if this value is defaulted by the interface operator. if that is the intent, the class definition should have an error form for the initform. parent : is NIL do-first : id NIL in-order-to : is NIL
james anderson wrote:
i don't know of the uses to which one puts license, but were it to matter, one could argue, that asdf should enforce canonicalized license keywords. i've no idea where to find such a thing, but there must be one "out there". this might require the addition of a "license-description" field (with a "" default).
I have an app which wanted to use the :license field but quickly realized I needed to maintain that info myself. Many projects don't set this field, and licensing is often an afterthought as a library grows. Then you have things like Qt which are dual-licensed.
At the end of the day, there are so many license variants that there probably isn't much point in standardizing this field. Anybody who cares will need to read the actual copyright statement anyway. But it wouldn't hurt to document a list of recommended license keys. Something like :commercial, :bsd, :mit, :gpl, :lgpl, :llgpl, :bsl, ...
- Daniel
BTW, the patch to the system source file is in 1.358.
-- Gary Warren King, metabang.com Cell: (413) 559 8738 Fax: (206) 338-4052 gwkkwg on Skype * garethsan on AIM * gwking on twitter
Robert Goldman writes (2009-Jul-09):
(Replying to an older posting,)
I'd rather have us handle slot-unbound on those optional parts of the system instead of stuffing a bunch of NILs in there.
Well, if you do not initialize slots with NIL, how can people know when it's safe to call an accessor?
Checking SLOT-BOUNDP would mean that users have to know about internal implementation issues: the slot names.
In ASDF, it's especially icky because slots tend to have different names than accessors, so you really have to look into the source.
-T.
Tobias C. Rittweiler wrote:
Robert Goldman writes (2009-Jul-09):
(Replying to an older posting,)
I'd rather have us handle slot-unbound on those optional parts of the system instead of stuffing a bunch of NILs in there.
Well, if you do not initialize slots with NIL, how can people know when it's safe to call an accessor?
Checking SLOT-BOUNDP would mean that users have to know about internal implementation issues: the slot names.
In ASDF, it's especially icky because slots tend to have different names than accessors, so you really have to look into the source.
I think we agreed that, in almost all cases, anyway, putting NIL in as the default value would be OK. There were a couple of cases where the null string might be better (so we don't need (OR NULL STRING) types), but I /believe/ that was it.
I think we concluded (IIRC, largely with James Anderson doing the thinking) that there were few or no cases where SLOT-UNBOUND was necessary.
I was initially mentioning a concern about whether there might be cases where SLOT-UNBOUND was appropriate. IMO, slots should be left unbound when it's a mistake not to initialize them. I was speaking from a concern that was born dealing with code where people would, as a matter of routine, add ":initform NIL" to every slot definition. That can fail very badly when a slot needed to be actively set. As I said, IIRC, we decided that there were very few cases where this was the case (e.g., I think it's actually an error for a component to be unnamed, but I don't think that can ever happen).
There was some residual discussion about whether the meta-data (e.g., author, license, etc.) should have "" or NIL as the default initform. This boils down to an aesthetic preference for whether :type (OR STRING NULL) is worse than having to test with (equalp <attribute> "") [as opposed to (null <attribute>)]. Both seem somewhat ugly. I bet if anyone took the trouble to make a patch, one way or another, that would close the discussion.
Cheers, r
-
dherring＠tentpost.com -
Gary King -
Greg Pfeil -
Greg Pfeil -
james anderson -
Robert Goldman -
Tobias C. Rittweiler