Joel Ray Holveck <·····@juniper.net> writes:
> Is there any X3J13 rationale available beyond what's in the HyperSpec?
No.
The only other document J13 ever created that touches on any
"rationale" stuff is the reply to the public review comments, where
what was required of the committee was to either address the change or
to offer an explanation of why we took no action on the changes. Since
in all cases, we just took no action, that generated a few rationales.
But all in all, it was a very expensive process to create the standard
and no budget was allocated for creating rationales.
In truth, there really isn't a rationale for a lot of stuff. People
who've never been involved in standards work expect the reasons for
various things to be technical, but usually it was more like "3 people
wanted it this way and 2 that way, so the 3 won." Democratic
concensusmaking rarely leads to explainable outcomes--sometimes it doesn't
even lead to outcomes which satisfy even one person who was involved in
the voting. Such is life.
Was there something in particular you were curious about? A few of us
who were involved in the votes taken can sometimes recall the nature of
the discussion surrounding various issues....
>> Is there any X3J13 rationale available beyond what's in the HyperSpec?
> No.
[snip]
> In truth, there really isn't a rationale for a lot of stuff. People
> who've never been involved in standards work expect the reasons for
> various things to be technical, but usually it was more like "3 people
> wanted it this way and 2 that way, so the 3 won." Democratic
> concensusmaking rarely leads to explainable outcomes--sometimes it doesn't
> even lead to outcomes which satisfy even one person who was involved in
> the voting. Such is life.
Sure, I was just curious if somebody took notes as far as "The ones
who wanted it this way argued that the burden on possible
implementations would case the sky to fall if X was added to the
standard" or what have you.
> Was there something in particular you were curious about? A few of us
> who were involved in the votes taken can sometimes recall the nature of
> the discussion surrounding various issues....
Nothing earth-shattering; I was just wondering why COMPOSE wasn't
added. It was considered and rejected at the Jan 89 X3J13 meeting as
part of the FUNCTION-COMPOSITION issue (which did still create two
other functions). It seems trivial (much like ACONS), and I had
assumed it was part of the language until I tried to use it recently,
so I was kinda curious.
Cheers,
joelh
Joel Ray Holveck <·····@juniper.net> writes:
> >> Is there any X3J13 rationale available beyond what's in the HyperSpec?
> > No.
> [snip]
> > In truth, there really isn't a rationale for a lot of stuff. People
> > who've never been involved in standards work expect the reasons for
> > various things to be technical, but usually it was more like "3 people
> > wanted it this way and 2 that way, so the 3 won." Democratic
> > concensusmaking rarely leads to explainable outcomes--sometimes it doesn't
> > even lead to outcomes which satisfy even one person who was involved in
> > the voting. Such is life.
>
> Sure, I was just curious if somebody took notes as far as "The ones
> who wanted it this way argued that the burden on possible
> implementations would case the sky to fall if X was added to the
> standard" or what have you.
There is no requirement that they vote rationally.
People are permitted to vote according to a flip of the coin. How they
decide to vote as they do is not required to be consistent, and sometimes
is in fact not consistent.
> > Was there something in particular you were curious about? A few of us
> > who were involved in the votes taken can sometimes recall the nature of
> > the discussion surrounding various issues....
>
> Nothing earth-shattering; I was just wondering why COMPOSE wasn't
> added. It was considered and rejected at the Jan 89 X3J13 meeting as
> part of the FUNCTION-COMPOSITION issue (which did still create two
> other functions). It seems trivial (much like ACONS), and I had
> assumed it was part of the language until I tried to use it recently,
> so I was kinda curious.
It's probably in my personal notes, but they're offline due to a disk
crash. (I have good backups, but because my house is being remodeled,
it probably won't be until everything is all back to normal that I try
to recover from the disk crash.)
However, my recollection of that situation, if you like that kind of
thing, is that the committee thought it extreme that we even added
CONSTANTLY and COMPLEMENT. I believe there was a lot of fussing about
CL not being a functional language, and these operations being really
inappropriate and arbitrary and excessive. There was probably the
sense that there was already too much in the language and that, if
anything, we should be removing things rather than adding them; this
was a recurrent theme in most votes. And there are some issues with
COMPOSE wherein it's not obvious what the order of arguments should
be; since there was no "current practice" to rely on, it was hard to
push for one or the other. And I think there was a sense that no one
was asking for this, other than Scheme programmers. I think we got
CONSTANTLY added because people do routinely ask for FALSE and TRUE as
functions, which one can now write as just (CONSTANTLY T) and
(CONSTANTLY NIL), so it saves adding two functions. Furthermore,
COMPLEMENT got through, I think, because it enabled fixing of
:TEST-NOT x to be :TEST (COMPLEMENT x), which allowed deprecation (at
least, and possibly later flushing) of :TEST-NOT.
I'm about 70% sure that some or all of these reasons were in play on
the day of the vote. Whether there were others as well, I can't say.
My (or anyone's) recollections are, of course, not infallible. Others
reading this newsgroup were probably present for the vote, so I invite
additions to or corrections of my memories.