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

Re: Splitting SRFI-10 into three?

This page is part of the web mail archives of SRFI 10 from before July 7th, 2015. The new archives for SRFI 10 contain all messages, not just those from before July 7th, 2015.

   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

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