Shiro Kawai:
> My concern is actually in the "implementation dependent" part.
> I generally like specs that allows implementations to explore
> more possibilities, but in this case, it's tempting to assume it
> would work similarly as `{,x op ,y op ,z}; some implementation
> supports it and some not may cause more confusion than other
> implementation-dependent edge-case extensions.

Fair enough.  Our current implementation just uses "eq?" and requires them to be symbols.

It'd be easy for it to *say* "equal?", and recommend checking for cycles.  That does complicate the implementation slightly, though not badly. R6RS, and R7RS draft 7, have equal? check for cycles but don't say what happens if there ARE cycles :-(, which makes it hard to use portably.  R5RS and before explicitly don't claim cycle checking. For portability the sample implementation would probably have to roll its own check, to make sure it actually works widely on real systems.

Do you think it's worth supporting "equal?"?  It is slightly more complicated to implement (it's hard to beat "eq?").  However, it would be much more general, e.g., it'd allow the use of ,op.

> OTOH, I do have applications that already use {} for different
> custom semantics, and if I support C-exprs in Gauche I'd like to
> have a way to switch the lexical syntax, at least per-source-file
> basis.   It's inevitable that I have to deal with sources with
> different lexical syntax, so curly-foo convention won't work.
>
> I'd like to avoid using procedures to switch, since the timing
> that the evaluation takes effect to the reader is ambiguous,
> especially when batch-compiling and incremental compiling are
> mixed.   I have enough headache in Common Lisp.

I completely sympathize.  But it's not obvious what the alternatives would be.  Infix is such a common circumstance that it's worth burning a single character for, and they really need to be paired.  {..} is literally the only ASCII symbol pair left.  #{...} is uglier, and other implementations use that up too so it's no advantage.

> Curly-infix-read allows you to read a source with C-exprs,
> but you _have_to_ know that the source contains C-exprs beforehand.
> Same as the procedure 'load', or module imports, even if they have
> switches.

My hope in the long term is that it's just standard on any Scheme, just like supporting "(...)" is supported everywhere.  I can hope, right :-)?

> R6RS #!-switch is the closest I can think of that can make a
> source file self-descriptive about the lexical syntax it uses.
> Did you think about using something like #!c-expr ?

A switch might work, though I think the #! syntax for switches is absurd; the #! sequence is ALREADY reserved by most Unix/Linux systems, and they will not change it for Scheme :-(.

> Of course you can argue that it's Gauche's responsibility to
> provide a switch to non-standard syntax, e.g. #!gauche-curly-syntax,
> which is reasonable.

That's exactly what I'll argue.  If there's a way we can simplify transition, though, I'd love to hear it.

>  But the srfi suggests some mechanisms for
> implementations to extend c-expr (nfx and transform-mixed-infix),
> which looks to me very ad-hoc.

>  I'd rather like to hear the srfi says:
>
>   "This is C-expr: 0, 1, 2-ary and simple cases.  Other cases
>    are undefined and we don't care.  It's up to implementations what
>    they want to do in other cases by whatever underlying mechanism
>    they like.  However, when you have multiple extensions, we suggest
>    using #!c-expr and alike to make the source self-descriptive
>    and easy to exchange between implementations."

The real intent was, if it's not 0-, 1-, 2-, or simple, it returns (nfx LIST).

> > The "transform-mixed-infix" should NEVER be changed by the user, as documented in the SRFI.  That is intended as a trapdoor for future SRFIs.  Note that "transform-mixed-infix" is NOT a requirement, it's just that an implementation MAY define it.
>
> It's kind of contradictory, for in Lisp languages users and language
> developers (including SRFI designers) overlap largely.   I don't think
> it's necessary to mention a specific procedure (transform-mixed-infix)
> inside the normative srfi document.   If future srfi writers need to
> extend srfi-105, they can do so no matter whether transform-mixed-infix
> hook is provided or not.  The srfi-105 reference implementation can
> provide it, and if implementor sees it's useful then they would
> follow the convention; the future srfi writers can say "this reference
> implementation assumes the hook provided by srfi-105's reference
> implementation."

Okay, that's good advice.  We could easily do that.  In fact, I'd be glad to drop "transform-mixed-infix"; it's clearly causing confusion with no real benefit.  We certainly never use it.

So I'd propose a much simpler rule: For a mixed curly-infix list, the reader replies with "(nfx LIST)".  That is in fact the rule in the "readable" list. When we create the SRFI we thought these extras might help, but obviously not :-).  The point of the "nfx" symbol is to give application developers a chance to process it further.

--- David A. Wheeler