Email list hosting service & mailing list manager

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: 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?)