This page is part of the web mail archives of SRFI 108 from before July 7th, 2015. The new archives for SRFI 108 contain all messages, not just those from before July 7th, 2015.
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 (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 per@xxxxxxxxxxx http://per.bothner.com/