All: The following proposal was sent by Beni Cherniavsky-Paskin to the SRFI-110 mailing list. Since it proposes a massive change to the sweet-expression notation, I wanted to make sure it was also posted on this mailing list (readable-discuss).
I'm not so sure about this proposal (and to be fair, neither is the proposer!).
Even if I *loved* it, I'd hate to make a big change this late in the game.
But I want to consider all ideas fairly, and I also want everyone to be aware
of discussion items like this that would change fundamental semantics. And
it's fair to say that NOW is the time to change semantics (if we do) - not
later.
Right now I'm just mulling over this idea in my mind. I'll reply once I've
thought it through further. If anyone else has a thought, though, PLEASE speak
up. In this particular case cross-posting is probably appropriate (I hate to
see much of that, but this really does cross the goals of both mailing lists).
--- David A. Wheeler
----- Start Forwarded Message -----
Sent: Thu, 2 May 2013 01:46:16 -0700
From: Beni Cherniavsky-Paskin <c...@users.sf.net>
To: srfi-110 <srfi-...@srfi.schemers.org>
Subject: Proposal: make $ serve as GROUP, leave \ to always be SPLIT
This is kinda late to say this, and I'm not at all sure it's an
improvement. But the thought won't leave me, so better now than never...
\\'s dual duty is nagging me. Intuitively, I grasp the operators like this:
- SPLIT prevents creation of lists ("a \\ b") or at least fractures them
("a b \\ c d").
- GROUP's sole reason[*] for existence is to express a list of child lines.
- SUBLIST (usually) creates lists.
Which leads me to feel that \\'s two meanings are opposite — SPLIT is
"anti-list", GROUP is "pro-list".
=> What if we make a lone $ on a line serve as GROUP, making $ always
"pro-list"?
Then we'd write:
let
! $
! ! x foo()
! ! y bar()
! do-stuff(x y ...)
[this currently isn't legal (trailing $), and would produce a spurious (((x
...) (y ...))) level if it were legal.]
I don't really think the "pro-list vs anti-list" argument is critical; the
more important criteria are:
* Can this unify the handling of leading $ vs head $ rest?
If this can reduce us from 3 central constructs to 2, it's a major win.
If leading $ remains a special case, just subtler, maybe it's a loss.
* Is this consistent with $ in haskell? [don't know if this Q even means
anything]
Another issue I see with the current leading $ behavior is this
inconsistency:
foo (a b) ==> (foo (a b))
foo $ a b ==> (foo (a b))
(a b) ==> (a b)
$ a b ==> ((a b)) ; huh?!
foo a ==> (foo a)
foo $ a ==> (foo a)
a ==> a
$ a ==> (a) ; huh?!
In other words, I feel that since "$ ..." always produces one object
(whether atom or list), it should be exempt from wrapping in a list if "$
..." is the first thing on a line.
This implies that "$ $ $ a" ==> a. I'm not sure I love that, but that's
how "\\ \\ \\ a" works now.
[*] I've ignored the do-nothing leading \\ usage for stylisitically
indenting some things, e.g. Arc's flat if and keyword args:
if
! cond1
! \\ then1 ...
func
! kw:
! \\ arg ...
IIRC this is currently ascribed to GROUP's disappearing act, but the same
effect with \\ could also be explained as a SPLIT with nothing on one side.
Alternatively, you can drop the behavior from \\ and use $ instead:
if
! cond1
! $ then1 ...
func
! kw:
! $ arg ...
but that'd miss the symmetry that now exists with one-liner form:
if
! cond1 \\ then1 ...
func
! kw: \\ arg ...
P.S. Cosmetic points:
- We'd lose the diagonal look of \\ which felt appropriate for GROUP.
+ The remaining sense of \\ will be familiar to TeX users ;-|
Curiously, the blank-line semantics (comment = not blank) also match.
----- End Forwarded Message -----This is kinda late to say this, and I'm not at all sure it's an improvement. Â But the thought won't leave me, so better now than never...
\\'s dual duty is nagging me. Â Intuitively, I grasp the operators like this:
- SPLIT prevents creation of lists ("a \\ b") or at least fractures them ("a b \\ c d").
- GROUP's sole reason[*] for existence is to express a list of child lines.
- SUBLIST (usually) creates lists.
Which leads me to feel that \\'s two meanings are opposite â SPLIT is "anti-list", GROUP is "pro-list".
=> What if we make a lone $ on a line serve as GROUP, making $ always "pro-list"?
\\'s dual duty is nagging me. Â Intuitively, I grasp the operators like this:
- SPLIT prevents creation of lists ("a \\ b") or at least fractures them ("a b \\ c d").
- GROUP's sole reason[*] for existence is to express a list of child lines.
- SUBLIST (usually) creates lists.
Which leads me to feel that \\'s two meanings are opposite â SPLIT is "anti-list", GROUP is "pro-list".
=> What if we make a lone $ on a line serve as GROUP, making $ always "pro-list"?
Then we'd write:
let
! $
! ! x foo()
! ! y bar()
! do-stuff(x y ...)
[this currently isn't legal (trailing $), and would produce a spurious (((x ...) (y ...))) level if it were legal.]
I don't really think the "pro-list vs anti-list" argument is critical; the more important criteria are:
* Can this unify the handling of leading $ vs head $ rest?
 If this can reduce us from 3 central constructs to 2, it's a major win.
 If leading $ remains a special case, just subtler, maybe it's a loss.
* Is this consistent with $ in haskell? Â [don't know if this Q even means anything]
Another issue I see with the current leading $ behavior is this inconsistency:
foo (a b) ==> (foo (a b))
foo $ a b ==> (foo (a b))
(a b) ==> (a b)
$ a b ==> ((a b))Â ; huh?!
foo a ==> (foo a)
foo $ a ==> (foo a)
a ==> a
$ a ==> (a)Â ; huh?!
In other words, I feel that since "$ ..." always produces one object (whether atom or list), it should be exempt from wrapping in a list if "$ ..." is the first thing on a line.
This implies that "$ $ $ a" ==> a. I'm not sure I love that, but that's how "\\ \\ \\ a" works now.
[*] I've ignored the do-nothing leading \\ usage for stylisitically indenting some things, e.g. Arc's flat if and keyword args:
if
! cond1
! \\ then1 ...
func
! kw:
! \\ arg ...
IIRC this is currently ascribed to GROUP's disappearing act, but the same effect with \\ could also be explained as a SPLIT with nothing on one side.
Alternatively, you can drop the behavior from \\ and use $ instead:
if
! cond1
! $ then1 ...
func
! kw:
! $ arg ...
but that'd miss the symmetry that now exists with one-liner form:
if
! cond1Â \\ then1 ...
func
! kw:Â \\ arg ...
P.S. Cosmetic points:
- We'd lose the diagonal look of \\ which felt appropriate for GROUP.
+ The remaining sense of \\ will be familiar to TeX users ;-|
 Curiously, the blank-line semantics (comment = not blank) also match.
------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2
_______________________________________________ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
