On Sat, Jul 14, 2012 at 7:29 AM, Kartik Agaram <a...@akkartik.com> wrote:
>> In a simple 2-way branch, I try to cuddle the condition right after "if"
>> where possible:
>> . if iso(1 {x % 2})
>> . . 'odd
>> . . 'even
>
> Yes, I don't use the :else in that case either.
>
> ---
>
> Your other options are fine at the start, but they get ugly as the
> tests and/or branches get more complex.
>
> I don't see how you can say these cases are "easy" when you think (* a
> (+ b c)) is suboptimal :) As the expressions grow complex, either the
> tests and branches become harder to visually separate, or we have to
> do more work to keep two columns lined up, etc. Even the examples of
> cond in lisp-hints.txt are kinda all smushed together compared to say
> the explicit block delimiters that non-lispers are used to.
You know, one completely knocks-the-socks-off-your-nose idea (due to
dwheeler) is to use "." for indentation whitespace.
And I think at least some of the problems of keeping multiple columns
lined up is mitigated by this idea.
consider a complicated set of cond clauses:
cond
\
. or
. eq? foo 'bar
. eq? foo 'quux
. eq? foo 'nitz
. \ let
. . \
. . var value
. . var2 value
. . compute var var2
\
. and
. something? foo 'is-nitz
. something-else? foo 'is-bar
. \ begin
. . do-something foo
. . do-something-else foo
\
. jer jer(binks)
. \ 42
\
. #t
\ final-possible-value
So: the condition expressions have one set of . while the branch
clauses have 2. Of course, this is still herding cats, since the "."
as indentation is optional.
>
> The problem is a fundamental one: we're interleaving expressions with
> very different semantics.
Well, let's see what we can get up until July 31, which is the
targeted freeze date for 0.3 spec.
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
