SRFI 198 and the Schemeregistry
hga@xxxxxx
(30 Aug 2020 12:37 UTC)
|
Re: SRFI 198 and the Schemeregistry
Lassi Kortela
(30 Aug 2020 14:01 UTC)
|
Re: SRFI 198 and the Schemeregistry
hga@xxxxxx
(30 Aug 2020 14:25 UTC)
|
Re: SRFI 198 and the Schemeregistry
Lassi Kortela
(30 Aug 2020 14:52 UTC)
|
Re: SRFI 198 and the Schemeregistry
hga@xxxxxx
(30 Aug 2020 15:45 UTC)
|
Re: SRFI 198 and the Schemeregistry
Lassi Kortela
(30 Aug 2020 16:06 UTC)
|
Re: SRFI 198 and the Schemeregistry
John Cowan
(30 Aug 2020 14:55 UTC)
|
Re: SRFI 198 and the Schemeregistry
Lassi Kortela
(30 Aug 2020 15:22 UTC)
|
Re: SRFI 198 and the Schemeregistry
John Cowan
(30 Aug 2020 16:05 UTC)
|
Re: SRFI 198 and the Schemeregistry
Lassi Kortela
(30 Aug 2020 16:39 UTC)
|
Re: SRFI 198 and the Schemeregistry Lassi Kortela (30 Aug 2020 16:56 UTC)
|
Re: SRFI 198 and the Schemeregistry
hga@xxxxxx
(30 Aug 2020 20:13 UTC)
|
Re: SRFI 198 and the Schemeregistry
hga@xxxxxx
(30 Aug 2020 15:23 UTC)
|
Re: SRFI 198 and the Schemeregistry
Lassi Kortela
(30 Aug 2020 15:35 UTC)
|
Re: SRFI 198 and the Schemeregistry
Lassi Kortela
(30 Aug 2020 15:44 UTC)
|
Re: SRFI 198 and the Schemeregistry
Marc Nieper-Wißkirchen
(30 Aug 2020 16:02 UTC)
|
Re: SRFI 198 and the Schemeregistry
Lassi Kortela
(30 Aug 2020 17:05 UTC)
|
Re: SRFI 198 and the Schemeregistry
John Cowan
(30 Aug 2020 17:47 UTC)
|
Re: SRFI 198 and the Schemeregistry
John Cowan
(30 Aug 2020 18:56 UTC)
|
Re: SRFI 198 and the Schemeregistry
Lassi Kortela
(30 Aug 2020 18:59 UTC)
|
Re: SRFI 198 and the Schemeregistry
Marc Nieper-Wißkirchen
(30 Aug 2020 19:45 UTC)
|
Re: SRFI 198 and the Schemeregistry
hga@xxxxxx
(30 Aug 2020 17:34 UTC)
|
Re: SRFI 198 and the Schemeregistry
John Cowan
(30 Aug 2020 17:55 UTC)
|
Re: SRFI 198 and the Schemeregistry
Arthur A. Gleckler
(30 Aug 2020 18:27 UTC)
|
Re: SRFI 198 and the Schemeregistry
Lassi Kortela
(30 Aug 2020 18:57 UTC)
|
Re: SRFI 198 and the Schemeregistry
Arthur A. Gleckler
(30 Aug 2020 19:10 UTC)
|
Don't panic
Lassi Kortela
(30 Aug 2020 19:28 UTC)
|
Re: Don't panic
Marc Nieper-Wißkirchen
(30 Aug 2020 19:34 UTC)
|
Re: Don't panic
Arthur A. Gleckler
(30 Aug 2020 20:00 UTC)
|
Re: SRFI 198 and the Schemeregistry
Lassi Kortela
(30 Aug 2020 19:57 UTC)
|
Re: SRFI 198 and the Schemeregistry
John Cowan
(30 Aug 2020 20:09 UTC)
|
>> Does the above idea help resolve this concern, which I admit is >> perfectly legitimate? It allows a specific status object to belong to >> many groups. > > If 'convention can be a list, that solves it. > > But doesn't testing for the existence of specific properties relating to > the desired convention also solve it? If you have a non-#f 'errno > property, you can do errno-related stuff to it; Aha, here's a further point of - not really disagreement, but different priorities. I would bank heavily on picking property names (going into the Scheme Registry) that are hard to misuse. For example, I wouldn't coin a 'line property because it doesn't say whether it's a line number, a line of text as a string, or something else. 'line-number clearly says it's a number. Likewise, 'sqlstate or 'errno are names that clearly refer to standard terminologies. 'errno is vaguely risky ("error number" is a generic concept) but 'errno is so universal that there's little risk of confusion, especially as we'll document it in the Registry. The tentative list in the registry has 'facility and 'severity. These are deliberately vague. The concepts exist in syslog, but also in VMS and other systems. The principle is that vague concepts are fine, but their names have to be equally vague. A 'vms-facility or 'syslog-facility property could have the same information with a more clearly defined meaning. Or a 'which-facility property with 'vms or 'syslog. If property names are chosen haphazardly so that they clash easily, my proposal is nullified and doesn't make sense.