I'm concerned about # syntax.
In particular, I'm worried about # syntax being used for non-datums
(basically, comments).
I wonder if adding this to the spec would be a good idea:
<p>
If an implementation supports some way of
extending the reader syntax at all,
such as by providing a hook into the <code>#</code> reader,
then that hook <em>MUST</em> be able to signal
a non-datum (basically, a comment).
For example,
such a hook might require the convention
that the hooked procedure will return
either the empty list <code>'()</code> -
which indicates that the read-in text is a comment -
or a one-item list whose first item is the read in datum.
When an implementation of this SRFI reads a piece of text
that invokes the hook,
if the hooked procedure signals a non-datum,
it <em>MUST</em> be treated as an s-expression comment
(i.e. the scomment production above is extended to match that text).
If the hooked procedure signals a datum,
it <em>MUST</em> be treated as a possible n-expression head,
and a subsequent opening
<code>(</code>, <code>[</code>, or <code>{</code>
<em>MUST</em> be treated as an n-expression tail that will
affect that head.
</p>
Basically, I worry that people will de-facto-standardize on just
returning a datum (without any way of signalling a comment), and if
the text read in is a comment, to recurse into 'read. Recursing into
'read is problematic for an indentation processor as it has a very
rich state.
Sincerely,
AmkG
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_jan
_______________________________________________
Readable-discuss mailing list
Readable-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/readable-discuss
