Alan Manuel Gloria <[email protected]>:
> Hence my continued position: SPLIT (to support :keyword-style
> juxtaposition pairings) and ENLIST (to support (k v)-style explicit
> pairings), using two different symbols.
>
> You can drop ENLIST, maybe, because SPLIT-by-itself can do part of its
> work, at the cost of adding one vertical line, but ENLIST can't do
> SPLIT's work, which is to juxtapose an "indented" line (i.e. to cancel
> an indentation).
My (current) position:
* I agree on SPLIT, let's do it.
* I disagree on ENLIST. Every rule we add has a cost in learning/explaining,
and using up a punctuation character is a big deal (there aren't many in
straight ASCII that aren't already used). Fundamentally, I'm skeptical that
ENLIST is worth the trouble.
We already have other ways to support (k v)-style pairings. Obviously (k v)
and k(v) work, for example.
I was looking at the various "let" uses, because "let" is a commonly-used case
that causes problems with indentation syntax. The "example/streams.scm" has
for example (thanks for the example!):
. let*
. \
. promise stream-unwrap(x)
. data xforce(promise)
. { data eq? private-stream-tag }
That is pretty readable as-is, actually. But all those lines consumed by let*
for a simple set of variable assignments *is* annoying. Yet even without
ENLIST, we can handle expressions with "let*" using much less vertical space:
. let* ( (promise stream-unwrap(x)) (data xforce(promise)) )
. { data eq? private-stream-tag }
or:
. let* ( promise(stream-unwrap(x)) data(xforce(promise)) )
. { data eq? private-stream-tag }
Once you're inside (...) indentation isn't used, so you could do a lot of
variable assignments without problems for simple assignments (which they often
are). Or if you have a lot of simple assignments, in many cases, you could
just use another let, e.g.:
. let* (var1(value1))
. let* (var2(value2))
. runme()
I'm not saying that ENLIST can't be usefulo, but even with "let" I think there
are often alternatives that reduce its utility.
I do agree on SPLIT; for completeness, let me document some of the reasons why.
Obviously "SPLIT" is useful in cases where you have a pair of datums that are
short & logically related (so you'd like them on one line) but they must be at
the same level in a list.
For cases were there's a pair of datums that are not short & you need deeper
indentation processing, but want to show their relation, SPLIT is also pretty
nifty, and the rule "SYMBOL at beginning of line is ignored" is really easy to
explain. E.G., Arc's:
if
long-cond-1
\ what-to-do-if-long-cond-1-true
long-cond-2
\ what-to-do-if-long-cond-2-true
...
I was trying to come up with an alternative rule for SPLIT when stuff happens
after the SPLIT symbol on the same line. That's such an easy-to-invoke
situation that I'd like it to have a *reason* to be used. My "always creates a
list" alternative rule is at least an alternative to the SPLIT notation. But
on reflection, it's too hard to explain, *and* using explicit (...) is probably
clearer in cases like "let".
We could add ENLIST later if it turns out to be really necessary, since that'd
be a different symbol anyway.
So what do you think? Think you could be happy with SPLIT without ENLIST, and
give it a try?
--- David A. Wheeler
------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/readable-discuss
