Re: Portability (long)

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

  This whole exercise seems entirely misguided to me.  I have not seen you
  (or anyone) respond well to Morry's objection that any ``appendix''
  constitutes a standard with inertia of its own.

An appendix will have inertia just as any large body of code (of any
sort) has inertia.  I don't believe that the inertia will be as great as
C's standard library because Scheme already has i/o and string=?, etc.
which C needed to be viable.  Scheme is pretty viable on its own.  In
addition, I expect things to change.  R2RS->R3RS had some interesting
changes.  Number syntax will change when (if) we can agree on ways to
deal with approximations to real numbers.

My proposal arises out of my perception that some names and functions are
widely used and are diverging.  I think that defining a language without
some thought of its enviromnent is a bit like Algol without i/o.  We
should not do much now, but there are some things that we do have
experience with.  I have never seen a file system without the idea of a
file pointer designating a position within a file (Pascal got in trouble
with exactly this when they belatedly had to standardize).  I have not
seen too many Lisps without a Read Eval Print Loop which has a way of
RESETing to the top level and EXITing to the host system.  I don't need a
REPL to program my toaster-oven, but I do use them in many Schemes (T,
MacScheme. PCScheme, Skim, AmigaScheme and XScheme this last year) and
would like to be able to trust a few things not to change.  I feel that
there is a need for discussion on the topics raised because the rate of
convergence for the Scheme community is very slow {e.g. numerics, macros}.
The Structure and Interpretation text is being used in over 125
universities last time I heard and I am concerned that issues be worked
on and solved before they become ISSUES.


  I have also not seen any response to, I think, Jinx's point about using
  extra ``compile'' and ``load'' files that test which implementation is in
  use and coordinate things appropriately.

There is *no* standard way of finding out what implementation is running!

  Any publication of a standard interface to certain facilities tends to
  reduce experimentation among implementations.  Such constraints should only
  be imposed on facilities with which we collectively have significant
  experience and on which we have reached consensus about what is The Right
  Thing.

Agreed.  The question is of balance and timing.  I don't expect the
FORMAT function to have "~A" format string cause a program to abort.  I
expect FORMAT (if it exists) to DISPLAY the next argument.  I agree with
your statement.  I think that in some areas we can reach a consensus.

  I think that detailed discussion of your many proposals is premature until
  you or others have more adequately justified the point of the whole
  endeavor.

Well, there are some things it would be nice to do.  Assuming that a
syntax system comes along soon, we can certainly do without ALIAS and
friends.  To do a structure or object system a way of adding disjoint
types would be nice.  I usually find some system code I can't recompile
with (e.g.) VECTOR? integrated, and I do get tired of rewriting a printer
to make sure something prints as #<structure foo> rather than a
strange-looking vector.  I can't write a native or byte-code compiler
without the ability to do binary i/o.  I can't do a portable interactive
text editor without the ability to set up software interrupt handlers.
Likewise, some sort of ERRORSET would be helpful in catching user runtime
errors in an editor rather than putting a user in some random debug REPL
in a raw mode tty.  I have yet to see a runtime system library of any
size which did not supply a set of SORT functions or a RANDOM number
generator or some form of FORMATted output.  Yes, I can do my own reader
for strings, but STRING-PORTs are much more convenient.

[OK, so I have a more-than-full-time job and outside interests.  There is
a lot that I want.  And I am impatient.  I want great things.  I want
discussions in certain areas so that we will have convergence.]

**"What, if any, of this is appropriate for the IEEE Scheme Standard at
this time?"**

Assuming a syntax system and a yellow pages (Real Soon Now...), the
minimum I see is the ability to query an implementation to find out its
name and version (Nice to get Operating and Filesystem likewise and what
numerics, etc. are supported).  

I would very much like to see (and feel strongly about) having specific
problems addressed in a non-binding appendix (not part of the language
standard) and as interfaces only:
    Binary i/o (including file positioning); <mumble>-ports
    Formatted output (FORMAT)
    Basic error handling, tracing
    Compiler and Inspector invocation
    Date and Time

I would be happy to see: (interfaces to)
   Ability to add disjoint types (to support Structures, Objects)
   Commonly used functionality.


-------------------------
Thank you for speaking up.
-Ken			kend@mrloog.LA.TEK.COM