From: Jonathon McKitrick
Subject: Why so few blank lines in Lisp?
Date: 
Message-ID: <1140560686.698745.142340@g47g2000cwa.googlegroups.com>
I've noticed that many other languages have generous, and sometimes
copious, amounts of blank lines as part of their accepted/suggested
style.

Yet CL seems to be more terse in comparison.  Is this because of the
functional nature, where most functions are smaller than in other
languages?

From: Eric Lavigne
Subject: Re: Why so few blank lines in Lisp?
Date: 
Message-ID: <1140562741.516433.91330@z14g2000cwz.googlegroups.com>
> I've noticed that many other languages have generous, and sometimes
> copious, amounts of blank lines as part of their accepted/suggested
> style.
>
> Yet CL seems to be more terse in comparison.  Is this because of the
> functional nature, where most functions are smaller than in other
> languages?

I put blank lines between paragraphs in an essay. Why have paragraphs
and blank lines at all? It allows you to mentally break the essay as a
whole up into smaller, easier-to-digest pieces. It also means, if you
have to walk away, that when you come back you can look for the
paragraph about some topic. None of these arguments make sense when the
essay is only five sentences long, so then I wouldn't use paragraphs
(or would only use one, depending on how you look at it). As you start
to deal with larger documents it makes sense to break it up further
into chapters and sections, perhaps giving each section a name.

Programs are the same way. The blank lines and other stylistic issues
are meant to make it easier to read. If my function is 5-10 lines long,
then it doesn't need to be broken up further. If a function is very
long, then for readability (and perhaps other reasons) I might break it
up into several smaller functions. As my programs get very large, I
might even break them up into separate files (chapters).

Out of curiosity, what particular language are you thinking of when you
say "many languages"? I don't generally get the impression that Lisp is
lacking in whitespace. In fact, it surprised me at first that Lisp
programmers would leave blank lines around a tiny defvar statement.
From: Kaz Kylheku
Subject: Re: Why so few blank lines in Lisp?
Date: 
Message-ID: <1140571201.078067.71250@f14g2000cwb.googlegroups.com>
Jonathon McKitrick wrote:
> I've noticed that many other languages have generous, and sometimes
> copious, amounts of blank lines as part of their accepted/suggested
> style.

One practice in the Lisp style is the closing of parentheses together
))))). That eliminates "quasi-blank" lines that contain only one
punctuation token.

Another observation is that a lot of Lisp code consits of heavily
nested, complex expressions in which there isn't a whole lot, if any,
sequential processing: moving on from one "statement-like" expression
to the next.

When you write such heavily compounded expressions in some mainstream
languages, it usually creates an ugly mess. As much of it is stuffed
onto one line as possible, and then it's awkwardly broken in some
ad-hoc way on various punctuators, such as low-precedence binary
operators.

For instance, nested ternary expressions in C occasionally appear like
this:

(cond1)
? (cond2)
   ? cond2consequent
   :  cond2alternate
: cond1alternate;

It's kind of Lisp-like, isn't it?

(if cond1
  (if (cond2)
    cond2consequent
    cond2alternate)
  cond1alternate)

I would not stick blank lines in the middle of the above C expression,
so why would I do it in the analogous Lisp one.

Where blank lines get added is in between top level forms, and between
blocks of statement-like expressions within (explicit or implicit)
PROGN bodies.

