Re: "Its the little things that count. Hundreds of 'em." -- Cliff Shaw

[kend%mrloog.la.tek.com@RELAY.CS.NET]

Rather than indent to the limit, I am breaking things up a bit...

JINX (Guillermo Rozas):---------------------------------------------V

	2) I think it's premature to standardize on something like this for
	IEEE.  Proposals along these lines should certainly be considered for
	R5RS.

Ken Dickey:---------------------------------------------------------V

   On the contrary, we need to standardize library issues as soon as
   possible to keep divergence from preventing portability.  The IEEE
   standard is a good place for this.  I really would rather see only
   *language* issues in RnRS.  Most languages standardize too late--after
   implementations have significantly diverged--and there is hell to pay as
   each implementor tries to get *his* dialect as *the* standard (e.g.
   ATLAS).  Currently, we have a portable language, but not portable code.
   I believe that there is sufficient practical experience to have a
   standard interface to common functionality and that the IEEE standard
   needs such an interface to be viable. 

Morry Katz:---------------------------------------------------------V

It seems that the situation that many of us feared is already coming to pass.
I see here a justification for why standardization should drive language design
rather than visa versa.  Let us remember that as difficult as it is to
standardize after peoples paths have diverged, it is even more difficult to
unstandardize a mistake.  I would oppose standardization of any feature that
has not been experimented with in its proposed form for standardization by the
Scheme community for at least 6 months.  DON'T RISK STANDARDIZATION OF
POTENTIAL BUGS.

Ken Dickey:---(New)--------------------------------------------------V

I guess I need to be more clear.  I distinguish between a language and a
library.  I am not proposing any changes to the Scheme language.  I am
proposing *optional* library interfaces to either (1) enable code
portability between implementations or (2) codify common usages.  In
class (1) I am interested in obtaining the functionality in the best
possible way.  In class (2) I don't want any new features or
functionality, but I do want an interface--when implemented--to have the
same parameters and semantics.  {*If* someone implements UNLESS, I want
(UNLESS <test> <exp>...), not some randomness.  UNLESS has been used for
years--I didn't make it up}.

The interfaces (functions or special forms in this context) I consider
class (2) are:
	pretty-print
	reset
	unless
	when
	random
	sort
	sort!
	suspend
	autoload
	define-structure
I have rarely seen an implementation without them.

Other interfaces are included to cure specific problems: to obtain basic
implementation information, format output, do basic error handling,
tracing and environmental inspection, specialization (alias,
define-if-<mumble>, comment-when), benchmarking (date & time functions),
and binary-i/o (including buffers).  With the exception of the
define-if-<mumble> and comment-when (and I would really like to see
alternate proposals for these), any differences in interface from what
most implementations have had for years is purely cosmetic--there is
nothing fundamentially new here.
  
There are many people like myself who are in a commercial environment and
wish to use Scheme.  Unless Scheme can be shown to be a portable language
which tackles commercial problems we are condemned to use C++ or some
other abomination.  It is my belief that if the above issues are not
addressed in the IEEE Scheme Standard, usage of the language will be
crippled.  Standardizing interfaces to functionality which has existed
for some time in many implementations in a non-binding appendix seems to
me the most conservative way of doing so.  Conditional compilation
/interpretation in some form seems to be the major piece of work, but I
see it as crucial to the success of the Scheme language (I am not giving
up my evenings doing this just to get flamed).

{I am sensitive to your concerns, but I don't think that for the readers
of this group conditional specialization is such a large problem that it
can't be addressed.  Given the time frame of the standards process, we
may have 6 months of implementation experience by the time the standard
is published}.

****************************************

Morry Katz:----------------------------------------------------------

When someone is proposing new functionality ...

Ken Dickey:-(new)---------------------------------------------------

I recant.  ABORT->NEAREST, MAKE-<direction>-PORT and friends belong as
proposals to RnRS.

***************************************

I suggest we seperate:
    [A] Arguments to keep or scrap the library proposal as a whole.
and [B] Cleanup, clarifications, or alternate interface proposals for
        specific functionality.

Thanks for the input,
-Ken			kend@mrloog.LA.TEK.COM