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)
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/