There are some places where you just don't add blank lines in C. For
instance

  while (x < 0)
                       /* huh? why blank? */
  {
  }

  for (iterator = get_first(obj);
                      /* What? */
       iterator != 0;
                      /* Pardon me? */
       iterator = get_next(obj, iterator)
  {
  }

  x = <big complex term>  +
                      /* ??? */
    <another big complex term>;

In general, you don't break apart statements and expressions. Lisp is
not that all that different in this regard.
From: Kenny Tilton
Subject: Re: Why so few blank lines in Lisp?
Date: 
Message-ID: <1OMKf.3879$cF5.517@news-wrt-01.rdc-nyc.rr.com>
Jonathon McKitrick wrote:
> I've noticed that many other languages have generous, and sometimes
> copious, amounts of blank lines as part of their accepted/suggested
> style.
> 
> Yet CL seems to be more terse in comparison.  Is this because of the
> functional nature, where most functions are smaller than in other
> languages?
> 

(a) yes

(b) unless (a) (where I do have a rare long function with discernible
discrete chunks, or a long hairy cond or case) I use blank lines to 
reassure me. Huge wodges of unbroken text intimidate me.

But then I do this with written text as well, trying to keep paragraphs 
small.

kenny
From: Larry Clapp
Subject: Re: Why so few blank lines in Lisp?
Date: 
Message-ID: <slrndvnli4.6c0.larry@theclapp.ddts.net>
On 2006-02-21, Jonathon McKitrick <···········@bigfoot.com> wrote:
> I've noticed that many other languages have generous, and sometimes
> copious, amounts of blank lines as part of their accepted/suggested
> style.

{
  Not to mention
  {
    lines with only
  }
  one token on them.
;)

> Yet CL seems to be more terse in comparison.  Is this because of the
> functional nature, where most functions are smaller than in other
> languages?

I think that's part of it.  The size of functions, of course, has
little to do with the language, and much to do with the programmer.
But Lisp's development cycle lends itself to small functions.  Code
little, test a little.  Where some programmers would write a hundred
line function with various comments and blank lines, a Lisp programmer
might write seventy-five lines (or twenty-five, Lisp being what it is
;) of much shorter functions, each with nary a blank line.

-- Larry
From: Tayssir John Gabbour
Subject: Re: Why so few blank lines in Lisp?
Date: 
Message-ID: <1140615230.537024.177860@z14g2000cwz.googlegroups.com>
Jonathon McKitrick wrote:
> I've noticed that many other languages have generous, and sometimes
> copious, amounts of blank lines as part of their accepted/suggested
> style.
>
> Yet CL seems to be more terse in comparison.  Is this because of the
> functional nature, where most functions are smaller than in other
> languages?

Noticed this too. Actually, it makes me think of English; I can
conceive of less blank lines than what I'm writing right now (I use
blank lines to delimit paragraphs; a terser use might be to omit blank
lines altogether). Perhaps the abstraction capabilities of Lisp allow
Lisp to have a vaguely similar amount of whitespace as English emails
and posts. You know, the extra ability to make idioms (macros),
punctuation and abbreviations (modifying the reader), etc.


Tayssir
--

Do you like the metaobject protocol?

"The medieval Scholastics distinguished two kinds of logical terms:
first intentions include words that refer to concrete things, and
second intentions refer to linguistic entities like properties and
propositions."
Sowa, _Knowledge Representation_, p. 27
From: Pascal Costanza
Subject: Re: Why so few blank lines in Lisp?
Date: 
Message-ID: <462p8qF93u2sU1@individual.net>
Jonathon McKitrick wrote:
> I've noticed that many other languages have generous, and sometimes
> copious, amounts of blank lines as part of their accepted/suggested
> style.
> 
> Yet CL seems to be more terse in comparison.  Is this because of the
> functional nature, where most functions are smaller than in other
> languages?

I don't think so. CL code is terse for other reasons - it provides you 
with a lot of rope to compress your code. For example, macros allow you 
to remove unnecessary technical details from your code and focus on the 
essential ingredients.

In general, if you can see more code on one page, you can get a better 
overview of your overall program. Increasing the vertical size of source 
code by inserting arbitary empty lines and lines with single 
punctuations is a waste of valuable space that ultimately makes it 
harder to understand your program.


Pascal

-- 
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
From: David Sletten
Subject: Re: Why so few blank lines in Lisp?
Date: 
Message-ID: <SXWKf.13838$Ou1.3202@tornado.socal.rr.com>
Pascal Costanza wrote:


>  CL ... provides you with a lot of rope to compress your code.

What a strange metaphor. Does it rely on string theory? :)

Aloha,
David Sletten
From: Pascal Costanza
Subject: Re: Why so few blank lines in Lisp?
Date: 
Message-ID: <4633ebF944pgU1@individual.net>
David Sletten wrote:
> Pascal Costanza wrote:
> 
>>  CL ... provides you with a lot of rope to compress your code.
> 
> What a strange metaphor. Does it rely on string theory? :)

