Alan Manuel Gloria <>:
> 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 }
.      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:
  \ what-to-do-if-long-cond-1-true
  \ 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 
Readable-discuss mailing list

Reply via email to