In the thread: "Proposal: Let's reserve some symbols "for future
syntactic purposes" in 0.3":

On 7/14/12, David A. Wheeler <dwhee...@dwheeler.com> wrote:
>
> Although I think I'm the one who started using "\" for SPLIT, I'm
> increasingly thinking it's a bad symbol choice.  The Common Lisp spec uses
> that as an escape for the next character in a symbol, and other Lisp
> implementations do the same.  It'd be better to use a symbol that doesn't
> cause so much incompatibility from the start.
>
> Of this set, I think "!" and "~" are better choices.  So you could do:
>
> myfunc
> . 1 ! 2 ! 3
>
> or maybe:
> myfunc
> . 1 ~ 2 ~ 3
>
> => (myfunc 1 2 3)
>
>
>
> If the symbol for GROUP == SPLIT, then:
> !
> . a b
> . c d
>
> or
> ~
> . a b
> . c d
>
> => ( (a b) (c d))
>
> Between the two, I have a slight affinity for "!" - it looks like a
> "separator" to start with.
>
> Thoughts? Comments?

Actually, I think I very much prefer the "\".

SPLIT has two rules, which when utilized, allow what I expect to be
four use cases:

let
. ; use case 1: extra indentation introducer
. SPLIT
. . foo bar()
. define quux()
. . nitz
. . . ; use case 2: next-line pairing
. . . :keyword
. . . SPLIT muti item
. . . . multi line expression
. . ; use case 3: line splitting / same-line pairing
. . arf() SPLIT meow()
. ; use case 4: alternative "empty line" marker
. SPLIT
. define quuux()
. . 42
. SPLIT
. SPLIT
. {quux() * quuux()}

Now, the reason why I prefer "\" is that it is a DIAGONAL line, which
serves to visually act as both a horizontal and vertical line.

So let's split by each use case:

1.  The first use case:

let
. \
. . foo bar()

looks like a line pointing to the lower left - which is where the
next, more-indented line is.  Neither ! nor ~ point correctly, so
neither is as visually appealing:

let
. !
; |
; v what's below it?
. . foo bar()

let
. ~ ; ---> what's here?
. . foo bar()

2.  The second use case:

:keyword
\ multi item expr

looks kinda like I wanted to draw an arrow like this:

:keyword
|
+--> multi item expr

in order to show the "pairing"

Now, ~ works better here I think, although \ feels like a close second:

:keyword
~ multi item expr

And ! is not visually appealing at all:

:keyword
! multi item expr

3.  The third use case:

arf() \ meow()

In this case, the \ looks almost like a vertical line.

Although ! is superior for this use case:

arf() ! meow()

Now, one *might* convincingly argue that a horizontal separator like ~
is good enough:

arf() ~ meow()

kinda like - you know - like this - where you separate clauses with -
what do they call it? - ah, em-dashes.

but in this case ! is clearly superior - and I think \ still beats ~
in this use case.

4.  The fourth use case:

define quuux()
. 42
\
\
{quux() * quuux()}

Now, it is kinda like a vertical line that points downward, to where
the next sub-expression goes.  Again, ! beats it here:

define quuux()
. 42
!
!
{quux() * quuux()}

And again, ~ might argue that it could also look good, if you squint right:

define quuux()
. 42
~
~
{quux() * quuux()}

but \ works well visually for use cases 1 and 2, and is acceptable for
cases 3 and 4.  ! doesn't work very well visually for case 1,
definitely looks weird for case 2, and works really well for cases 3
and 4.  ~ doesn't work very well for use case 1, works reasonably well
visually for case 2, and requires some twisting to work for cases 3
and 4

------

So, I still think \ is superior, at least visually.  Of course, its
use as an escape character is there for hysterical raisins, but the
escaping mechanism IMO doesn't really exploit its visual shape for its
full potential.

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

Reply via email to