On Wed, Aug 22, 2012 at 3:00 AM, David A. Wheeler <dwhee...@dwheeler.com> wrote:
> Here's a note about Racket's infix notation. Comments? Agree/disagree?
>
> Racket allows an infix notation of the form (a . > . b), as defined here:
> http://docs.racket-lang.org/guide/Pairs__Lists__and_Racket_Syntax.html
>
> Pros:
> - Doesn't need to use up braces {}, so it might be easier to implement in
> some Lisps which already define {}.
>
> Cons:
> - Notation is much longer and more awkward. Every infix operator adds 6
> characters, including "." characters not used in any other infix notation.
> Infix operations are a common operation, so convenience matters... an
> expression like (1 . + . 2) is far longer, and less convenient, than {1 + 2}.
> - It doesn't look like other languages or math. A human notation should be
> maximally understandable to people given what they already know. {a + b} is
> much more similar to standard notation than (a . + . b).
> - Easy to make mistakes in. If you forget a "." somewhere, you end up with
> the wrong thing. This would also make it harder to see improper lists;
> improper lists are important but rarer, so it's good to make them obvious,
> and this notation doesn't do that. The Racket documentation even goes out of
> its way to emphasize that infix convention use is unrelated to improper
> lists.. which suggests that they are easily confused.
> - We could still define prefixed f to instead allow f{a . + . b}, but it's
> still ugly.
> - We'd lose {x} as an escape mechanism. We could revert to (. x) as the
> escape mechanism, at which point dots-in-lists becomes rather busy (!).
> - It's not clear that Racket's implementation allows multiple operations,
> e.g., (a . + . b . + . c). Even if it doesn't now, that could be added. But
> this makes the notation even more unwieldy; every infix operator requires 6
> extra characters not needed by curly-infix.
>
> Even Racket users don't use it much. Its documentation says that "Racket
> programmers use the infix convention sparingly—mostly for asymmetric
> binary operators such as < and is-a?."
>
> We *could* implement the infix convention in our implementation, as a way to
> help people transition to curly-infix.
>
> We *could* switch to the "infix convention", though you can see I'm not
> excited about it. Thoughts?
Bleah.
Honestly, I first thought that curly-infix was pretty noisy (curly
braces are more ornate than parens) but they're still pretty
convenient. (foo(bar) . eq? . 'red) seems worse than { foo(bar) eq?
'red }. Despite { } being relatively noisy (due to their graphical
ornateness) I find them quite often in my own code.
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
