SRFI-108/SRFI-109 special characters
Per Bothner
(10 Nov 2012 16:51 UTC)
|
Re: SRFI-108/SRFI-109 special characters
Shiro Kawai
(11 Nov 2012 01:06 UTC)
|
Re: SRFI-108/SRFI-109 special characters
Per Bothner
(11 Nov 2012 03:47 UTC)
|
Literals vs Quasi-literals (Was: SRFI-108/SRFI-109 special characters)
Shiro Kawai
(12 Nov 2012 07:20 UTC)
|
Re: Literals vs Quasi-literals (Was: SRFI-108/SRFI-109 special characters) Per Bothner (12 Nov 2012 17:08 UTC)
|
Re: SRFI-108/SRFI-109 special characters
John Cowan
(18 Nov 2012 21:22 UTC)
|
Re: SRFI-108/SRFI-109 special characters
Per Bothner
(18 Nov 2012 21:50 UTC)
|
Re: SRFI-108/SRFI-109 special characters
John Cowan
(24 Nov 2012 06:55 UTC)
|
Re: SRFI-108/SRFI-109 special characters
Michael Sperber
(11 Dec 2012 17:27 UTC)
|
Re: Literals vs Quasi-literals (Was: SRFI-108/SRFI-109 special characters) Per Bothner 12 Nov 2012 17:08 UTC
On 11/11/2012 11:08 PM, Shiro Kawai wrote: > Srfi-10 has number of shortcomings, but most of them > come from having the true literal status---that is, > if you want to get a user-defined object by just > (read)-ing back from its external representation, you > need to run a constructor in read anyway. One possible > approach to fix it would be introducing some formal > distinction in read phase and compile/execution phase. A general mechanism where you can modify or extend the reader syntax using directives would be nice. > If you give up the true literal behavior, you're fixing > a different problem. That is perfectly fine. I just don't > want the reader of srfi-108 to be confused that it addresses > the issues of srfi-10. Absolutely. I'll try to re-phrase this, > Again, I think naming it with 'datum' or 'literal' is misleading, > for they don't behave as pure datum nor pure literal. > Maybe <extended-constructor-expression> or something?) SRFI-107 uses 'xml-constructor'. Perhaps used 'named-constructor' for SRFI-108 and 'string-constructor' for SRFI-109? -- --Per Bothner xxxxxx@bothner.com http://per.bothner.com/