No, I am still suffering from a the aftermath of a flu... ;)


Pascal

-- 
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
From: Waldek Hebisch
Subject: Re: Why so few blank lines in Lisp?
Date: 
Message-ID: <dtja4n$q7i$1@panorama.wcss.wroc.pl>
Jonathon McKitrick <···········@bigfoot.com> wrote:
> I've noticed that many other languages have generous, and sometimes
> copious, amounts of blank lines as part of their accepted/suggested
> style.
> 
> Yet CL seems to be more terse in comparison.  Is this because of the
> functional nature, where most functions are smaller than in other
> languages?
> 

I think that variation between individual programs is probably larger
then variation due to choice of language.

I did a little test using various sources scattered on my disk:

Program             total  blank blank%

GNU C               419063 60949 14.54%
GNU Pascal           56257  5159  9.17%
Linux net drivers   229455 31412 13.69%

ACL2                181977 24768 13.61%
maxima              102245 10173  9.95%
axiom                24912  2482  9.96%
mma1.6               13649  2409 17.65%
clicc                34278  3484 10.16%
sbcl                 50822  3360  6.61%
Sneps-2.5.1          37131  2630  7.08%

With the exception of Sneps where I took few directories I used sources
from one (main) directory. For C programs I counted only .c file, for
Lisp only .lisp files. Total counts are given by wc.

I looked more carefully at sbcl and sneps, since both have unusually small
percentage of blank lines, and the explanation is simple: both sbcl and
sneps put no blank line between comment and preceeding (and following) code.
Other programs normally have a blank line after a logical block of code,
many put blank lines both between and after comments. Since sbcl have
12856 lines containing ';;' and sneps has 22182 line beginning with ';'
that have profound impact on blank line count.

As an extra factor sbcl and sneps do not have blank line in block comments,
both have at least comment chars in such lines (probably a small factor
for sbcl, but significant for sneps).


-- 
                              Waldek Hebisch
·······@math.uni.wroc.pl 
From: Förster vom Silberwald
Subject: Re: Why so few blank lines in Lisp?
Date: 
Message-ID: <1140698651.253004.198020@i40g2000cwc.googlegroups.com>
Jonathon McKitrick wrote:
> I've noticed that many other languages have generous, and sometimes
> copious, amounts of blank lines as part of their accepted/suggested
> style.
>
> Yet CL seems to be more terse in comparison.  Is this because of the
> functional nature, where most functions are smaller than in other
> languages?

You would yourself no good if you will introduce blank lines into your
lisp programming style. CommonLisp and Scheme is much easier to read as
it is than lets say crap Python.

That said: do not forget to use an appropiate editor for your coding.
And don't try to overlue lets say Emacs when identing. Everything is as
good as it can be. I have seen very horrible code examples were poor
souls tried to turn their Lisp or Scheme code either into on or two
liners or some extended version with blanks line. Neither of them is
readable.

Schneewittchen
From: Rob Thorpe
Subject: Re: Why so few blank lines in Lisp?
Date: 
Message-ID: <1140708548.053995.129580@g14g2000cwa.googlegroups.com>
Jonathon McKitrick wrote:
> I've noticed that many other languages have generous, and sometimes
> copious, amounts of blank lines as part of their accepted/suggested
> style.
>
> Yet CL seems to be more terse in comparison.  Is this because of the
> functional nature, where most functions are smaller than in other
> languages?

I think it's the same in any language you write:-
*  If have small functions then you don't need many lines of whitespace
in them.
*  If you have larger functions then you generally have blocks of code
that do associated things, in this case it is useful to group them by
putting blank lines (or comments) between them.  Often comments are
more useful than blank lines, but where a comment can't say anything
useful a blank line is better.

You may have large/small functions for many reasons, language,
development method, time allowed or problem being solved.
From: Majorinc, Kazimir
Subject: Re: Why so few blank lines in Lisp?
Date: 
Message-ID: <MPG.1e67fa64a51563db9898b7@news.carnet.hr>
In article <1140560686.698745.142340
@g47g2000cwa.googlegroups.com>, ···········@bigfoot.com says...
> I've noticed that many other languages have generous, and sometimes
> copious, amounts of blank lines as part of their accepted/suggested
> style.

