[disclaimer, which perhaps I should have been adding long ago: I haven't
written any CL in years.
Nor scheme, actually, but I much prefer it to CL. I only occasionally do
pieces of emacs lisp.]
I think code with \\ at line ends would be annoying to maintain, for the
same reason multi-line #defines are in C.
When editing it's easy to omit \\ on one line and the meaning of the
following lines changes, perhaps creating a subtle bug instead of an
outright error.
Many people maintain an aligned column of \ (so you can validate it's
unbroken at a glance), but this is only practical with editor support.
Arne's leadlng dot syntax is somewhat better:
- It doesn't depend on all previous lines having unbroken.
- It's more visible at start of a line.
- In a long .-prefixed block the dot's are vertically aligned for free.
Also, I think trailing \\ would break some \\ symmetries:
a b \\ c d
and
a b
\\ c d
are the same but
a b \\
c d
wouldn't be.
Personally, I'd just use parens and/or avoid overly complex loop forms by
breaking them into steps / helper functions.
(This a Python bias — I think of loop as an [overcharged] list
comprehension, and I'm in the camp that believes list comprehensions over
3–4 lines are hard to read.
It's hard to separate this belief from python's syntax — comprehensions
suspend python's line/indentation syntax, and the leading expression in
[expr(x,y) for x ... for y ...] becomes a distant forward reference when
the whole construct is long...)
On Mon, May 13, 2013 at 3:28 PM, David A. Wheeler <dwhee...@dwheeler.com>wrote:
> I'm looking for some feedback... should sweet-expressions be adjusted to
> handle really long Common Lisp loop statements?
>
> Sweet-expressions work just great with relatively short Common Lisp loop
> statements. But here's an example from hunchentoot version 1.2.18 file
> request.lisp line 176+:
>
> (loop with buffer = (make-array +buffer-length+ :element-type 'octet)
> with content = (make-array 0 :element-type 'octet :adjustable t)
> for index = 0 then (+ index pos)
> for pos = (read-sequence buffer content-stream)
> do (adjust-array content (+ index pos))
> (replace content buffer :start1 index :end2 pos)
> while (= pos +buffer-length+)
> finally (return content))
>
> So... what should be done with really LONG loop expressions like this?
> The best approach I've found currently is to just use parens to disable
> indent processing:
> (loop with buffer = make-array(+buffer-length+ :element-type 'octet)
> with content = make-array(0 :element-type 'octet :adjustable t)
> for index = 0 then {index + pos}
> for pos = read-sequence(buffer content-stream)
> do adjust-array(content {index + pos})
> replace(content buffer :start1 index :end2 pos)
> while {pos = +buffer-length+}
> finally return(content))
>
> That actually isn't bad; you still have neoteric-expressions.
> That could be annoying, though, if the "do" body is long.
>
> Using "\\" between parameters works find if there are pairs
> (e.g., keywords paired with data), but not well with:
> with \\ content \\ = \\ make-array(0 :element-type 'octet
> :adjustable t)
>
> The one alternative approach I can think of is "\\"-at-the-end, a dropped
> proposal
> to allow line splicing if "\\" is at the end of a line with at least 1
> neoteric-expression
> is on its left. Then you can do:
> loop with buffer = make-array(+buffer-length+ :element-type 'octet) \\
> with content = make-array(0 :element-type 'octet :adjustable t) \\
> for index = 0 then {index + pos}
> ...
>
>
> So... is this a problem that needs solving? Is it adequately handled
> already?
> If not, are there suggestions for solving it?
>
> Comments welcome. I'd like to finish SRFI-110, but now's the time to know
> if there's a weakness that needs addressing.
>
> --- David A. Wheeler
>
>
> ------------------------------------------------------------------------------
> AlienVault Unified Security Management (USM) platform delivers complete
> security visibility with the essential security capabilities. Easily and
> efficiently configure, manage, and operate all of your security controls
> from a single console and one unified framework. Download a free trial.
> http://p.sf.net/sfu/alienvault_d2d
> _______________________________________________
> Readable-discuss mailing list
> Readable-discuss@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/readable-discuss
>
--
Beni Cherniavsky-Paskin
------------------------------------------------------------------------------
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d
_______________________________________________
Readable-discuss mailing list
Readable-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/readable-discuss
