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.)

Correct.

> 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
>
>    (case x
>      ((#,(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.
>
>     (list #&myobj[xyz])

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.
--
	--Per Bothner
xxxxxx@bothner.com   http://per.bothner.com/