On 7/13/12, David A. Wheeler <dwhee...@dwheeler.com> wrote:
> Alan Manuel Gloria <almkg...@gmail.com>:
>> 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?
Yes, I did say that you could drop ENLIST, since there are a multitude
of ways to get what it means, while that's harder for SPLIT. Notice
how I don't use ENLIST at all in example/streams, even though arguably
it's clearer with ENLIST than with SPLIT, and why I haven't gone
around to implementing it (^.^)v. Still, ENLIST does have the
advantage that it takes fewer lines (unlike replacing it with SPLIT,
which requires a separate line for SPLIT and for the first
let-variable) while still retaining indentation processing (unlike
surrounding with parentheses).
On 7/12/12, Arne Babenhauserheide <arne_...@web.de> wrote:
> So yes, this would be a hack on the language (because it already
> allows using . this way), but I somehow like that. It minimizes the
> changes from regular lisp and only uses syntax elements which already
> have a special meaning in lisp - though not at the point where they
> are used.
>
> a . b → construct a cons-cel
> a
> .
> b → create a double bracket
> . (b) → pure syntactic sugar to give the code a stronger structure.
>
> As a departure from normal sweet parsing rules, “. (…)”¸ could retain the
> indenting rules - different from direct use of brackets. So
>
> if
> cond1
> . (exp1
> subexp)
>
> would correspond to
>
> (if
> (cond1)
> (. (exp1
> (subexp))
> ))
>
> Which es equivalent to
>
> (if
> (cond1)
> (exp1
> (subexp)))
>
> and
>
> if
> cond1
> exp1
> subexp
>
> -- for comparision again:
>
> if
> cond1
> . (exp1
> subexp)
>
> if
> cond1
> . exp1
> subexp
>
> … I’m not sure if I am blinded by the nice hack represented by . (…).
> The form without the brackets could be cleaner, but I can’t really
> judge that objectively right now.
>
> let
> .
> a 1
> b 2
> if
> = a 1
> . message "true"
> . message "false"
>
> If this is cleaner, the form would be:
>
> a . b → construct a cons-cel
> a
> .
> b → do a double bracket
> . b → pure syntactic sugar to give the code a stronger structure.
>
> With this, there would be only six syntax elements:
> ()"',.
>
> And () could be omitted, so the required syntax elements in sweet
> expressions would be
>
> "',.\n
>
> Adding \ for linebreaks would stay consistent with bash.
>
> Or just use . there, too, to join lines, just as it joins cons-cels:
>
> a . b → construct a cons-cel
> a
> .
> b → do a double bracket
> a .
> b → ignore a linebreak,
> . b → pure syntactic sugar to give the code a stronger structure.
>
> What is missing is splitting lines, because that would definitely
> conflict with constructing the cons-cel.
>
> So alternate: The adding dot:
>
> a . b → construct a cons-cel
> a
> .
> b → do a double bracket
> . b → pure syntactic sugar to give the code a stronger structure.
>
> And the splitting and unbreaking backslash:
>
> a \ b → split a line in two
> a \
> b → avoid a linebreak.
>
> Though this is somewhat strange, because only removing the linebreak
> in the second case gives
>
> a \ b → (a) (b)
>
> while the correct form would be
>
> a b → (a b)
>
> With the dot to avoid a linebreak that would be worse, though, because
> a .
> b → (a b)
> while
> a . b → (a . b) == valid syntax! (dangerous as no tool could warn about it)
> (though that’s the case for \ as line splitter and unbreaker, too)
>
> Best wishes,
> Arne
>
> PS: What I like the most about the . is that it is already used, so it
> does not add more syntax overhead.
>
> PPS: Sorry for being a bit chaotic here.
>
Well, it appears that some of the uses you've pointed out above for
"." are compatible with SPLIT = "." rules.
> a
> .
> b → do a double bracket
> . b → pure syntactic sugar to give the code a stronger structure.
a
SPLIT
b => (a (b))
SPLIT b => b
What isn't compatible is:
> a . b → construct a cons-cel
since:
a SPLIT b
is two expressions, a followed by b
Instead, your proposal is:
> a \ b → split a line in two
> a \
> b → avoid a linebreak.
So, using my terminology, your position is:
1. Use GROUP = ".", with the addition that GROUP-inline now means
"form a cons cell" (in the original rules, GROUP-inline was
meaningless and represented the symbol used by itself),
2. Use SPLICE = "\", with the removal of the SPLICE-at-the-beginning
rule (and the retention of the SPLICE-inline and SPLICE-at-the-eol
rule).
Is this correct?
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
