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