[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SRFI-108/SRFI-109 special characters
On 11/10/2012 05:02 PM, Shiro Kawai wrote:
There's one thing that confused me, though.
(Maybe because of the arrangement of the document).
Yes - there is a lot of information and ideas in the document,
and not always presented as clearly as it could be.
The document appears to propose a new literal syntax, for
it mentions adding new literals for new types and then
goes on to compare it to srfi-10. However, what follows
is not a syntax of literals, but a new reader syntax
of a list, with a certain assumed format and function.
(Well, it's quasi-literal, so it is not exactly about literals,
nevertheless I found the flow of discussion a bit confusing.)
The difference between literals and proposed quasi-literals
is mostly visible when they appear within literals. Srfi-10
works for those cases:
'(1 2 #,(URL "http://example.com")) => list of 1, 2 and URL object
((#,(char-code #\a) #,(char-code #\b)) (do-a-or-b x))
;; Suppose #,(char-code #\a) reads as the ascii code value
;; of #\a.
I assume srfi-108 can't be used for these contexts.
The former is of course easy:
`(1 2 `#&URL[http://example.com])
The case example doesn't seem terribly convincing. Or perhaps
it can be viewed as an argument for an "evaluating case" that
care the clauses take expressions rather than datums.
Srfi-10 can also be used as an external representation of
objects of user-defined datatypes, since if you define an
appropriate writer, you can make those objects written out
and then read back to get the object of the same type/attributes.
I assume srfi-108 doesn't work like that---if you write an
object in srfi-108 syntax and then read it back, you'll get
a list ($quasi-value$ ...), not the object of the written type.
Right. The main reason SRFI-108 defines quasi-literal rather
than true literals is covered (very tersely) in the paragraph
starting with "SRFI-10 has a number of problems": For modularity.
R6RS and R7RS are moving Scheme towards static bindings and
modules/libraries. You can important a macro from a library
but there is no support for importing reader syntax. It's
valuable to be able to import type-specific concise syntax
from a library. Another problem is that SRFI-10 doesn't
support unquoting for or all of the components so it doesn't
handle quasi-quotation, which I think is important. Finally,
the fact that SRFI-10 *does* change the reader syntax leads
to some security and control issues which it's not clear
how to deal with.
The "Readtable literals" section kind of opens the door for
implementations to make srfi-108 work like true literals, but
if that's the purpose, it needs more explanations. For
example, the resulting value of $quasi-value$ must be self-evaluating
object, otherwise the following expression will behave differently
whether the syntax is converted to objects at read-time or not.
True - there are some issues there. Readtime expansion works
best for objects that are self-evaluating. Either that, readtime
expansion would have to be context-dependent - maybe disabled
when reading by a Scheme parser, but not for a top-level call
to read. Somewhat ugly - but then I think the way Scheme and
Lisp handle quote vs evaluation is awkward to say the least.
SRFI-10 or any other read-time syntax has same issue:
#,(URL "http://example.com") needs to be a <constant>.
To allow read-time object construction, it might also be better
to mention that the value of quasi-liteal without unquoting
shouldn't be affected by the dynamic environment---it must yield
the same value whenever the quasi-literal is evaluated (it also
consistency in whether the value is constructed at macro-expansion
time or at evaluation time.)
I felt that it may be easier to mention at first that srfi-108
is really about a shorthand notation of an S-expression for
calling a constructor. It can compare to literal syntax
like srfi-10, but it would also be nice to refer to the
difference between quasi-literals and literals.
That makes sense.