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)
|
Literals vs Quasi-literals (Was: SRFI-108/SRFI-109 special characters) Shiro Kawai 12 Nov 2012 07:08 UTC
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. 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. (BTW, having <extended-datum-literal> as <expression>, not <datum>, is a wise choice to avoid another issue infecting srfi-10, which is interference with srfi-38, e.g. #0=#,(foo #0#) Gauche handles this to a certain extent, but it's pretty ugly. 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?)