It is social issue. Lisp community is deffensive and tries hard 
to prove the value of Lisp on various ways, including writing 
short programs even if it is not practical. 

> 
> Yet CL seems to be more terse in comparison.  Is this because of the
> functional nature, where most functions are smaller than in other
> languages?
> 

Size of the program is inversly related to the size of the 
language and its level of abstraction. Lisp is relatively good 
at both of these... 
From: Duane Rettig
Subject: Re: Why so few blank lines in Lisp?
Date: 
Message-ID: <o0k6bmgh75.fsf@franz.com>
Majorinc, Kazimir <·····@email.address> writes:

> In article <1140560686.698745.142340
> @g47g2000cwa.googlegroups.com>, ···········@bigfoot.com says...
>> I've noticed that many other languages have generous, and sometimes
>> copious, amounts of blank lines as part of their accepted/suggested
>> style.
>
> It is social issue. Lisp community is deffensive and tries hard 
> to prove the value of Lisp on various ways, including writing 
> short programs even if it is not practical. 

I don't think it's defensiveness at all.  Blanks are just like parens,
and lispers tend to make each invisible.  So there is no defensiveness
in that area because they are not seen.  And yet, when they are "out
of place", they are most glaringly seen, and it is this distinction
between being seen and being not seen that gets lispers bent out of
shape.

But why are these syntactic characters seen when "out of place"?
And what constitutes "out of place"?

I have a completely different theory about why lispers (in this case,
CLers) write the way they do.  It has to do with a standard
representation that is output from a standard module within CL called
the pretty-printer.  Since it is standard, it has a standard way of
placing items in both code and data when it writes it (and it does
write code and data, since code is data and is often generated, and is
thus output by the pretty-printer so that the programmer can see what
the program just wrote).

Note that there are several parameterizations to the pretty-printer,
and defaults are dependent on various factors, including screen widths,
vendor's preferences, etc.  So the same code printed by one lisp may
be slightly different than code printed by another.  However, lispers
tend to still view those outputs as "the same" and "in place", since
they were printed standardly modulo the parameterizations.  Also, external
editors like emacs (which use lisp, but not CL), will make formatting of
code slightly differently than the CL pretty-printer, but we lispers
still view those formattings as ok, since it is what the standardized
tools produce.  But of course since the editors are not purely syntactic
editors, but work on text, they are more preservation-oriented than the
pretty printer, which tends to normalize all forms when output.

A couple of main areas where the pretty printer is more autocratic
than an editor like emacs is

 1. It does not suffer gratuitous blanks (this is more true for
pprint than for the emacs editor, which will not change line counts
or embedded blanks normally, but will add or subtract leading blanks)

 2. It tends to write closing parens next to each other, rather
than on separate lines (again, emacs tends not to change what had
been done normally, but keeps parens on whatever lines they were
inserted, but reformatting to the correct column).

 3. It does not carry through comments (definitely different than 
emacs, which preserves comments)

So if a newbie wants to see what a CLer will accept as good formatting,
all that has to be done is to send the form through pprint (or write
it some other way with *print-pretty* true).

>> Yet CL seems to be more terse in comparison.  Is this because of the
>> functional nature, where most functions are smaller than in other
>> languages?
>> 
>
> Size of the program is inversly related to the size of the 
> language and its level of abstraction. Lisp is relatively good 
> at both of these... 

Agreed, and I don't believe that blanks figure in one way or the
other.  The only blanks that a CLer even sees is one that is "out
of place".

-- 
Duane Rettig    ·····@franz.com    Franz Inc.  http://www.franz.com/
555 12th St., Suite 1450               http://www.555citycenter.com/
Oakland, Ca. 94607        Phone: (510) 452-2000; Fax: (510) 452-0182   
From: Majorinc, Kazimir
Subject: Re: Why so few blank lines in Lisp?
Date: 
Message-ID: <MPG.1e687c954e06c952989684@news.htnet.hr>
In article <··············@franz.com>, ·····@franz.com says...

> CLers) write the way they do.  It has to do with a standard
> representation that is output from a standard module within CL called
> the pretty-printer.  

Oh, I must admit it sounds convincing.