Email list hosting service & mailing list manager

Are we done? Are other changes needed to maximize adoption? David A. Wheeler (16 Sep 2012 19:49 UTC)
Re: Are we done? Are other changes needed to maximize adoption? Alan Manuel Gloria (17 Sep 2012 00:25 UTC)
Re: Are we done? Are other changes needed to maximize adoption? David A. Wheeler (17 Sep 2012 00:52 UTC)
Re: Are we done? Are other changes needed to maximize adoption? David A. Wheeler (17 Sep 2012 01:17 UTC)
Re: Are we done? Are other changes needed to maximize adoption? David A. Wheeler (17 Sep 2012 00:30 UTC)
Re: Are we done? Are other changes needed to maximize adoption? David A. Wheeler (17 Sep 2012 01:32 UTC)
Re: Are we done? Are other changes needed to maximize adoption? Alan Manuel Gloria (19 Sep 2012 01:35 UTC)
Re: Are we done? Are other changes needed to maximize adoption? David A. Wheeler (18 Sep 2012 02:45 UTC)

Re: Are we done? Are other changes needed to maximize adoption? Alan Manuel Gloria 19 Sep 2012 01:35 UTC

On 9/18/12, Per Bothner <xxxxxx@bothner.com> wrote:
> On 09/17/2012 08:29 AM, John Cowan wrote:
>
>>> And of couple people are used to parenthesis as grouping.
>>
>> For SRFI-105 to fit nicely into Scheme, () has to work the way it works
>> in vanilla Scheme; the same is true with sweet-expressions.
>
> I was responding to "If you're allowed to *change* the syntax of Scheme
> ...",
> which means () can work the way most people not fluent in Lisp/Scheme
> expect.
>
> I think "fit *semantically* nicely into Scheme" is a good goal.
> The goal "fit *syntactically* nicely into Scheme" means you constrain
> the design too much so you no longer have a language that is appealing
> to parenthesis-phobes and others of the target community.

I think this is the difference between Q2 and the readable-lisp
project: Q2 wants to fit semantically nicely into a specific Lisplike, but
the readable-lisp project wants to fit nicely into all Lisplikes.  And the
only real commonality between Lisplikes is the *List structure*.
(they're not called List Processors for nothin'!) Lisplikes have many
very different semantics: Lisp-1 or Lisp-2, list macros or hygienic
syntaxes or vaus, dynamic or syntactic binding.  But the
representation of code in Lisplikes is the commonality: cons +
symbols + end-of-list.  And this is where the readable-lisp project
(and one of its products, SRFI-105) comes from.  Readable-lisp is a
project to make a more readable representation for list structures of
*all* kinds, be it code, data, or code of a completely different
semantics.

Sincerely,
AmkG