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

[mkatz@sesame.stanford.edu (Morris Katz)]

   Date: 21 Mar 89 18:05:49 PST (Tue)
   From: kend%mrloog.la.tek.com@RELAY.CS.NET

   JINX,

   Some general comments on your general comments:
   --------

	Some general comments on your proposal:

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

   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. 

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.

	Comments on individual issues:


	4) RESET and FATAL-ERROR: I would propose a different, more powerful,
	procedure instead, on top of which both of these could easily be
	built.

	(ABORT-TO-NEAREST-REPL <thunk>)

	fetches a continuation created by the nearest repl (nearest in systems where
	there is more than one, like MIT Scheme, the top level one if there is
	only one) and executes <thunk> with this continuation.

	Thus

	(define (reset)
	  (abort-to-nearest-repl (lambda () unspecific)))

	(define (fatal-error message . irritants)
	  (abort-to-nearest-repl
	   (lambda ()
	     (for-each (lambda (unused-arg)
		    (display #\space)
		    (display obj))
		  (apply format #t message irritants))
	     (newline))))

   How is the "nearest repl" known to the runtime system?  How does a
   Scheme system recognize that a function is a (possibly user written)
   repl?  I don't have a problem with implementing RESET or FATAL-ERROR
   this way, but why standardize this function as a library routine?


	I have strong objections against having a procedure named FATAL-ERROR
	(or anything else with ERROR in it's name) which does not allow the
	option of fixing the bug and proceeding.

   Perhaps I'm confused.  You don't want a FATAL ERROR to abort a
   computation?  This might be a valuable behavior in a (possibly
   parallel) multi-tasking search situation.  What would be the
   difference between FATAL-ERROR and ERROR ?  The thing that I am trying
   to clean up here is the confusion over CERROR vs ERROR as to when an
   error is fatal and when recoverable.  `ERROR' is pretty common and
   typing RECOVERABLE-ERROR gets a bit tedious. 


	I'm not too attached to the name ABORT-TO-NEAREST-REPL.  The similar
	MIT Scheme procedure is called ABORT->NEAREST.

   I don't see this as a common usage in other Scheme implementations.
   Anyone? 

When someone is proposing new functionality, common usage should be irrelevant.
We should be trying to find the correct way of doing things, not the most
common way.  Common usage is a good argument as to why it is premature to
standardize this feature, not as to why a given functionality is more or less
desirable than another.  Lets here some substantive technical arguments for or
against different approaches.



	7) ALIAS: Why can't you just use (define <alias> <original>) ?

   This is hard to do with special forms.

	A different question is making your compiler generate reasonable code,
	but this should not be difficult.
	If you want to use it for special forms instead (like comment), I'd
	rather wait until we have some way of creating syntactic extensions.

   The reason for these bits of syntax is that we need to solve the
   portability problems now and we do not yet have syntactic extensions.
   Unless someone in Indiana moves fast, we will not have syntactic
   extensions in R4RS.  When we get syntactic extensions, these are easy
   to `define'.  I strongly suspect that the number of Scheme
   implementations is going to double every year or two for a while.  We
   need to be heading off the problems that will exist in 5 years unless
   fixed now. 

I feel VERY strongly that new syntactic forms of this sort should not be added
to Scheme.  Again, standardization seems to be driving language design, rather
than visa versa.  Lets put our effort into standardizing syntactic extensions
rather than into kludging around them.


	9) UNLESS and WHEN: I would wait for syntactic extensions.  I
	generally object to adding spurious special forms.

   We don't have syntactic extensions.  I see these in a lot of code.  I
   believe they are common usage.  Who else out there objects to these?
   Who else uses them?

I HATE the idea of adding unless and when to Scheme.  We already have enough
cruft in the form of do.  I use Scheme rather than CommonLisp because of its
elegance and simplicity.  The way we are going, I fear that pretty soon the two
will be indistinguishable.

   ----------
   Thank you very much for your input.

   -The Reader


					Morry Katz
					katz@polya.stanford.edu