[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

2nd RFD: comp.org.lisp-users and comp.std.lisp

This is the second (of two) formal Request for Discussion for the
creation of two newsgroups:

Please see *** Proceedure below, to respond to this RfD, or to 
encourage a vote.

(the text below has been changed slightly, see last sentence before 
"*** Proceedure", and text after that heading)

***Proposed Names:         Proposed Moderation:     Proposed Moderator:

comp.org.lisp-users               No
comp.std.lisp                     Yes                 miller@cs.rochester.edu



Discussion of general topics relevant to the Association of Lisp Users (ALU)
(including Lisp Vendors), in particular centered on membership issues,
future conferences, publications, and Lisp advocacy issues. Overlap with
comp.lang.lisp.*, and other groups this message is cross-posted to should be
minimal, as this is NOT intended to be a technical, but an organizational
group. The ALU mailing list will be bidirectionally gatewayed into this

welcome to post (appropriate messages).


(also see below) This moderated (sub)group is intended to foster focused
discussion on user-group supported standards that are not addressed by
formal standards, e.g. in the (almost final) ANSI Common Lisp. It will be
moderated for appropriateness to the group and timeliness, and not for
technical content; the moderator will periodically post the status of all
ALU standard proposals, open and close discussions on new standards, and
call for specific technical experts to take charge of each standard (for
surveying existing practice, proposing, incorporating changes, and wording
the final version).  The moderator will be reponsible for recording all
finalized standards for the ALU, assigning identifiers and submitting copies
to all interested vendors. The intent is to give feedback to the several
LISP vendors for inter-vendor compatible support of various features that
have developed too late to be included in the work of ANSI committee X3J13,
such as (but not limited to) DEFSYSTEM, Foreign Function Interface, and

Note that ALU board member Brad Miller (miller@cs.rochester.edu) volunteered
at the LUV '93 conference to moderate such a newsgroup, and act as the ALU
"de facto" standards coordinator for the vendor and user community.

to post (appropriate messages).

*** Reasoning behind this RFD

Although SLUG (Symbolics Lisp Users Group) evolved into the Association of
Lisp Users, the mailing list for SLUG is still used for discussions
related to issues regarding Symbolics products.  As such, it is not the
appropriate vehicle for discussions relevant for the entire membership of
ALU. One of the primary purposes behind the ALU organization is to promote
the use of, and education about LISP-like languages. At the ALU (open)
board meeting at LUV '93, we discussed this and felt that a newsgroup in
the comp.org hierarchy could best help us achieve our goals of
disseminating information about promoting lisp to interested parties, have
a single place for discussing how the ALU can help parties interested in
lisp, and have a useful place for discussion on future conferences and a
possible periodical take place. The newsgroup will also cut down the
number of addresses on the direct ALU list, which should ease support
chores on that list as well. Futhermore the common-lisp mailing list is
designed for technical, rather than evangelical discussions; furthermore
the ALU does NOT restrict itself to only common-lisp, but all dialects of
lisp like languages.

The other major discussion at that point was on how to get the various
vendors of lisp products to merge their incompatible definitions of several
common features, namely DEFSYSTEM, foreign function interface, and
multiprocessing. The vendors suggested that feedback from the user group
would be welcome, and it was clear that only through user pressure would the
vendors be inclined to improve the existing situation (which for those of us
who maintain "portable" software that needs to work under several vendors
offerings know is quite painful). At that time, I volunteered to coordinate
such "de facto" (better called "de dicto") standards creation for the ALU,
though commentary would be open to all interested parties.
comp.std.lisp would be the place to hold specific focused
discussion on these evolving standards, which would ultimately evolve into
some sort of request to the vendor community to support specific features
(in addition to, or in place of overlapping features they already support).
Note that this is in response to vendor wishes: they want more feedback from 
the user community; this is one way of providing it, with the ALU representing
the users.

Some of the standards developed will be considered optional: in general, the
standards so developed will not necessitate vendors to implement features
they do not wish to support (e.g. version control under defsystem), but
rather be a request that if they do support such a feature, that the ALU
standard be one of the ways of accessing it. (So, e.g. Franz would be free
to not support version control at all, or support their own, presumably
better implementation, but in the latter case should also support the ALU
standard for version control under defsystem).

While the initial discussion on comp.std.lisp will concentrate on
common-lisp, it is not, in principle, so limited; it is intended to be a
good place for users of any lisp dialect to communicate and attempt to
agree on non-formal standards that can be used as feedback from users to
vendors and other implementation groups. However, where better forums for 
a particular dialect or branch of lisp exists, the user will be strongly
encouraged by the moderator to use that forum instead of comp.std.lisp 
(since presumably that will be where the audience for the idea is).

*** Procedure:

Any discussion should be kept in news.groups; and should
include ALU or Lisp somewhere in the title. 

By 12 November 93, if interest warrants, a CFV will be initiated by
miller@cs.rochester.edu, and will be conducted by an impartial third party.
Please send me private email (or post something to news.groups) if you would
definitely vote FOR or AGAINST this proposal (if against, I'd like to know
why, feel free to post to news.groups as well); I will only go through the
CFV stage if it looks like success (100 more yes votes than no; 2/3
majority) is probable.

Thanks for your interest and consideration,
Brad Miller, for the ALU, miller@cs.rochester.edu

[note: first RFD was also mailed to a number of mailing lists, this second
RFD has not been]
---- Brad Miller miller@cs.rochester.edu
Disclaimer: I disavow any support, or consent for the actions
            or existance of any so called government entity.