Re: unquote in quasisyntax

[Helmut Eller <eller dot helmut at gmail dot com>]

* Per Bothner [2012-02-06 20:32] writes:

> On 02/06/2012 01:20 AM, Helmut Eller wrote:
>> * Per Bothner [2012-02-06 08:21] writes:
>>
>>> Perhaps the cleanest solution is warn about the old unquote syntax
>>> *unless* srfi-72 is explicitly requested, with a require or import.
>>> Or perhaps that is overkill?  How many would like Kawa to really
>>> support SRFI-72?
>>
>> R6RS semantics should be used instead of SRFI-72.  Dybvig and the Racket
>> gang seem to write all the relevant documentation about this stuff, so
>> using #, is less surprising.
>
> I agree, but i think we should support using , for backward compatibilty,
> at least for a release or two.
>
> The options I'm considering are (in all cases #, and unsyntax work):
>
> (1) Commma/unquote while nested in quasisyntax works, but causes a
> "deprecated" warning.  In the future support might be removed.
> This is what is currently checked in.
> (2) Commma/unquote while nested in quasisyntax works.  No warning is
> emitted, or perhaps on with certain flags.
> (3) The warning is normally emitted, but doing (require 'srfi-72)
> shuts off the warning.  In the future, support for comma/unquote might
> be removed unless in the context of a (require 'srfi-72).

(1) is fine with me (3) seems like an the most flexible solution but
I don't need it. (2) seems rather useless.

>> I would like to see is that #,X is read as (unsyntax X) and #,@X as
>> (unsyntax-splicing X).  E.g. (car '#,1) should evaluate to the symbol
>> unsyntax.
>
> That would require removing support for srfi-10.  We might consider #s
> instead.  Or perhaps some other syntax for extended literals.  (I'm
> actually more motivated on figuring out a extended-string-literal syntax.)

srfi-10 and R6RS seem comically incompatible to me.  Almost as if one
was designed to rule out the other.

Helmut