Email list hosting service & mailing list manager

SRFI-110 updated (version 2013/08/07)!! Are we done?? David A. Wheeler (07 Aug 2013 11:52 UTC)
Re: SRFI-110 updated (version 2013/08/07)!! Are we done?? Mark H Weaver (19 Aug 2013 07:22 UTC)
Re: SRFI-110 updated (version 2013/08/07)!! Are we done?? David A. Wheeler (20 Aug 2013 00:22 UTC)
Re: SRFI-110 updated (version 2013/08/07)!! Are we done?? David A. Wheeler (20 Aug 2013 02:03 UTC)

Re: SRFI-110 updated (version 2013/08/07)!! Are we done?? Mark H Weaver 19 Aug 2013 07:05 UTC

Hi David,

"David A. Wheeler" <xxxxxx@dwheeler.com> writes:
> There's now a new version of SRFI-110 (version 2013/08/07), here:
>   http://srfi.schemers.org/srfi-110/srfi-110.html
>
> Are we done?!?
>
> I don't know if Mark H Weaver will be happy with it, but I've mightily
> strived to make it easier to understand, while simultaneously keeping it
> correct and rigorous, per his earlier comments.
> It ended up being an overhaul of the spec section!

I finally took a look at the new spec, and it's definitely much clearer
than before.  At this point, I have no major complaints with how you've
expressed the grammar.  Thanks for working so hard to make it so.
Thanks also for making datum comments usable as intended when used with
sweet expressions.

Having said that, I still find the rules of this notation far too
complex for my taste.  Furthermore, I'm sorry to say that I find most
of your nontrivial examples neither clear nor aesthetically pleasing,
especially where SUBLIST and/or GROUP are used in clever ways to make
the code more compact.

I believe that curly-infix is a clear winner, worthy of standardization
and wider adoption.  I'm less fond of neoteric expressions, but that
notation is also quite clear and reasonably simple.  My gut feeling
about sweet expressions is that this proposal needs more work, and that
it is unlikely to be successful in its current form.

For what it's worth, I believe that Arne Babenhauserheide's wisp
notation is a more promising approach, even after reading your
"Comparison to wisp" section.

I'm aware that these mostly subjective judgments are not something that
you can reasonably address in this SRFI, so feel free to ignore them.  I
very much appreciate all the work you've done to address my actionable
comments.

For Guile, what I'd like to do is to provide the needed hooks and
extension points in our core reader, so that both wisp and SRFI-110
(if you choose to finalize it) can be supported without having to
reimplement the entire reader from scratch.

     Regards,
       Mark