Re: Splitting SRFI-10 into three?

[Richard Kelsey <kelsey@xxxxxxxxxxxxxxxxxxx>]

   Date: Wed, 13 Oct 1999 19:58:16 GMT
   From: oleg@xxxxxxxxx

	   Let me try to restate your suggestions, to make sure I know
   what you were saying.

   ... SRFI-10 proposes another, formal and generic, way of extending
   external representations of scheme values, namely, via a #,(<symbol>
   <datum>*) form. A particular SRFI-X that introduces a new data type
   simply should pick up the appropriate <symbol> and decide upon
   <datum>-arguments.  ...

   Am I right it representing your position?

It's not *my* position, it's my guess as to *your* position.

My suggestion dealt with new external representations in general, not
just external representations of new data types.  This would include
an SRFI with your

 #,(pi) #,(epsilon) #,(Infinity) #,(NaN)

for example.

	   Furthermore, consider "variable constants", for example,
   #,(os-type). When the reader scans the code, it replaces #,(os-type)
   with a literal symbol, e.g., Solaris, HP-UX. ...

Why not just use macros for this?  As soon as you add a new level
you get problems because later levels cannot talk to earlier ones.
If the program cannot make use of the information before macro-expansion
time there is no utility in providing it at read time.

	   You're saying that SRFI-10 has nothing to implement. Yet it
   extends the syntax of Scheme, and thus requests that a Scheme reader
   at least recognize the #,() form. Currently it does not. 

It does not extend the syntax of Scheme.  You say so yourself:

   When a non-SRFI-10 compliant reader comes
   across a #,(foo) form, it immediately throws an error. When a SRFI-10
   compliant reader sees the same form and does not know what to make of
   the 'foo' tag, the reader reports generally a different kind of
   error.

The Scheme reports say nothing about the behavior of programs that are
grammatically incorrect, including whether an error is reported.  All
legal programs that use SRFI-10 are just as legal without it.  SRFI-10
does not extend the syntax or change the language in any way.  

   I guess you were saying that SRFI-10 was way overloaded.

I am saying that I do not understand what SRFI-10 is proposing.
It talks about read-time evaluation without providing a mechanism
for doing read-time evaluation.  Either remove the talk or add the
mechanism.
                                         -Richard