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.
Thanks for an interesting srfi. I prefer xml-style, for (1) starting with # makes it stand out more as an extended syntax, and (2) for something like srfi-109 we can refer to the existing XML standard when it's useful (e.g. entity reference). There's one thing that confused me, though. (Maybe because of the arrangement of the document). 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. 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. 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]) 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.