Re: SRFI 105: Curly-infix-expressions

[Shiro Kawai <shiro@xxxxxxxx>]

From: "David A. Wheeler" <dwheeler@xxxxxxxxxxxx>
Subject: Re: SRFI 105: Curly-infix-expressions
Date: Mon, 27 Aug 2012 08:27:16 -0400 (EDT)

> Shiro Kawai:
>> - I think whether the following C-expr is 'simple' or not
>>   depends on implementation, correct?
>>     `{x ,op y ,op z}
> 
> Correct.  We could *require* support for this.  The "easy" way would be to require use of "equal?".

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.

>>   Having reader to recognize simple C-exprs might introduce
>>   nasty edge cases.  If macro handles transformation, the
>>   behavior would be more predictable.
> 
> No, that'd be horrible.  I don't care if the underlying reader uses macros to implement itself, that's fine.  But when (read) is done, it is *critically* important that {+ a b} produce the list (+ a b).  There are lots of "infix" systems today that generate FUNNY_SYMBOL as the first position.  That's not what an infix system is about; the point is to put the OPERATOR into the operator position, not FUNNY_SYMBOL.

Points taken.  That you'll never see funny symbols (even in
quoted or quasiquoted expressions) is certainly a great benefit.
The examples Alan gave also show advantages.

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.

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.

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 ?

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.  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 "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."

--shiro