On Sun, Jul 15, 2012 at 8:13 AM, Kartik Agaram <a...@akkartik.com> wrote:
>> https://sourceforge.net/p/readable/wiki/Solution/
>> "A leading quote, comma, backquote, or comma-at, followed by space or tab,
>> is a list with that operator and the following expression."
>>
>> Of course, if you think that's a bad idea, then let's discuss! This is
>> straight from SRFI-49..
>
> It's not this rule in particular, but the spec as a whole seems quite
> complex. http://www.dwheeler.com/readable/version02.html is quite
> long, and it includes this wormhole to the universe of SRFI 49, which
> the reader must also understand. It might be a useful exercise to
> inline SRFI's rules into v0.3 and try to organize them to be shorter
> and simpler. v0.2 tries to be both a tutorial and a spec, and I think
> that makes it too intimidating. Lose the motivation, assume that the
> reader is already on board by the time (s)he gets to that page, etc.,
> etc.
>
> ---
>
> GROUP doesn't seem worth the extra complexity required to explain it
> to others. If you have a list with a nested list as its first
> element.. just add parens. We don't need alternate syntax for every
> possible situation.
>
> Some of the burden of being readable must fall also to the user of our
> notation. If lists in function position are hard to read we need
> incentives to avoid them.
It's not lists in function position, it's support for the design of
let, which requires a list of lists.
let
group
var1
combine
expr1(x)
expr2(y)
expr3
{w - v}
{w + {v * z}}
var2
combine
expr1(w)
expr2(y)
expr3
extract(w)
recombine(v y x)
use var1 var2
Wart has two major differences from sweet-expressions that makes GROUP
superfluous in it:
1. It uses the Arcan let, which just assigns a single variable.
2. It allows indentation processing inside parentheses.
These two make saying "just add parens" easy.
However, sweet-expressions has the following properties:
1. It has to support a wide variety of syntaxes. So we support a
goodly number of escapes (GROUP/SPLIT) to adapt to various kinds of
syntax.
2. It disables indentation processing inside parentheses.
The following e-mail you had is somewhat telling:
On Sat, Jul 14, 2012 at 10:43 AM, Kartik Agaram <a...@akkartik.com> wrote:
>> The idea of suppressing paren-insertion inside explicit parens is a
>> good one. I had considered it, but I hadn't noticed that it allows me
>> to get rid of the single-space rule. I'm going to try that!
>
> Ok, this change is now in: http://github.com/akkartik/wart/commit/3320d257ac
>
> Judging by the line-count savings, this is a huge win. In addition,
> the description in the Readme is *much* shorter and simpler. The
> entire section on exceptions is gone.
Basically, your approach of using indentation processing inside
parenthesis is dual to our approach of including special syntax for
list-of-lists: both work to make long expressions inside let variable
bindings readable. So the comparison here is: How clear, consistent,
and flexible are the rules for indentation-inside-parenthesis compared
to no-indentation-inside-parenthesis-but-has-GROUP/SPLIT?
>
> Is sweet expressions trying to make lisp syntax familiar to
> non-lispers? With wart I wasn't trying to make the notation look
> familiar, just to make it easier to read at length. I was trying to
> keep my readers reading when they don't have the fluency to parse all
> the parens just yet.
The goal of sweet-expressions is to work with as many Lisp variants as
possible. dwheeler believes that this would help avoid the Dylan
trap, which made the surface syntax specific to the underlying
semantic: by trying out sweet-expressions on various kinds of Lisp, we
hope to make a good specifications that is decoupled from the
underlying semantics, by trying out the same surface syntax with
different actual semantics.
Scheme and CL are very similar to each other, especially in terms of
basics such as let. Arc shakes up let and cond syntax, and is a
useful yardstick for us to consider if we are getting too specific to
Scheme/CL-style let and cond.
As an aside, one thing we *still* don't support very well is CL's
loop. You're pretty much constrained to use parens for that to get
any readability.
Sincerely,
AmkG
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Readable-discuss mailing list
Readable-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/readable-discuss
