Programming Style
Roy Mash
As a newbie to Lisp, I am interested in (among other things) programming
style
differences between C/C++/Java and Lisp. For instance Kantrowitz and
Margolin write,
"Don't write Pascal (or C) code in Lisp. ... Don't put a close
parenthesis on a line by itself --
this can really irritate programmers who grew up on Lisp."
I'm not so sure that this is a rational preference. So let me defend the 'C
style' and invite all
Lisp mavens to set me straight. Here is a small practice fragment I used
just to fool around:
;;; Display a list using NTH
;;; Lisp style code
(let ((L (list 'a 'b 5 'symbol -14)))
(dotimes (i (length L))
(print (nth i L))))
;;; Same code - C style
(let
(L (list 'a 'b 5 'symbol -14))
)
(dotimes (i (length L))
(print (nth i L))
)
)
Why prefer the C style? Well, say I later want to add more forms to the
DOTIMES body. With the Lisp Style I have to analyze what belongs to
what before inserting the form between the 2nd and third closing
parentheses -- Easy to mess up, even in relatively simple code like this.
With the 'C style', however, the indentation and parenthesis placement
does the work for me, allowing me to add new forms or delete existing ones,
1 per line, to the DOTIMES body (or to the LET body) without worrying
about parentheses. The same goes for adding new bindings or removing old
ones.
One goal of programming style is to facilitate code changes. In this regard,
the C style weds function and form in a way the Lisp style does not.
Roy Mash
cbbr...@hex.net
If you need to add additional code inside the DOTIMES body, you just
need to stick the cursor at what _appears_ to be an appropriate spot,
and press enter.
If you got the right spot, then the cursor will sit at the spot you
expect, thusly:
(let ((L (list 'a 'b 5 'symbol -14)))
(dotimes (i (length L))
(print (nth i L))
))
^--- Cursor sits here
If you positioned the cursor wrongly, then you'll get one of the
following:
(let ((L (list 'a 'b 5 'symbol -14)))
(dotimes (i (length L))
(print (nth i L)
)))
(let ((L (list 'a 'b 5 'symbol -14)))
(dotimes (i (length L))
(print (nth i L)))
)
It's pretty obvious, by inspection, which position is the right one;
if you get it wrong, it's easy enough to c-u c-b Enter or c-u c-f
Enter to fix it up.
There's a much more important benefit to the "traditional approach:"
your indentation appproach results in three lines of code expanding to
fill up 9 lines of screen space.
For me to buy a screen three times as large as the one I've got would
likely cost me the price of a Lexus automobile.
The notion of wasting that much screen space because I _might_,
_someday_, want to add additional code is what strikes me as nearly
criminal.
It's just _idiocy_ to waste lines for ONE PARENTHESIS.
--
(concatenate 'string "cbbrowne" "@ntlug.org")
http://vip.hyperusa.com/~cbbrowne/unix.html
Pound for pound, the amoeba is the most vicious animal on earth.
Kent M Pitman
> Why prefer the C style? Well, say I later want to add more forms to the
> DOTIMES body. With the Lisp Style I have to analyze what belongs to
> what before inserting the form between the 2nd and third closing
> parentheses -- Easy to mess up, even in relatively simple code like this.
Not if you're using a good text editor. Emacs has commands that hop over
balanced parens, that tell you when parens match, that open up new space
on a fresh line and indent to the right place at the same time. It is
VERY hard to mess up if you're using a competent Lisp-savvy text editor.
> One goal of programming style is to facilitate code changes. In this regard,
> the C style weds function and form in a way the Lisp style does not.
You're using the wrong text editor. We all see this as a goal, too, but
we also like to see a reasonable amount of code on a screen and the C style
means we only see about a half to a third as much code per screen, while
buying us (who use good text editors) none of the advantages you want, since
we already have them.
PLEASE check out Emacs and its Lisp mode, or an equivalent editor such as
comes on the Lisp Machine (Zmacs), in Macintosh MCL (FRED), or in Xanalys
LispWorks (boringly called the Editor).
Duane Rettig
> Hi,
>
> As a newbie to Lisp, I am interested in (among other things) programming
> style
> differences between C/C++/Java and Lisp. For instance Kantrowitz and
> Margolin write,
> "Don't write Pascal (or C) code in Lisp. ... Don't put a close
> parenthesis on a line by itself --
> this can really irritate programmers who grew up on Lisp."
> I'm not so sure that this is a rational preference. So let me defend the 'C
> style' and invite all
> Lisp mavens to set me straight. Here is a small practice fragment I used
> just to fool around:
>
> ;;; Display a list using NTH
> ;;; Lisp style code
> (let ((L (list 'a 'b 5 'symbol -14)))
> (dotimes (i (length L))
> (print (nth i L))))
The nice thing about the above code is that the parens are essentially
invisible. You don't worry about them, and you get into the habit of
ignoring them.
> ;;; Same code - C style
> (let
>
>
> (L (list 'a 'b 5 'symbol -14))
> )
> (dotimes (i (length L))
> (print (nth i L))
> )
> )
The major problem with the above code is that it is hard to see the
actual code for all of the parentheses screaming "look at me!". The
parens are definitely not invisible in the above code.
> Why prefer the C style? Well, say I later want to add more forms to the
> DOTIMES body. With the Lisp Style I have to analyze what belongs to
> what before inserting the form between the 2nd and third closing
> parentheses -- Easy to mess up, even in relatively simple code like this.
Again, you're looking at parentheses. Don't do that. Look at expressions
instead. If your editor is lisp-savvy, it will allow you to traverse into,
out of, and across expressions very easily.
> With the 'C style', however, the indentation and parenthesis placement
> does the work for me, allowing me to add new forms or delete existing ones,
> 1 per line, to the DOTIMES body (or to the LET body) without worrying
> about parentheses. The same goes for adding new bindings or removing old
> ones.
The C style is a line-oriented style. Even source-level debuggers don't
tend to see with any finer granularity than the line. In Lisp, the
expression is the preferred unit of syntax, not the line.
> One goal of programming style is to facilitate code changes. In this regard,
> the C style weds function and form in a way the Lisp style does not.
No, the C style weds line-orientation to the code. If you look at your
C style lisp code above, you have essentially made it more line-by-line
editable by breaking up the major expressions so that they are
on their own lines. Code changes are easy to make in an expression-oriented
indentation if you learn how to manipulate expressions in your editor as
well as you already know how to manipulate lines.
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 du...@Franz.COM (internet)
Erik Naggum
> One goal of programming style is to facilitate code changes. In this regard,
> the C style weds function and form in a way the Lisp style does not.
The C style was designed to work well with ed, the standard editor, on a
teletypewriter. The style of Fortran was similarly inspired by punched
cards. The style of Lisp was inspired by full-screen editors with
commands to move around in expressions: up, down, forward, backward.
This is just one of the large number of benefits of having a delimiter at
both the beginning and end of an expression, at all levels of expression.
Coming from the C language family, this will take a while to register as
a feature, but once you understand, you will regard the idea that the
line is the most natural division as incredibly backward, almost
retarded. Despite being much older than C, the Lisp family did a large
number of things right that the C/Unix folks still have not grasped the
significance of. Or maybe it is _because_ it is so much older. ///
Wade Humeniuk
> > ;;; Lisp style code
> > (let ((L (list 'a 'b 5 'symbol -14)))
> > (dotimes (i (length L))
> > (print (nth i L))))
>
> The nice thing about the above code is that the parens are essentially
> invisible. You don't worry about them, and you get into the habit of
> ignoring them.
>
As a testament to what Duane said (I still remember vividly learning Lisp)
you eventually do not even see the parens (except when you have to). It
takes some getting used to but your brain will eventually see the "code"
automatically. But you have to be patient and _let_ it happen.
Wade
Frank A. Adrian
> Despite being much older than C, the Lisp family did a large
> number of things right that the C/Unix folks still have not grasped the
> significance of. Or maybe it is _because_ it is so much older. ///
Actually, it's the other way 'round. Lisp _got_ older because it did a
large number of things right! It is the original language that has
improved on a large number of its successors. In fifty years, Lisp will
still be around.
faa
Friedrich Dominicus
> >
> > ;;; Display a list using NTH
> > ;;; Lisp style code
> > (let ((L (list 'a 'b 5 'symbol -14)))
> > (dotimes (i (length L))
> > (print (nth i L))))
>
> The nice thing about the above code is that the parens are essentially
> invisible. You don't worry about them, and you get into the habit of
> ignoring them.
>
> > ;;; Same code - C style
> > (let
> >
> >
> > (L (list 'a 'b 5 'symbol -14))
> > )
> > (dotimes (i (length L))
> > (print (nth i L))
> > )
> > )
>
> The major problem with the above code is that it is hard to see the
> actual code for all of the parentheses screaming "look at me!". The
> parens are definitely not invisible in the above code.
has not seen it, suggests that is very unreadable. In fact I feel it
hurts my eyes...
The error? Now a missing ( before L
Regards
Friedrich
Alain Picard
> Hi,
>
> Here is a small practice fragment I used
> just to fool around:
>
> ;;; Display a list using NTH
> ;;; Lisp style code
> (let ((L (list 'a 'b 5 'symbol -14)))
> (dotimes (i (length L))
> (print (nth i L))))
>
When you're a bit more experienced, your eyes will
see the above code as:
let L (list 'a 'b 5 'symbol -14)
dotimes i (length L)
print (nth i L)
You know it's right because of the _indentation_, not
because of where the parens match. (The fact that
the indentation is right because the parens match is
a fortunate/planned accident.)
Now you know where Python got it from. They just took
the next step and dropped the parens. :-)
Erik Naggum
> As a testament to what Duane said (I still remember vividly learning Lisp)
> you eventually do not even see the parens (except when you have to). It
> takes some getting used to but your brain will eventually see the "code"
> automatically. But you have to be patient and _let_ it happen.
This is actually no different than any other language. To what extent do
C programmers _see_ its punctuation? Commas, semicolons, braces, parens,
brackets, etc, all convey meaning immediately without been obsessed about
as such. Getting them right can be a significant hurdle as you struggle
with the syntax. Once you stop seeing the & and instead think "address",
you have got the hang of it. Perl hackers have mastered this technique.
The reason many people who have learned C prefer to continue on the C
branch of evolution is that they found the process of learning all that
syntax quite _painful_. This is especially true for parentheses in C.
You only need them in expressions that cross a fairly high complexity
threshold and you can get rid of them by simplifying the expressions.
Lisp is chock full of parentheses, with no way to get rid of them -- if
you simplify your expressions, you end up with _more_ parentheses. The
"syntax = pain" equation in most C programmer's heads translates to a
desire to reduce the cost of learning a new language by trying to adapt
it to the pain they have already been through. However, once you grok
the parentheses in Lisp, they are _not_ painful. In fact, they are so
much more liberating and enabling and downright _friendly_ that you would
just _love_ to have similar tools available in every other language you
use. This is why the "economy of syntax" in C is really a "poverty of
syntax" and the perceived verbosity of Lisp translates to a wealth of
opportunity. Like so many other things in life, you rarely get _only_
what you optimize for. ///
Eric Moss
>
> "Roy Mash" <Roy_...@ci.sf.ca.us> writes:
>
> > ;;; Display a list using NTH
> > ;;; Lisp style code
> > (let ((L (list 'a 'b 5 'symbol -14)))
> > (dotimes (i (length L))
> > (print (nth i L))))
>
> When you're a bit more experienced, your eyes will
> see the above code as:
>
> let L (list 'a 'b 5 'symbol -14)
> dotimes i (length L)
> print (nth i L)
Indeed! It took me forever to read lisp code a few months ago, but my
lil' ol' pea brain has adapted and now everything else looks silly. Now
I think that using newlines for delimiting phrases is a false economy.
> Now you know where Python got it from. They just took
> the next step and dropped the parens. :-)
I hope you mean ;) rather than :).
:)
Actually, having written tens of thousands of lines of Python, I have
decided that Guido was in error to use indentation (a la fortran?) to
group code. It looks nice when the code is in final, presentable form,
but ONLY in the short, neat examples Pythoners use to show how nice it
is...
While I know that short functions are preferable, sometimes I can't
reasonably avoid more lines in a function than will fit on one screen.
In Python, I found I couldn't get the indentation correct near the
bottom of the function because there was a lot of nesting. I couldn't
easily see (or remember) if I needed to unindent one level or three.
Worse, when editing code and changing the structure, emacs, with no
consistent delimiter to determine nesting level, could only guess, and
usually guessed wrong. It really slowed down prototyping. In a book or
in an email exchange on the subject, Python looks so clean, but getting
from blank page to finished code was much more tedious than with a
uniformly delimited language like lisp.
I would relegate (sounds harsher than I intend) Python to the status of
"way nicer than Perl, but still a wannabe lisp". In every aspect,
unfortunately.
Eric
--
US Supreme Court hearing 00-836
GEORGE W. BUSH, Petitioner, v. PALM BEACH COUNTY CANVASSING BOARD
Justice (Scalia?) to Mr. Klock (representing Katherine Harris):
20 and therefore, I guess, whether we win, whether your side,
21 the side you're supporting wins or loses, it doesn't
22 change that, and I guess that's moot, but my question is,
Wade Humeniuk
"Erik Naggum" <er...@naggum.net> wrote in message
news:32062592...@naggum.net...
> * "Wade Humeniuk" <hume...@cadvision.com>
> > As a testament to what Duane said (I still remember vividly learning
Lisp)
> > you eventually do not even see the parens (except when you have to). It
> > takes some getting used to but your brain will eventually see the "code"
> > automatically. But you have to be patient and _let_ it happen.
>
> This is actually no different than any other language. To what extent
do
> C programmers _see_ its punctuation? Commas, semicolons, braces,
parens,
> brackets, etc, all convey meaning immediately without been obsessed
about
> as such. Getting them right can be a significant hurdle as you struggle
> with the syntax. Once you stop seeing the & and instead think
"address",
> you have got the hang of it. Perl hackers have mastered this technique.
This goes even farther to written language in general. I learned to write
some Japanese in my early adult years. At first the characters were just
disjoint symbols and I struggled in attempting to read words, let alone
sentences. Over time, with practice, I began to "see" words, with meaning,
and then began to see sentences. If I had continued I am sure that I would
eventually have been fluent in reading phonetic Japanese.
Since this discussion has began I have been looking at my Lisp code trying
to fathom how my mind is really working. I find that my attention first
moves to the symbols in the code then I (very) quickly bound the groups of
symbols into expressions with the parens. Because there are expression
delimiters at the end and the beginning of an expression I seem to be able
to start "anywhere" within a complex expression and quickly work my way
backwards or forwards or even jump around to get the gist of what is going
on. This way of looking at "code" also extends into how I seem to write
Lisp code. When I start to write a function I usually start with just
(defun funcname (some-variables) then jump into the middle of the function
and write from the inside out. If I encounter something too difficult to
write in place I will just write a higher level expression of what I what to
do and either carry on or go and write the higher level expression function.
The operative word that seems to be popping up here is "expression". The
ability to see an expression, by quickly determining its bounds, and then
determine its meaning.
Going back to the original posters comments, by putting parens on seperate
lines you reduce the ability to quickly determine the bounds of an
expression.
Wade
Eric Dahlman
[snip]
Hi Roy,
In any programming language there is a point where the model of the
programmer meets that of the machine. The level of that interface
determines what the two can "discuss." The currency of C and Unix is
characters and lines. This is the level at which the programmer and
the machine interact and there is a rich set of C tools for this type
of interaction, cpp, vi, grep, perl, ad infinitum.
The problem with the C approach is that lines and characters are not
good at representing structure. Cpp only replaces one string with
another, vi is just a front end to a line editor, grep's operation is
intimately tied to a 2D array of characters.
In contrast to this lisp adopts a different level of abstraction by
basing everything on s-expressions. This allows for a much more
powerful set of tools which understand this structure.
* The macro system can perform arbitrary transformations on this
structure and not just substitutions. This is more power than
most can comprehend, it certainly makes my head spin.
* I can have a "dialogue" with my editor at a semantically
meaningful level of abstraction. Not just lines and characters.
* It is possible to search for objects with _context_ as well as
identity. This is embodied in thing like destructuring-bind, code
walkers and even XSL.[1]
One of the biggest complaints coming from non-lisp languages is that
there are all of these irritating parentheses. That is a concession
which is made to be able to express structure. Lisp could be defined
entirely in terms of graphs with nary a paren in sight and it would
still be lisp. Other languages have made another tradeoff by adopting
a "more" human friendly syntax for expressing their structure within
the context of a 2D array of characters. They have sacrificed the
ability to have a useful dialogue with the computer about the
structure of the code. One has to remember that these languages were
developed in an environment where interaction was expensive and
difficult so I think that it was a good tradeoff.
I for one would go insane writing lisp using a punch card reader,
Fortran or Cobol for all their warts would be a much better choice.
Similarly, if I was using a teletype or glass-tty I would write in C
or a similar language, but for god sakes we are in the 21st century
now.
> Why prefer the C style? Well, say I later want to add more forms to
> the DOTIMES body. With the Lisp Style I have to analyze what belongs
> to what before inserting the form between the 2nd and third closing
> parentheses -- Easy to mess up, even in relatively simple code like
> this.
Other people have replied and said that you should use a lisp aware
editor and that is very important. It goes back to the level of
discourse, in C you are communicating characters and lines to the
machine vi is totally adequate for this. Lisp and editing lisp is
about structure; you need an editor which will allow you to edit and
interact the structure of your program.
<Start emacs advocacy>
First In XEmacs[2] I always have the following set:
(setq paren-mode 'sexp)
This makes emacs display the s-expression in a different face. Mine
adds a subtle yellow highlight to the background when the parens match
and a red one when the don't.[3] Like other posters have mentioned you
tend to not see the parens after a while, but I find that that only
really works for code which is formatted correctly (my way that is
;-)). The highlighting visually indicates the structure of the code it
can be seen as part of the dialogue between you and the editor. The
editor understands the structure of your code let it help you.
Whith sexp highlighting and good bindings for backward-sexp,
forward-sexp, kill-sexp, and the like any lisp code is easily grokked
even that with that nasty C style indenting ;-).
In order to simplify my life I made that annoying windows key on my
keyboard into a Super key and put all my lisp stuff under there.
There are other key bindings for all of this stuff but I don't have
the time to look them up, M-x will tell you what any given function is
bound to after executing it anyway so you can track them down in your
own emacs.
Here are my bindings:
S-right - forward-sexp
S-left - backward-sexp
S-up - backward-up-list
;; This jumps back to before the paren which
;; started this list (foo bar baz)
;; to^ from^
S-down - down-list
;; moves just past the next '(' "entering" the list.
S-k - kill-sexp
S-t - transpose-sexp
S-y - yank
The above are generally useful so I have them in the global keymap
In just lisp mode I also have
[ - insert-parentheses
;; This inserts a () and puts the cursor between them.
] - move-past-close-and-reindent
;; This effectively closes the current sexp started with '['
;; above. It moves the next closing paren into the correct
;; place and moves the cursor to the next line. I'm
;; thinking of moving this to 'enter'
C-q [ and C-q ] will insert the []'s if I still need them in lisp mode.
> With the 'C style', however, the indentation and parenthesis
> placement does the work for me, allowing me to add new forms or
> delete existing ones,
Again your editor must help you here. The funny thing is that I do
lots of lisp and C programming and am continually frustrated that
c-mode does not give me semantically useful editing commands like I
have gotten used to with lisp. Lines and characters are not the
structure of my program.
> 1 per line, to the DOTIMES body (or to the LET body) without
> worrying about parentheses. The same goes for adding new bindings or
> removing old ones.
Again with a good editor this is easier in Lisp.
> One goal of programming style is to facilitate code changes. In this
> regard, the C style weds function and form in a way the Lisp style
> does not.
Here I have to strongly disagree, both with the simple case like you
mentioned and harder things. With emacs you can make all of those
simple c-like changes easily. Furthermore, larger structural changes
are easier in lisp, I am constantly making large scale transformation
with a couple of key strokes. These are not possible in C since the
syntax is generally not uniform. I find many times that I am adding
extra {}'s to my C code just to allow me to treat parts of it like
s-expressions.
Sorry for the long rant. I have been scarred from having too many
people (and students) complain about how hard lisp is while using
*pico*!!!! to edit their programs. Programming is a dialogue between
man and machine it has the potential to be very collaborative, but
both parties need to speaking on the same level. The level of C is
lines of characters while Lisp operates at the higher level of graphs
and objects rendered as s-expressions. Choose your tools accordingly.
Have fun,
-Eric
Footnotes:
[1] This applies since XML is really just a bad syntax for sexps.
[2] I assume it works in GNU Emacs also but I haven't tried.
[3] This is actually most helpful in C and similar languages where one
could have a reasonable chance of typing ( ... ].
Christian Lynbech
Frank> Actually, it's the other way 'round. Lisp _got_ older because it did a
Frank> large number of things right!
I like the argument, but I am not really sure it says very much. The
opposite claim, a language that doesn't do large number of things
correctly will not get old, seems hard to defend.
I can think of a number of languages that only seems to have gotten
some (perhaps even just a few ?) things right that also seems pretty
old (FORTRAN, COBOL, pascal and PL/1 just to name a few).
But undeniably, IMHO, no language has ever gotten as many things right
as LISP :-)
On a related note, it seems to me that diversity of programming
languages was much larger in the begining of programming, if you
compare languages such as FOTRAN, LISP, COBOL and APL.
For the past decade or two, mainstream programming languages seems
trapped in the Algol tradition. Are this the effect of teaching
trapped within the same tradition, modern programmers being mentally
lazy and accept only what seem to improve upon wellknown tradition, or
are the Algol clan just better at marketing their products?
------------------------+-----------------------------------------------------
Christian Lynbech | Ericsson Telebit, Skanderborgvej 232, DK-8260 Viby J
Phone: +45 8938 5244 | email: christia...@ted.ericsson.dk
Fax: +45 8938 5101 | web: www.ericsson.com
------------------------+-----------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
- pet...@hal.com (Michael A. Petonic)
Dorai Sitaram
Eric Dahlman <er...@lossage.org> wrote:
>
>Other people have replied and said that you should use a lisp aware
>editor and that is very important. It goes back to the level of
>discourse, in C you are communicating characters and lines to the
>machine vi is totally adequate for this. Lisp and editing lisp is
>about structure; you need an editor which will allow you to edit and
>interact the structure of your program.
>
><Start emacs advocacy>
You make a good case for having an
s-expression-friendly editor but emacs is hardly the
only game in town for that. There is no need to
include emacs in the price of entry into Lisp
programming. A lighter editor like vim (or any other
vi) is also very good at navigating
s-expressions.
What some Lispers seem to like about emacs is the
ability to run Lisp in an emacs window, but that
wasn't the advantage you were citing.
--d
glauber
[...]
> Going back to the original posters comments, by putting parens on seperate
> lines you reduce the ability to quickly determine the bounds of an
> expression.
Quickly, easily and, most important for me, unambiguously!
g
glauber
[...]
> Actually, having written tens of thousands of lines of Python, I have
> decided that Guido was in error to use indentation (a la fortran?) to
> group code. It looks nice when the code is in final, presentable form,
> but ONLY in the short, neat examples Pythoners use to show how nice it
> is...
I agree. I tried Python a few years ago and liked it, but not enough
to move away from Perl. :-)
Using indentation to convey syntax is a step backwards because it
confuses form and meaning.
It's also a problem for more pratical reasons because of editors like
vi, which insist in using tabs to indent code. Mixing tabs and spaces
is a mess. To make it worse, in most of the Unix shops i worked,
programmers will use
:set ts=4
or (horrors!) :set ts=3
to change the tab width.
So using indentation works, as long as the source code is in good
shape, as long as everybody follows the same conventions for tabs and
tab width, as long as it's a world slightly more perfect than the one
i've been living in.
With Lisp (and C, and even Perl), if the indentation is good great! If
not, you can easily use a tool to fix it, and NO MEANING IS LOST.
Having expressed my personal opinion above, let me add that Python is
a fine language and the good people who give so much of their time to
implement it as free software deserve nothing but praise.
g
Roy Mash
> It's pretty obvious, by inspection, which position is the right one;
> if you get it wrong, it's easy enough to c-u c-b Enter or c-u c-f
> Enter to fix it up. --browne
> Not if you're using a good text editor. Emacs has commands that hop over
> balanced parens, that tell you when parens match, that open up new space
> on a fresh line and indent to the right place at the same time. It is
> VERY hard to mess up if you're using a competent Lisp-savvy text editor.
--Pitman
There is no text editor of which I am aware in which it is easier to
position the cursor to make insertions and deletions in the middle
of a line rather than inserting and deleting entire lines.
> we also like to see a reasonable amount of code on a screen and the C
> style means we only see about a half to a third as much code per screen
--Pitman
> The notion of wasting that much screen space because I _might_,
> _someday_, want to add additional code is what strikes me as nearly
> criminal. --browne
There are trade-offs here. I agree the C-style wastes valuable screen space.
To some extent this is offset by the advent of 17" and 19" screens allowing
for smaller fonts. Of course if you really want to save space, you'll just
forget about indentation and linebreaks altogether! Presumably this
trade-off is not worth it, even for laconic-minded Lispers.
IMHO both of you minimize the advantages of C-style. From 20 odd years of
programming I can say it is a virtual certainty that with a project of any
moderate size I will be constantly adding and deleting lines from logical
subsections of code. For me the ease of these modifications is worth the
sacrifice of screen space.
Another advantage to the C-style that I neglected to mention is the ease
with which you can comment out lines for debugging purposes. With the Lisp
style, at least for those final lines with endless close parentheses, you
need to jump through those <c-u c-b Enter or c-u c-f> hoops to do this, and
then rejoin the lines when your done.
RMash
Raymond Wiker
> > we also like to see a reasonable amount of code on a screen and the C
> > style means we only see about a half to a third as much code per screen
> --Pitman
>
> > The notion of wasting that much screen space because I _might_,
> > _someday_, want to add additional code is what strikes me as nearly
> > criminal. --browne
>
> There are trade-offs here. I agree the C-style wastes valuable screen space.
> To some extent this is offset by the advent of 17" and 19" screens allowing
> for smaller fonts. Of course if you really want to save space, you'll just
> forget about indentation and linebreaks altogether! Presumably this
> trade-off is not worth it, even for laconic-minded Lispers.
> IMHO both of you minimize the advantages of C-style. From 20 odd years of
> programming I can say it is a virtual certainty that with a project of any
> moderate size I will be constantly adding and deleting lines from logical
> subsections of code. For me the ease of these modifications is worth the
> sacrifice of screen space.
I take it that your 20 years of programming is in C and
similar languages. Some people in this newsgroup have more than 20
years experience in Lisp programming, and are quite happy with the
"canonical" formatting of Lisp code.
Anyway, you are *not* adding/deleting lines of C code. More
likely, you are adding/deleting C statements, which happen to occupy
an integral number of lines. Adding/deleting Lisp forms *is* easier
than this, as long as your editor is capable.
> Another advantage to the C-style that I neglected to mention is the ease
> with which you can comment out lines for debugging purposes. With the Lisp
> style, at least for those final lines with endless close parentheses, you
> need to jump through those <c-u c-b Enter or c-u c-f> hoops to do this, and
> then rejoin the lines when your done.
I use #| / |# or #+nil for this purpose. In fact, if you use
#+nil, you can comment out an entire form by inserting text at a
single place - in C/C++ you'd have to edit at two places.
--
Raymond Wiker
Raymon...@fast.no
Duane Rettig
> I respond to both Messrs Browne and Pitman here:
>
> > It's pretty obvious, by inspection, which position is the right one;
> > if you get it wrong, it's easy enough to c-u c-b Enter or c-u c-f
> > Enter to fix it up. --browne
>
> > Not if you're using a good text editor. Emacs has commands that hop over
> > balanced parens, that tell you when parens match, that open up new space
> > on a fresh line and indent to the right place at the same time. It is
> > VERY hard to mess up if you're using a competent Lisp-savvy text editor.
> --Pitman
>
> There is no text editor of which I am aware in which it is easier to
> position the cursor to make insertions and deletions in the middle
> of a line rather than inserting and deleting entire lines.
Heighten your awareness. If you don't use emacs/xemacs, then start. If
you do use it, then start asking someone who knows better how to make such
insertions and deletions.
I'll not participate in a "how many keystrokes does it take" type of
discussion between line orientation and expression orientation.
However, my intuition and experience tells me that it is at least
as easy to insert and delete expressions as lines, and possibly even
easier.
> > we also like to see a reasonable amount of code on a screen and the C
> > style means we only see about a half to a third as much code per screen
> --Pitman
>
> > The notion of wasting that much screen space because I _might_,
> > _someday_, want to add additional code is what strikes me as nearly
> > criminal. --browne
>
> There are trade-offs here. I agree the C-style wastes valuable screen space.
> To some extent this is offset by the advent of 17" and 19" screens allowing
> for smaller fonts. Of course if you really want to save space, you'll just
> forget about indentation and linebreaks altogether! Presumably this
> trade-off is not worth it, even for laconic-minded Lispers.
Why laconic? I don't remember the quote exactly, but I believe Einstein
advised us to make things as simple as possible, but no simpler. I think
lispers might agree with this philosophy. Thus, removing all linebreaks
and whitespace is of course not part of the lisp style. However, the
wasted space of the C style is not as simple as possible, and thus subject
to screen-space optimization.
> IMHO both of you minimize the advantages of C-style. From 20 odd years of
> programming I can say it is a virtual certainty that with a project of any
> moderate size I will be constantly adding and deleting lines from logical
> subsections of code. For me the ease of these modifications is worth the
> sacrifice of screen space.
I can assure you, having come from an Algol-style language background myself,
that it should not have take you 20 years to learn how to manipulate lisp
expressions! Provided, of course, that you actually _want_ to learn how to
do so.
> Another advantage to the C-style that I neglected to mention is the ease
> with which you can comment out lines for debugging purposes. With the Lisp
> style, at least for those final lines with endless close parentheses, you
> need to jump through those <c-u c-b Enter or c-u c-f> hoops to do this, and
> then rejoin the lines when your done.
Not true. It is not necessary to touch the parens in order to comment an
expression.
Before:
(defun foo ( ... )
(flet ...
(let ...
(bar bas)
(frazzle gorp
glop gleep))))
After:
(defun foo ( ... )
(flet ...
(let ...
(bar bas)
#+ignore (frazzle gorp
glop gleep))))
I might sometimes add a line break before the frazzle call, in order to
keep the same indentation, but the parens at the end need not be
disturbed at all.
Kent M Pitman
>
> Another advantage to the C-style that I neglected to mention is the ease
> with which you can comment out lines for debugging purposes. With the Lisp
> style, at least for those final lines with endless close parentheses, you
> need to jump through those <c-u c-b Enter or c-u c-f> hoops to do this, and
> then rejoin the lines when your done.
No, you do not. Usually you find the beginning of the exprssion that ends
in that soup of parens and do c-m-f to find the other end of it. Since
often the start of that expression is the start of the same line, the extra
cost to find the right place is one keystroke, plus one more (linefeed)
to get to a new line, properly indented. This possibility of
occasionally having to do this two keystroke sequence buys you a tight
visual display the rest of the time and is well worth it. See example
at end of this post.
(defun foo (x)
(cond ((zerop x) 1)
(t (* x (foo (- x 1) 7)))))
Suppose I want to comment out the (- x 1) starting from the head of the
expression.
c-n c-m-f m-b # | m-f | # [8 keystrokes total]
Result:
(defun foo (x)
(cond ((zerop x) 1)
(t (* x (foo (- x 1) #|7|#)))))
I type upwards 70 words a minute. That's about 1 word (5 keystrokes)
per second. That means I can touch-type tha above edit in 2 seconds.
In C, you can't use expression motion commands so you can only touch-type
line replacement, not expression replacment.
What about a more complicated edit in that light? I've written the other
kind of factorial with two args and don't like the arg order.
(defun bar (x n)
(cond ((zerop x) n)
(t (bar (* x n) (- x 1)))))
Fixing this in any infix language is work because you have to point with
the mouse. In Emacs lisp-mode I write (starting from cursor at head of defun)
c-e end of line
m-b backward word
m-t exchange words
c-s ( b ESC search for "(b"
m-f forward word
c-m-f forward lisp expression
c-m-t exchange lisp expressions
[10 keystrokes total, pretty sloppy of me]
or
c-e end of line
m-b backward word
m-t exchange words
c-m-e end of definition
m-b backward word
c-m-u up lisp expression
c-m-t exchange lisp expressions
[8 keystrokes--ah, much better]
or
m-3 m-f forward 3 words
c-m-t exchange lisp expressions
c-m-e end of definition
c-r ( ESC search backward for "("
c-m-t exchange lisp expressions
[again 8 keystrokes]
or even if i'm clumsy and plodding
m-f m-f m-f forward word, thrice
c-m-t exchange lisp expressions
c-n c-n down two lines
c-m-f forward lisp expression
c-m-t exchange lisp expressions
[again 8 keystrokes, would have been 7 if i'd thought to use
m-3 m-f on the first line]
So again, basically the edit takes literally 2 seconds. Result:
(defun bar (n x)
(cond ((zerop x) n)
(t (bar (* x n) (- x 1)))))
Suppose I want to rewrite that COND as an if starting from the revised
form above with cursor at the start of the defun and not assuming a
command that does that (which some Emacs variants have):
(defun bar (n x)
(cond ((zerop x) n)
(t (bar (* x n) (- x 1)))))
c-n down line
m-f forward word
m-Backspace delete word
i f insert "if"
c-f forward char
c-d delete "("
c-m-f c-m-f forward 2 lisp expressions
c-d delete ")"
m-f forward word
c-m-k kill lisp exprssion forward
c-m-u up lisp expression
c-m-k kill lisp exprssion forward
c-y m-y paste last kill, replace last paste with previous kill
tab properly indent current line
[17 keystrokes is 4 seconds]
Note I haven't even talked the value of being able to do this as a keyboard
macro. Consider the definition:
(defun foo (x)
(case x
(1 (quote (um uma)))
(2 (quote (dois duas)))
(3 (quote (três)))
(4 (quote (quatro)))
(5 (quote (cinco)))
(6 (quote (seis)))
(7 (quote (sete)))
(8 (quote (oito)))
(9 (quote (nove)))
(10 (quote (dez)))))
Suppose you want to add '(muitos muitas) in an otherwise clause. I
also want to upgrade this to use single-quote at the same time, and to
use the style of case where you put parens around the case
options. Cursor initially at the head of the expression.
c-n c-n down 2 lines
c-x ( begin keyboard macro definition
m-m move to non-whitespace start of line
c-f forward char (over paren)
( insert "("
m-f forward word
) insert ")"
m-d delete word forward, including the intervening "(" before it
c-f forward char
' insert "'"
c-m-f forward lisp expression
c-d delete ")"
c-n down line
c-a start of line (positioned for next macro execution)
c-x ) end keyboard macro definition
c-9 c-x e do keyboard macro 9 times
c-p up line
c-m-f forward expression [THIS IS WHAT STARTED THE DISCUSSION]
linefeed newline + tab
Type an otherwise clause, such as:
(otherwise '(muitos muitas))
Ignoring the number of keystrokes in the otherwise clause once you're
in place to type it, since that will be the same in all text editors,
that's 24 keystrokes or 5 seconds to make this edit correctly. It
takes more time to type in the 28 chars in my suggested otherwise clause.
Total time, 11 seconds.
(defun foo (x)
(case x
((1) '(um uma))
((2) '(dois duas))
((3) '(três))
((4) '(quatro))
((5) '(cinco))
((6) '(seis))
((7) '(sete))
((8) '(oito))
((9) '(nove))
((10) '(dez))
(otherwise '(muitos muitas)))
That's a pretty substantial edit and I bet vi would have trouble making
it quite so fast. Note, too that it accomodated programmatically irregular
data like the different indentation of (1) and the extra spaces in the
first two clauses, and the different line lengths throughout.
Note further that the "cost" of the parens being on
the same line was the cost of locating the line plus c-m-f linefeed
(two keystrokes, or 1/2 second) in exchange for an extra screen line.
And then there's the value of having a programmable editor so you can teach
it (by adding new defuns in the same session or by an init file or library)
to do new things on a named command or even single keystroke.
Eric Dahlman
> In article <tz4r8um...@flatt.cs.colostate.edu>,
> Eric Dahlman <er...@lossage.org> wrote:
> >
> >Other people have replied and said that you should use a lisp aware
> >editor and that is very important. It goes back to the level of
> >discourse, in C you are communicating characters and lines to the
> >machine vi is totally adequate for this. Lisp and editing lisp is
> >about structure; you need an editor which will allow you to edit and
> >interact the structure of your program.
> >
> ><Start emacs advocacy>
>
> You make a good case for having an
> s-expression-friendly editor but emacs is hardly the
> only game in town for that. There is no need to
> include emacs in the price of entry into Lisp
> programming. A lighter editor like vim (or any other
> vi) is also very good at navigating
> s-expressions.
That is true, I am guilty of over generalizing here. As I understand
it vim, jed and the like are all capable of similar things. I cannot
say exactly what since what I know is only hearsay.
> What some Lispers seem to like about emacs is the
> ability to run Lisp in an emacs window, but that
> wasn't the advantage you were citing.
I was getting a little long winded so I figured I had best quit when I
did. What you say is very true about running lisp in an emacs window,
it is very powerful. Many people, myself included, really like the
ability to incrementally compile and load changes into the running
lisp as we are editing. The avoidance of the whole
compile-link-run-debug cycle has given me countless hours of my life
back.
However, I would also like to point out that running lisp in an emacs
buffer also allows lisp and the running program to participate in the
collaborative dialogue I mentioned in my last post. This is where the
"emacs way" is a real win when working in an introspective language
like lisp. If I change a function I can ask lisp who calls the
function and edit those functions also.[1] Lisp can tell me about the
arguments to my functions as I edit and help navigate the inheritance
graph for my classes. Again the point is that I can interact with the
system on a higher semantically meaningful level rather than on the
level of strings in files.
Ultimately, all of the features of emacs which I am extolling are
available in some form for other tools and other languages to varying
degrees. Vim is a great example, I have met people who do basically
everything I do in emacs with lisp in vim with python. Choose your
poison...
To bring this post back to the original poster's problem, he was
trying to shoehorn lisp into a line & string structure since this is
what he was familiar with. He did not know how to communicate with
his computer about the more powerful s-expression. My meta-point is
that if something is overly painful you are doing something wrong.
Computer science and the common lisp community in particular is full
of really smart (and appropriately lazy) people. They are not martyrs
or masochists; none of them would be willing to do something overly
painful for long. If you are then you are doing something wrong.
Don't just dismiss those around you who do not seem to be suffering as
lunatics, they probably just know how to avoid or handle the problem
you are having.
-Eric
Footnotes:
[1] This requires something like xref which isn't in the ANSI spec
but I consider to be part of Lisp anyway. You can get similar
results from tags but these lose in cases when the use is not
textually visible, for instance if it is hidden inside a macro.
To be fair not all xrefs are created equal some have varying
abilities to see through macros and the like.
cbbr...@hex.net
> #+ignore (frazzle gorp ...)
It's apparently possible to learn something every day. That is a
_slick_ way of eliminating an s-exp...
--
(reverse (concatenate 'string "gro.gultn@" "enworbbc"))
http://vip.hex.net/~cbbrowne/linuxdistributions.html
From a UK local newspaper, the Horsham Friday-Ad:
"Parachute for sale, once used, never opened, small stain."
Bijan Parsia
[snip]
> I agree. I tried Python a few years ago and liked it, but not enough
> to move away from Perl. :-)
>
> Using indentation to convey syntax is a step backwards because it
> confuses form and meaning.
Syntax *is* form (semantics is meaning), and indentation (in
Python) doesn't *convey* syntax, it *is* syntax.
> It's also a problem for more pratical reasons because of editors like
> vi, which insist in using tabs to indent code.
[snip]
This seems akin to saying that "Parens are a problem for more practial
reasons because of editors like MS word which don't have parens
balancing."
In other words, I'm not quite sure how "there are tools and practices
which don't work well with indentation" even if they are *common* tools
and practices, works as a practical argument. Clearly, such practices and
tools are the *wrong ones* for working with Python, just as having a
non-parens balancing editor (at a minimum) is the *wrong* tool for writing
Lisp.
Cheers,
Bijan Parsia.
Roy Mash
Thanks much for the 'long rant'. I appreciate your man-machine
interface commments.
I do want to make clear, however, that I did not intend to compare
the benefits of C and Lisp as programming languages. My concern was
with programming style (eg placement of closing parentheses), not
programming substance.
- Here I have to strongly disagree, both with the simple case like you
- mentioned and harder things. With emacs you can make all of those
- simple c-like changes easily.
The 'changes' I had in mind -- deleting/inserting/commenting out code --
are common to all programming languages. One style question to ask is:
what use of white-space makes these programming tasks easier?
I claim that if it is reasonably possible to isolate a syntactic 'chunk'
-- ie a stretch of code you could comment out or delete without
syntactically
breaking the program -- on a single line, then you ought to do so,
purely as a development tool.
The only relevant counter-argument I have heard to this so far is that my
suggestion takes up more screen space. It surely does -- in both C and Lisp.
So if I became convinced that, as a general rule, that the benefits
of saving screen space outweighed the benefits of ease of
deleting/inserting/commenting out code then I suppose I should
start writing my C code along these lines:
for (int i =0; i < x; ++i)
{ <...>
<...>
for (int j =0; j < y; ++j)
{ <...>
<...>
for (int k =0; k < z; ++k)
{ <...>
<...>}}}
On the other hand, fearing I might be ostracized by other
C programmers, I might resist the change on sociological
grounds. Just as I find myself now tempted to manage Lisp
whitespace the Lisp way -- not because it is the best
functional choice, but because, well ... who wants to make
other programmers <vomit> <wretch>, or be labelled
criminal, or worse?
cheers,
Roy
Wade Humeniuk
For awhile I did the parens on an extra line trick. You know what? I
stopped! It did not take long. If you want to do it, go ahead. All your
arguments aside, you will write code in the style that makes you feel
comfortable. Putting the extra lines with parens in is a symptom of C
thinking because you see the program as a list of statements, not as one big
expression (which is the result of combining and nesting a number of smaller
expressions). I think a good Lisp function is like a natural language
paragraph, a C function is like a list of assembler statements.
Just do it! (In Lisp)
Your arguments about code layout smack of avoiding programming in Lisp.
Code it first then format it. In Lisp you can easily write a code formatter
for yourself!
Wade
Dorai Sitaram
Kent M Pitman <pit...@world.std.com> wrote:
>[other keystroke counts deleted]
Out of curiosity, I tried the above edit in vim to see
just how poorly it stacks up against emacs.
jj down 2 lines
qa begin keyboard macro def
e move to 1st left paren
a( add a left paren
<esc> back to normal mode
e move past case tag
a) add a right paren
<esc> back to normal
w move right to start of (quote
ce' replace it with '
<esc> back to normal
lx eat the next space
%x go to end of clause and eat a right paren
0j go to next line
q end keyboard macro def
9@a call macro 9 times
%a add after end of (10) clause
<ret> insert newline
This is followed by the insertion of (otherwise
'(...)), which is not counted since equivalent in all
editors.
The vim keystrokes are 6 more than Pitman's 24. Still,
the individual keystrokes are all simpler to type than
the many c-, m- and c-m- keychords used in the emacs
version, so it's quite possible that a hypothetical
70-wpm vim typist wouldn't lag substantially
behind Pitman.
--d
Kaz Kylheku
This is way too much work. Using the same editor, Vim, here is how it is
done. First enter this:
(defun foo (x)
(case x
((1) '())
Now, with the cursor on the third line, record this keyboard macro:
qaYp^Aq
where ^A stands for Ctrl-A. Then repeat ten times: 10@a.
That's it! You now have
(defun foo (x)
(case x
((1) '())
((2) '())
((3) '())
((4) '())
((5) '())
((6) '())
((7) '())
((8) '())
((9) '())
((11) '())
Now just go down the column of '() and insert the Spanish. Change the
(11) into 'otherwise' with c%otherwise<ESC> and terminate the nesting.
Kaz Kylheku
This is way too much work. Using the same editor, Vim, here is how it is
done. First enter this:
(defun foo (x)
(case x
((1) '())
Now, with the cursor on the third line, record this keyboard macro:
qaYp^Aq
where ^A stands for Ctrl-A. Then repeat ten times: 10@a.
That's it! You now have
(defun foo (x)
(case x
((1) '())
((2) '())
((3) '())
((4) '())
((5) '())
((6) '())
((7) '())
((8) '())
((9) '())
((10) '())
Kent M Pitman
> In article <9kumv2$nss$1...@news.gte.com>, Dorai Sitaram wrote:
>
> >Out of curiosity, I tried the above edit in vim to see
> >just how poorly it stacks up against emacs.
I accept this result as "comparably well". I really didn't mean this
to be turned into a vim vs emacs issue. See remarks below.
> This is way too much work. Using the same editor, Vim, here is how
> it is done. First enter this: [...] Now just go down the column of
> '() and insert the Spanish. Change the (11) into 'otherwise' with
> c%otherwise<ESC> and terminate the nesting.
Creation of new code wasn't the assignment. Editing was.
The transformation of code already in your buffer from one form
to another.
(It was Portuguese by the way.)
And this WASN'T a rant about Emacs-vs-VIM so please desist. Such a
discussion will run pointlessly forever and I'm not interested.
This was a defense of why Lisp does not make it difficult to do
editing. If you are asserting that my code shows that it IS difficult
to do editing of code in Lisp, then we have an issue worth talking
about at length. Otherwise, you are merely underscoring my point,
which is that Lisp programmers are NOT at an editing disadvantage
and are almost surely at an editing ADVANTAGE.
I used Emacs as an example of this, since the original poster seemed
to be using some editor in which he felt things had to be on separate
lines to be easy to edit.
Duane Rettig
> The 'changes' I had in mind -- deleting/inserting/commenting out code --
> are common to all programming languages. One style question to ask is:
> what use of white-space makes these programming tasks easier?
> I claim that if it is reasonably possible to isolate a syntactic 'chunk'
> -- ie a stretch of code you could comment out or delete without
> syntactically
> breaking the program -- on a single line, then you ought to do so,
> purely as a development tool.
I would be able to agree with this statement if you were only to leave
out the "on a single line" phrase. Your insistence on line-orientation
is the sticking point. Everything else you say is perfectly agreeable.
Let me try one more tack:
C is inherently line oriented. Debuggers tend to work on a line-by-line
basis (and indeed if more than one statement is given on a line, the
two statements are indistinguishable to the debugger. Also, C compilation
errors are called out with line numbers. In fact, many languages have this
characteristic, which is probably one reason why line-orientation is so
ingrained in people's minds.
Lisp is however, definitely _not_ line-oriented. When you debug lisp
programs, you tend to look contextually at the code surrounding the
error. Also, when you compile a file, line numbers are usually not
given. In fact, if you compile a function which you've just typed in
to the top-level, line numbers are pretty meaningless.
> The only relevant counter-argument I have heard to this so far is that my
> suggestion takes up more screen space. It surely does -- in both C and Lisp.
There have been other arguments given. Screen space optimization is
perhaps relevant, but it is not so very important; certainly not
important enough to make a change. What does become important enough to
change the style is that it is _easier_ to edit expressiopn-by-expression
in lisp, rather than line-by-line. You have a lot of experience in
editing line-by-line. And since C is a line-oriented language, I wouldn't
want to see you change your editing sytle for C. However, try editing lisp
on an expression-by-expression basis. It may surprise you how much
easier it is after, say, a couple of weeks to a month, to edit lisp
programs expression-wise than line-by-line, and thus the grouping of
parens will simply come naturally as a side-effect of that editing
style.
Kaz Kylheku
>k...@ashi.footprints.net (Kaz Kylheku) writes:
>
>> In article <9kumv2$nss$1...@news.gte.com>, Dorai Sitaram wrote:
>>
>> >Out of curiosity, I tried the above edit in vim to see
>> >just how poorly it stacks up against emacs.
>
>I accept this result as "comparably well". I really didn't mean this
>to be turned into a vim vs emacs issue. See remarks below.
>
>> This is way too much work. Using the same editor, Vim, here is how
>> it is done. First enter this: [...] Now just go down the column of
>> '() and insert the Spanish. Change the (11) into 'otherwise' with
>> c%otherwise<ESC> and terminate the nesting.
>
>Creation of new code wasn't the assignment. Editing was.
>The transformation of code already in your buffer from one form
>to another.
I see.
>And this WASN'T a rant about Emacs-vs-VIM so please desist. Such a
>discussion will run pointlessly forever and I'm not interested.
I'm not interested either, and if I were, I'd take it over to comp.editors.
>This was a defense of why Lisp does not make it difficult to do
>editing.
Which I believe.
>If you are asserting that my code shows that it IS difficult
>to do editing of code in Lisp, then we have an issue worth talking
>about at length.
Not my position at all.
Robert Gonzalez
Erik Naggum wrote:
> * "Roy Mash" <Roy_...@ci.sf.ca.us>
> > One goal of programming style is to facilitate code changes. In this regard,
> > the C style weds function and form in a way the Lisp style does not.
>
> The C style was designed to work well with ed, the standard editor, on a
> teletypewriter. The style of Fortran was similarly inspired by punched
> cards. The style of Lisp was inspired by full-screen editors with
> commands to move around in expressions: up, down, forward, backward.
The FORTRAN and C inspirations ring true, but full screen editors did not come
into fashion until a significant amount of time after McCarthy invented Lisp
(circa 1960). I wonder, was it just a lucky inspiration?
rg
Kaz Kylheku
>Note I haven't even talked the value of being able to do this as a keyboard
>macro. Consider the definition:
>
>(defun foo (x)
> (case x
> (1 (quote (um uma)))
> (2 (quote (dois duas)))
> (3 (quote (três)))
> (4 (quote (quatro)))
> (5 (quote (cinco)))
> (6 (quote (seis)))
> (7 (quote (sete)))
> (8 (quote (oito)))
> (9 (quote (nove)))
> (10 (quote (dez)))))
>
>Suppose you want to add '(muitos muitas) in an otherwise clause. I
>also want to upgrade this to use single-quote at the same time, and to
>use the style of case where you put parens around the case
>options.
Also, here we can point out another advantage: that Lisp can treat Lisp
code as data and operate on it. So to change from (quote X) notation
to 'X, I would just quote the whole form, and pump it through the Lisp
reader, so that it spits it out in its canonical form.
(DEFUN FOO (X)
(CASE X (1 '(UM UMA)) (2 '(DOIS DUAS)) (3 '(TRÊS)) (4 '(QUATRO))
(5 '(CINCO)) (6 '(SEIS)) (7 '(SETE)) (8 '(OITO)) (9 '(NOVE)) (10 '(DEZ))))
Adding parens to the case labels can be also be done as a Lisp function
which processes a form recursively, looking for case statements and
applying a transformation to their elements. E.g.
(defun ensure-parens-around-cases (case-form)
(cond
((null case-form) nil)
((not (listp case-form)) case-form)
((eql (first case-form) 'case)
(add-parens-around-cases case-form))
(t (cons (ensure-parens-around-cases (first case-form))
(ensure-parens-around-cases (rest case-form))))))
(defun add-parens-around-cases (case-form)
(list (first case-form) (second case-form)
(mapcar #'add-parens-around-case (cddr case-form))))
(defun add-parens-around-case (one-case)
(if (or (eql (first one-case) 'otherwise) (not (atom (first one-case))))
one-case
`((,(first one-case)) ,@(rest one-case))))
;; test case
(ensure-parens-around-cases
'(defun foo (x)
(case x
(1 (quote (um uma)))
(2 (quote (dois duas)))
(3 (quote (tres)))
(4 (quote (quatro)))
(5 (quote (cinco)))
(6 (quote (seis)))
(7 (quote (sete)))
(8 (quote (oito)))
((9) (quote (nove))) ;; test for not adding redundant parens
(10 (quote (dez)))
(otherwise '(muitos muitas)))))
--->
(DEFUN FOO (X)
(CASE X
(((1) '(UM UMA)) ((2) '(DOIS DUAS)) ((3) '(TRES)) ((4) '(QUATRO))
((5) '(CINCO)) ((6) '(SEIS)) ((7) '(SETE)) ((8) '(OITO)) ((9) '(NOVE))
((10) '(DEZ)) (OTHERWISE '(MUITOS MUITAS)))))
Imagine trying to do the same thing for, say, the C language: write C
that performs some precise transformation on C code.
Kaz Kylheku
> retarded. Despite being much older than C, the Lisp family did a large
> number of things right that the C/Unix folks still have not grasped the
> significance of.
Or other communities of folks, to be fair. It's quite peculiar how the
Lisp community has all kinds of insights into all kinds of things,
but have been largely ignored for decades. Why is that? Ineffective
advocacy? Or are the concepts just too difficult to grasp?
What did you think about Lisp before you started using it? How and why
did you get started?
I got into Lisp when I came across convincing advocacy, which stated
facts about the amazing things you can do in Lisp. But I think that
understanding and being impressed by the advocacy required experience
in computing; a newbie might not catch what the fuss is about.
For example, if someone tells you that you can write clean, seamless
code-transforming macros that can compute things rather than merely
substitute arguments into replacement text, this is might not register
as significant, unless you have already spent much time carving macros
with a blunt instrument like the C preprocessing language, and experienced
first hand how hard it was to create clean extensions to the language.
Kent M Pitman
> >And this WASN'T a rant about Emacs-vs-VIM so please desist. Such a
> >discussion will run pointlessly forever and I'm not interested.
>
> I'm not interested either, and if I were, I'd take it over to comp.editors.
Phew! (Sorry for sounding snappy. Just wanted to nip that path in the bud
before it ran out of control.)
> >This was a defense of why Lisp does not make it difficult to do
> >editing.
>
> Which I believe.
>
> >If you are asserting that my code shows that it IS difficult
> >to do editing of code in Lisp, then we have an issue worth talking
> >about at length.
>
> Not my position at all.
That's good. It's hard to know what a truly minimal set of keystrokes
would be. Maybe there's some fractal or huffman-coded editor out
there waiting to be written that can do it in way fewer, but beyond
such creative techniques it's hard to imagine where much more
optimization could come from. Indeed, the use of domain-directed
pre-package commands is very close to analogous to compression
technology, and the large body of emacs users functions as a vast
neural net doing the choice of strings for the compression table, so I
guess it's not that surprising that the result is of fairly high
quality.
(In reverse I've sometimes suggested that it would be cool to use
compression technology to choose good "function" boundaries in
languages like postscript that are about optimizing the moral
equivalent of keystrokes (token stream rather than keystroke stream).
I suppose a similar overseer clamped onto emacs might "discover"
interesting command sequences that were candidates for keyboard
commands. If anyone ever tries any of those projects I'd be very
curious to hear the outcome.)
Kent M Pitman
> In article <32062266...@naggum.net>, Erik Naggum wrote:
> > retarded. Despite being much older than C, the Lisp family did a large
> > number of things right that the C/Unix folks still have not grasped the
> > significance of.
>
> Or other communities of folks, to be fair. It's quite peculiar how the
> Lisp community has all kinds of insights into all kinds of things,
> but have been largely ignored for decades. Why is that? Ineffective
> advocacy? Or are the concepts just too difficult to grasp?
For small programs that don't require Lisp's "deep" understanding of things,
it's hard to make the case that you need Lisp. C works as well in the
arena of "hello world"and friends, so the other design issues in Lisp
dominate--e.g., the fact that it doesn't generally compile static or
dynamic modules that link with other systems, the fact that its syntax
is unusual, the fact that its core datatypes are quite different, etc.
It's hard to make the case that someone who is faced with using C will be
ill-served by writing "hello world" in C, and it's easy to take potshots
at Lisp at this point. So traditionally Lisp has ceded this ground to
other languages and said "Look, for small programs, just about any language
will work. Come back and find us when your programs get bigger."
However, this has two severe disadvantages: (1) it loses contact with
the person so that when it's time for them to fail with the other language,
you aren't there to say "ready to return?" and (2) people get used to doing
things a certain way and tend to push their use of something they are
familiar with far beyond the point they properly should have changed over
due to "practice effects". Then when they do change, it's typical to seek
something similar on the common but often wrong assumption that a minimal
change is best. Because the issues like syntax, modular composition,
and datatype continue to make Lisp look "less similar" than other alternatives,
Lisp continues to lose.
Dr. Amar Bose of MIT (creator of Bose speaker systems) confronted this
over and over. In a talk to the MIT Enterprise Forum of Cambridge a
few years back (see http://www.mitforumcambridge.org/fall98recap/lunch.html )
he remarked on how his customers and sales people have forever had
trouble with the fact that his speakers aren't really like other
speakers. They keep thinking of those differences as problems. He
finally came up with the catch phrase "better implies different".
That is, "It is impossible to do anything better if it isn't
different." A lot of people simply don't expect this, nor even accept
it once it's pointed out.
> What did you think about Lisp before you started using it? How and why
> did you get started?
>
> I got into Lisp when I came across convincing advocacy, which stated
> facts about the amazing things you can do in Lisp. But I think that
> understanding and being impressed by the advocacy required experience
> in computing; a newbie might not catch what the fuss is about.
Yes. I think this is true.
> For example, if someone tells you that you can write clean, seamless
> code-transforming macros that can compute things rather than merely
> substitute arguments into replacement text, this is might not register
> as significant, unless you have already spent much time carving macros
> with a blunt instrument like the C preprocessing language, and experienced
> first hand how hard it was to create clean extensions to the language.
He might not believe you even if he has done this because (1) he doesn't
want to admit he's wasted a lot of time needlessly or (2) he has puzzled
hard on this problem and so convinced himself that it can't be made
better that he simply thinks you are lying or deluded.
Christian Nybų
> (In reverse I've sometimes suggested that it would be cool to use
> compression technology to choose good "function" boundaries in
> languages like postscript that are about optimizing the moral
> equivalent of keystrokes (token stream rather than keystroke stream).
> I suppose a similar overseer clamped onto emacs might "discover"
> interesting command sequences that were candidates for keyboard
> commands. If anyone ever tries any of those projects I'd be very
> curious to hear the outcome.)
What is such an analysis (or synthesis?) called in AI literature?
--
chr
Eric Dahlman
> Eric,
>
> Thanks much for the 'long rant'. I appreciate your man-machine
> interface commments.
I'm happy it had more value than just reducing my stress level ;-)
> I do want to make clear, however, that I did not intend to compare
> the benefits of C and Lisp as programming languages. My concern was
> with programming style (eg placement of closing parentheses), not
> programming substance.
That is fair, I'll play inside that fence.
> - Here I have to strongly disagree, both with the simple case like you
> - mentioned and harder things. With emacs you can make all of those
> - simple c-like changes easily.
>
> The 'changes' I had in mind -- deleting/inserting/commenting out
> code -- are common to all programming languages. One style question
> to ask is: what use of white-space makes these programming tasks
> easier?
This is a very reasonable question. One thing which needs to be kept
in mind though is that given style should provide some additional
utility which not already present.
> I claim that if it is reasonably possible to isolate a syntactic 'chunk'
> -- ie a stretch of code you could comment out or delete without
> syntactically breaking the program -- on a single line, then you
> ought to do so, purely as a development tool.
I agree completely, for C, in the case of Lisp am afraid that I of a
different mind. Lets examine the benefits in the C case to see how
well they carry over to Lisp.
As an example lets consider one of the benefits of C style indentation
which you cite, "it is easy to elide" It is very easy to comment out
a line in C your style, simply add a "//" to the beginning of the
line.[1] This technique implies that "}"s should be on there own lines
and that only one statement should be on a line since it is impossible
to ignore the first without ignoring the second.
Going back to the man-machine thing this is a case of being able to
easily communicate something to the computer, "ignore this X". When
your world of discourse is lines and characters communicating "ignore
the rest of this line" is a very easy thing to say. Since there is no
way to directly "discuss" the structure of a C program embedding this
structure into what you can discuss is the next best thing. What is
happening is you as the programmer are manipulating your program
metaphorically; lines stand in for statements in the absence of the
ability to directly discuss the latter.
Given the "vocabulary" available to you for communicating with the
machine in the C tradition this is really the only sane way to go. I
will even admit to choosing to write lisp this way under extreme
duress[2] and it was the right thing to do at the time.
In the case of lisp we again have the advantage of being able to
communicate our intentions about the structure of our program to the
machine without couching them in metaphorical terms. We just say
ignore this form, the way I do this is with #+nil I think Duane used
#+ignore which may be a little less idiomatic. The result is that I
can easily tell lisp to ignore a statement, variable definition, or
even a value.
(let ((a 10)
#+nil(b 5) (c 4))
(setf foo (+ a #+nil b c))
#+nil
(setf bar 42))
In lisp I am able to directly communicate my intentions. The is no
need to move (c 4) to another line in order to preserve the one-line
one-statement mapping. Similarly, I can leave the closing paren of
the let on the same line as the elided (setf bar 42) without fear of
eliminating the trailing ')'. Another plus for the lisp way is the
fact that #+nil can span lines with no problem so #+nil(defun... can
nuke pages of code. Now, I can't argue the difficulty of typing
"#+nil" over "//" there is a shift and three extra characters ;-)
I hope that I have shown that at least in the case of eliding text no
additional utility is gained by placing individual forms on their own
lines. At this point I have knocked down the strawman I set up,
whoopdedoo. Honestly, I believe any similar utility based
justification fo the C style of indentation for lisp programs would
suffer a similar fate.
> The only relevant counter-argument I have heard to this so far is that my
> suggestion takes up more screen space. It surely does -- in both C and Lisp.
Here I will be more subjective in my reasoning. In the case of C I
think that one of the major uses of whitespace is specifically to map
language constructs into lines. In the absence of any way to directly
address the structure of the code this is a good hack to gain some
expressiveness via the line ~ statement metaphor. The structure of a
lisp program is directly available for manipulation so such a hack is
not necessary. With this in mind any arguments on this point will
basically be subjective.
My subjective opinion is that C indenting of Lisp programs is *icky*!
Of course as with any good opinion I have a set of rationalizations
which I think lend support to my position.
* Everything, including white space has a cost. A general
rule would seem to be don't use it if you don't have to. For a C
program whitespace adds utility for lisp it doesn't.
* Lisp programs are more nested than C programs, so a larger portion
of space would be wasted. Several idioms used in lisp lead to
huge amounts of nesting: with-macros, let bindings, directly
using return values in enclosing function calls. Expand more
than some toy examples in C style and I'll wager the symbol
density is much lower than comparable C code.
* Appeal to authority: All the geezers around here like dense code
since they have been around the block a couple of times I'd
guess that there was some benefit to it.
* Me-tooism: I just did it that way cause the people I worked with
did it that way. Apparently I have been successfully
indoctrinated since I like dense code too.
> So if I became convinced that, as a general rule, that the benefits
> of saving screen space outweighed the benefits of ease of
> deleting/inserting/commenting out code then I suppose I should
> start writing my C code along these lines:
The screen space argument is in my opinion a very good one. Yes,
monitors are bigger now days so make use of the added space. The
information I can directly look at is only one step away from my
memory. While scrolling looking for stuff is like retrieving info
from swap space.
> for (int i =0; i < x; ++i)
> { <...>
> <...>
> for (int j =0; j < y; ++j)
> { <...>
> <...>
> for (int k =0; k < z; ++k)
> { <...>
> <...>}}}
This reduces the utility of the line ~ statement metaphor so I don't
think that it would fly. You can see the optimization of the tradeoff
between this metaphor and code density in the myriad of different
styles inside the C community. This has produced some great idioms
like "}else{" to allow for both editability and density. Personally,
I like to read dense C code and modify spaced out code.
> On the other hand, fearing I might be ostracized by other
> C programmers, I might resist the change on sociological
> grounds.
I think that you should do it on utilitarian grounds. C indenting is
good for C.
> Just as I find myself now tempted to manage Lisp
> whitespace the Lisp way -- not because it is the best
> functional choice, but because, well ... who wants to make
> other programmers <vomit> <wretch>, or be labelled
> criminal, or worse?
Well, I have given an honest try to explaining why it actually is the
best functional choice. Try to get the line~statement metaphor out
of your brain and operate on forms, but once you become fluent at this
mind you, C will become more tedious. Take a step back and look at C
and lisp for what they are, linguistic constructions. They communicate
meaning for better or worse and each has shaped and been shaped by
their respective environment. There is a natural optimization process
going on through which they change and try to balance these dynamic
pressures. C gains "//" and loses restrictions on the location of
variable declarations. Lisp lets flavors go in favor of CLOS, while
ACL is leading the charge into the wild realms of case sensitivity.
They are both living languages which have been well worn and broken
in, enjoy them. If you are a glutton for abuse go live in one of them
thar new fangled languages somebody recently designed. Sure they are
more modern and sleek, but like a lot of modern and sleek things their
not particularly comfortable or hospitable.
-Eric
Footnotes:
[1] I think that C99 added this but if you disagree just think in C++.
[2] I was using Win 3.11's very twisted idea of a telnet client
to modify some code controlling some experiments running on the
other side of the world. It couldn't handle emacs even vi was
messed up to where I would have to exit every now and again to
reset the terminal. In that case I found it was just easier to
have a paren per line, you couldn't even could them since
scrolling the terminal left junk every where, is it a paren or a
display fragment? I usually had to do a :wq reset ; cat foo.lisp
to find out for sure.
Kent M Pitman
The comments I'm about to make are orthogonal to the main thrust of what
you were writing about, but I wanted to inject them somewhere.
> (let ((a 10)
> #+nil(b 5) (c 4))
> (setf foo (+ a #+nil b c))
> #+nil
> (setf bar 42))
>
You should know that things after #+ and #- are read in the KEYWORD package,
not the current nor CL-USER package. Consequently, this is about the
feature :NIL, which is, incidentally, non-null. (Not that that matters to
your example or anything else I say.) There was a dialect of Lisp called
the New Implementation of Lisp (NIL) and it did use this particular #+/#-
keyword, so please do not think that #+nil is a good thing to use.
#+ignore is used by enough programmers that it probably merits being
considered reserved; it would be a disaster to ever push :ignore onto
*features* and then load anyone's code that you had not audited first.
I also recommend never globally putting :debug on *features*, because a lot of
programmers use #+debug in code to put in debugging stuff they don't want.
Pushing it temporarily there for compiling one file and then removing it is
probably ok, since otherwise no one's use of #+debug would work.
It's too bad we didn't think to reserve such things in the standard.
All in all, I recommend using #|...|# (or #||...||#) rather than #+ignore ...
though. #|...|# can span multiple lines or can comment out part of a line.
It also has the virtue of having clean nesting behavior.
Thomas F. Burdick
> k...@ashi.footprints.net (Kaz Kylheku) writes:
> > For example, if someone tells you that you can write clean, seamless
> > code-transforming macros that can compute things rather than merely
> > substitute arguments into replacement text, this is might not register
> > as significant, unless you have already spent much time carving macros
> > with a blunt instrument like the C preprocessing language, and experienced
> > first hand how hard it was to create clean extensions to the language.
>
> He might not believe you even if he has done this because (1) he doesn't
> want to admit he's wasted a lot of time needlessly or (2) he has puzzled
> hard on this problem and so convinced himself that it can't be made
> better that he simply thinks you are lying or deluded.
I would bet that most of the time he will be convinced, or at least
intrigued. My reasoning: that programmer who was actually trying to
do significant rewriting of C code -- rather than just simple
substitution -- was probably reaching beyond what he was comfortable
with, beyond the minimum he thought he needed to get the job done.
One of the most disturbing observations I've had wrt other programmers
my age while aging from [17, 23] has been that most of them have
reached a point then decided that they knew everything they needed to
about computer science. Age [21, 22] was the worst, because that was
when a bunch got CS degrees and thought that was that. A fair bit of
the rest of us -- I know because I've been talking about this for 2
years now, because it disturbs me -- figure we'll still be learning
vital, important things about CS in our 90's, and programming
techniques that, once learned, we won't be able to imagine living
without.
(with-anecdote (:obligatory)
Once upon a time, I was working on a C++ project that was doing
significant rewriting of its source code by hooking in to g++, and
had an ad hoc garbage collector. When someone told me this was much
easier in Lisp, I was doubtful. When he told me that it was
system-supported, I didn't particularly care (obviously, I was more
interested in exploring new-to-me ideas than caring what the system
supported). When he told me that these were normal, everyday things
to do in Lisp, that all Lispers are conversant in, then I cared.)
I'd guess the best potential Lisp converts are the ones trying to
reach for things they're not comfortable with, because they're trying
to constantly expand their knowledge in computer science.
(I'll cut this short before I get into the self-righteous
scientific-mindset rant so typical of biology students at this
university)
Thomas F. Burdick
> (In reverse I've sometimes suggested that it would be cool to use
> compression technology to choose good "function" boundaries in
> languages like postscript that are about optimizing the moral
> equivalent of keystrokes (token stream rather than keystroke stream).
> I suppose a similar overseer clamped onto emacs might "discover"
> interesting command sequences that were candidates for keyboard
> commands. If anyone ever tries any of those projects I'd be very
> curious to hear the outcome.)
I know someone who once tracked his keystrokes in emacs, identified
the idioms, and bound them to keys. Alt- and Super- are completely
untouched in standard emacs bindings, leaving a *huge* space in which
to bind idiomatic sequences. Once he got used to his new bindings, it
was amazing to see him work. As far as I know, he still looks for
idioms in his current usage, and adds those.
Christian Lynbech
Dorai> The vim keystrokes are 6 more than Pitman's 24.
Which I think only goes to show that `vim' too is a capable
editor. Trying to do the same in standard vi, (or even `ed') would
most likely be a horrifying experience (it would in any rate, but
double so for a standard lisp style file than C style one).
------------------------+-----------------------------------------------------
Christian Lynbech | Ericsson Telebit, Skanderborgvej 232, DK-8260 Viby J
Phone: +45 8938 5244 | email: christia...@ted.ericsson.dk
Fax: +45 8938 5101 | web: www.ericsson.com
------------------------+-----------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
- pet...@hal.com (Michael A. Petonic)
Alain Picard
> I hope you mean ;) rather than :).
Hum, I guess it was Ha ha, only serious.
>
> Actually, having written tens of thousands of lines of Python, I have
> decided that Guido was in error to use indentation (a la fortran?) to
> group code. It looks nice when the code is in final, presentable form,
> but ONLY in the short, neat examples Pythoners use to show how nice it
> is...
>
> Worse, when editing code and changing the structure, emacs, with no
> consistent delimiter to determine nesting level, could only guess, and
> usually guessed wrong. It really slowed down prototyping. In a book or
Thanks for this post. I've read a book about Python, but never
programmed in it. My initial impression was that, since I always
indent my code nicely, the indentation as syntax would not be a harsh
penalty, but I think your point of losing quick refactoring ability
is a good one. It's nice to hear it from someone who's been through
the pain.
--
It would be difficult to construe Larry Wall, in article
this as a feature. <1995May29....@netlabs.com>
Christian Lynbech
Kaz> Or other communities of folks, to be fair. It's quite peculiar how the
Kaz> Lisp community has all kinds of insights into all kinds of things,
Kaz> but have been largely ignored for decades. Why is that? Ineffective
Kaz> advocacy? Or are the concepts just too difficult to grasp?
I think it is also (at least in part) a case "seduction by
systems". Many systems tend to lead their users in particular
directions, and I think that once the average programmer has grasped
one tool, he will need some pretty strong motivation to move on (the
"the world looks like a nail to a hammer" argument).
Back in the microcomputer days, one of the big languages was BASIC,
since this was what was readily available to the hobyist programmers.
On UNIX systems, it is pretty difficult to ignore C for long, both
because C is an integrated part of UNIX and because the kernel
facilities are geared towards the C world, so even UNIX
implementations of other languaes easy gets a definitie C/UNIX aroma
(consider for instance Guile Scheme, that exports many low-level
things to the scheme level, including the select() call and filedescriptors).
If Symbolics had stood grounds against SUN and the floodwave of UNIX,
the world might looked very different today.
Dorai Sitaram
>
>> (let ((a 10)
>> #+nil(b 5) (c 4))
>> (setf foo (+ a #+nil b c))
>> #+nil
>> (setf bar 42))
>>
>
>You should know that things after #+ and #- are read in the KEYWORD package,
>not the current nor CL-USER package. Consequently, this is about the
>feature :NIL, which is, incidentally, non-null.
So sad. I rather like the ability to "comment
following s-expression", without having to annotate to
both flanks of that s-expression.
Well I guess one could get by with #+(or). Only one
extra keystroke too! ;->
--d
xauau
> While I know that short functions are preferable, sometimes I can't
> reasonably avoid more lines in a function than will fit on one screen.
> In Python, I found I couldn't get the indentation correct near the
> bottom of the function because there was a lot of nesting. I couldn't
> easily see (or remember) if I needed to unindent one level or three.
I've very seldom had this problem in Python. In version 2 and later,
it's even less likely to become a problem because list comprehensions,
together with other functional features (map, zip, filter, etc),
relieve a lot of the need for nested loops. This decreases the
indentation level in itself, but it also makes functions less likely
to need more than a screenful.
If it _is_ a problem for some, they can solve it easily by using the
right editor. (Now where have I heard that before?) ;-)
Some editors use "folding", wherein indented portions of code can be
collapsed and expanded in the same way that various graphical tree
widgets display directory contents.
> I would relegate (sounds harsher than I intend) Python to the status of
> "way nicer than Perl, but still a wannabe lisp". In every aspect,
> unfortunately.
For the majority of the (simple) stuff I do, I find Python as good as
or slightly better than Lisp. The combination of C++ and Python solves
all of my current problems, but I'm learning Lisp in the hope that, if
I one day need to do something I hadn't anticipated a need for, Lisp
is less likely to leave me stranded. Perhaps you've already been where
I hope/fear to go?
So may I ask you what you have in mind when you say "in every aspect"?
I'm not looking to disagree with you or defend Python _against_ Lisp.
I'm just wondering whether you have better reasons than the (IMO
trivial) ones proffered above.
(Sorry if line spacing in this article is screwed up. Google's preview
mode needs some work).
xauau
(Apologies if your server displays this twice. I posted first via
Google, but cancelled when I saw it had inserted _meaningless_
whitespace) ;-)
Craig Brozefsky
> So if I became convinced that, as a general rule, that the benefits
> of saving screen space outweighed the benefits of ease of
> deleting/inserting/commenting out code
Well I can tell you that I personally spend way more time reading code
than I do editing it, so a style that prioritized reading at no, or
very little, loss of editing efficiency seems to be a big win over an
editing efficient style that has less code on the screen.
> On the other hand, fearing I might be ostracized by other
> C programmers, I might resist the change on sociological
> grounds.
when in Rome...
> Just as I find myself now tempted to manage Lisp
> whitespace the Lisp way -- not because it is the best
> functional choice, but because, well ... who wants to make
> other programmers <vomit> <wretch>, or be labelled
> criminal, or worse?
Killed? Well, just don't reveal you're real address and the style
cabals will be stymied.
--
Craig Brozefsky <cr...@red-bean.com>
http://www.red-bean.com/~craig
The outer space which me wears it has sexual intercourse. - opus
Andy Freeman
> Actually, having written tens of thousands of lines of Python, I have
> decided that Guido was in error to use indentation (a la fortran?) to
> group code. It looks nice when the code is in final, presentable form,
> but ONLY in the short, neat examples Pythoners use to show how nice it
> is...
I haven't written tens of thousands of lines of Python, but in my thousands
of lines, the more I've written, the more I like its indentation as syntax.
I've found that visual uniformity that Python requires makes code more
readable. My visual pattern recognizers can extract more information
with less processing AND they work the same on other people's code (or
my code from two months ago) as they do on what I've just written.
The uniformity also makes it possible for me to read/understand at a
higher level of abstraction. I can print out 10-20 pages of code,
lay it on a table, step back so that I can only see the structure,
and see things. Before, I could only do this with my code, and then
only when I've been careful about my indentation. With Python, I can
do it with other people's code as well; the trick even works with code
from multiple sources.
Don't get me wrong - expression/statement oriented editing (depending
on the language) is the way to go, but the more information that I can
get from low-level visual processing, the better.
I write bigger than a screen/page functions in Python too and emacs
didn't fail me when it came to indentation, tabs or not. (I use a
very small subset of emacs, so maybe I've just adapted.)
I miss lisp's macros, and I don't like Python's multiple expression
syntaxes (and precedence), but I really like grouping statements with
indentation.
-andy
Eric Dahlman
> Eric Dahlman <er...@lossage.org> writes:
>
> The comments I'm about to make are orthogonal to the main thrust of what
> you were writing about, but I wanted to inject them somewhere.
>
> > (let ((a 10)
> > #+nil(b 5) (c 4))
> > (setf foo (+ a #+nil b c))
> > #+nil
> > (setf bar 42))
> >
>
> You should know that things after #+ and #- are read in the KEYWORD package,
> not the current nor CL-USER package. Consequently, this is about the
> feature :NIL, which is, incidentally, non-null. (Not that that matters to
> your example or anything else I say.) There was a dialect of Lisp called
> the New Implementation of Lisp (NIL) and it did use this particular #+/#-
> keyword, so please do not think that #+nil is a good thing to use.
Just when you think that you understand something, reality rears its
ugly head. The #+nil idiom is not my coinage, but when I first came
across it I thought "Gee that is cool, it evaluates to nil so the code
will not be included." I believe that this intention was also
reflected in the code I was working on at the time since I never came
across anything which would make me question my interpretation. Later
on I have had to fight my way through the subtleties of #+ and #- and
*features* with ACL's extensions, and I never questioned my initial
interpretation of #+nil. Which just amazes me given that it is so
inconsistent with the way that the mechanism works.
Had you not pointed that out I would certainly carried that
misconception to the grave with me. Now I have got jillions of files
to update to change #+nil to #+ignore, not because I particularly care
about compatibility with the New Implementation of Lisp but because it
works for the wrong reason.
< cool theoretical stuff follows ;-) >
To kind of bring this back to the original poster's indenting
quandary, this does go to illustrate a good point. The mapping of
#+nil to #+ignore [1] is a fundamentally different problem than the
previous issues with sexps. When the domain of our language is sexps
#+nil is lingual construct, it describes a transformation on a given
sexp. Now to say that #+nil should become #+ignore is actually a
meta-lingual concept, as such it need not be representable or
accessible via the original language. This is nothing to lose sleep
over, there are big name mathematitions who are working against you.
Unfortunately, there will always be a #+nil out there to get you.
The relevance of this is that we have been extolling the power of
using the language of s-expressions and s-expression manipulation
which is useless of this task. At this point we really need a
language for describing the operations on the language of operations
on s-expressions, such a thing surely exists. Alas it has its own
#+nil and so is only the first step in an infinite tower of such
languages.
What to do!!!
Like any good mathematition presented with a nasty infinite
progression we do the wise thing and punt. Actually we take a page
from the book of C, when it is too hard to handle a structure embed it
in a simpler language and try to get by. C has too many special cases
to directly address its structure, so map that onto lines in files and
make do. The hope is that the actual transformations you want to make
are "well behaved" under this mapping so you can express your
intentions in terms of the simpler language. This is why bad C
indenting is so onerous. It makes the projection of a semantically
simple transformation "elide this statement" too complex; that is the
simple projection "put '//' at the beginning of the line" becomes a
complex program involving checking for multiple statements on a given
line, statements spanning multiple lines and verifying that no scoping
operators are altered.
Fortunately in this case if we look at the natural projection of my
lisp code into the domain of files and lines the transformation #+nil
-> #+ignore has a simple and obvious projection. So the solution is
to use sed! More importantly we have informally proven that sed is in
fact the correct solution.
With all the abuse I have heaped onto the model of lines in files as
an encoding of a program. It is still very powerful for some tasks
and should not be abandoned. This is the reason that I *HATE* gui
interfaces for doing "real work", there is no way to punt when I need
to express a meta-linguistic idea. It may by impossible to say
"Delete all files larger than 27MB." In the absence of a useful
projection of the language onto another domain where I could say
something of similar effect I will be pointing and clicking all day.
Have fun,
-Eric
Footnotes:
[1] Or maybe #+if-you-put-this-on-*features*-you-deserve-to-lose ;-)
[2] Or some other search-replace-string-thingy.
Edward O'Connor
> of saving screen space outweighed the benefits of ease of
> start writing my C code along these lines:
> { <...>
> <...>
> for (int j =0; j < y; ++j)
> { <...>
> <...>
> for (int k =0; k < z; ++k)
> { <...>
> <...>}}}
Actually, a friend of mine has been writing C, C++, and Java like the
following code snippet for quite a while, and I liked it so much that
I've adopted the same style myself:
for(int i=0; i<x; i++) {
...
for(int j=0; j<y; j++) {
...
for(int k=0; k<z; k++) {
...}}}
--
Edward O'Connor
t...@oconnor.cx
Kaz Kylheku
>So if I became convinced that, as a general rule, that the benefits
>of saving screen space outweighed the benefits of ease of
>deleting/inserting/commenting out code then I suppose I should
>start writing my C code along these lines:
> for (int i =0; i < x; ++i)
Note that this is C99 or C++.
> { <...>
> <...>
> for (int j =0; j < y; ++j)
> { <...>
> <...>
> for (int k =0; k < z; ++k)
> { <...>
> <...>}}}
Actually, as a result of this debate, I took some C source files and
converted them to this style. It works well, except for a few
infelicities arising out of the treatment of the opening brace. Take
the above loops for instance. If the syntax were more like
{ for ( ... ) statements .. } then this style would work slightly better.
Because then the placement of the opening brace would not be an issue,
and it would be clear that the for construct belongs with the statement
block. This is now more true than ever, because the C++ and C99 declarations
within the for(;;) construct have the same scope as that block.
And of course, function parameter declarations have always had the
scope of the function body.
You can try it both ways, but neither is quite satisfactory,
although I think the second looks somewhat better.
for (;;) {
for (;;) {
statement; }}
for (;;) /* Scope starts here already. */
{ for (;;) /* But brace is opened here, doh! */
{ statement; }}
Then there is the variety in C syntax. How do you treat do/while loops?
do
{ do
{ statement;
statement;
statement; } while (0); } while (0);
do
{ do
{ statement;
statement;
statement }
while (0); }
while (0);
Other than these minor irritations, it appears workable. All you have
to do is train yourself not to see the braces, but only the indentation,
which is something that C programmers already do anyway. All of the
various styles preferred by C programmers make the nesting obvious
by indentation, so that if the braces were erased, the program would
still make sense. Any style which has this property is workable,
and ones which reduce vertical space are better than ones that don't. ;)
--
Articulable, clever reduction of outstretched nonsense, yet meaningful.
Duane Rettig
> [1] Or maybe #+if-you-put-this-on-*features*-you-deserve-to-lose ;-)
Nah; too long - it would really mess up the indentation :-)
In fact, #+ignore could be considered too long. However, shortening
the name increases the liklihood of the name actually representing
a valid feature.
How's this for an idea - we take a hint from the war on drugs and
Just Say #+no
Thomas F. Burdick
> How's this for an idea - we take a hint from the war on drugs and
> Just Say #+no
But that would break my Hello World!
(princ #+es "Hola, Mundo!"
#+fr "Salut, Monde!"
#+no "God dag, Verden!"
#+ca "Hello, World! / Salut, Monde!"
#+us (or #+mi "Hello, World! / God dag, Verden!"
"Hello, World! / Hola, Mundo!"))
(Ug, nevermind ... I should go back to doing something useful now)
Eric Moss
>
> Eric Moss <eric...@pacbell.net> wrote in message
>
> > While I know that short functions are preferable, sometimes I can't
> > reasonably avoid more lines in a function than will fit on one
> > screen. In Python, I found I couldn't get the indentation correct
> > near the bottom of the function because there was a lot of
> > nesting. I couldn't easily see (or remember) if I needed to unindent
> > one level or three.
>
> I've very seldom had this problem in Python. In version 2 and later,
> it's even less likely to become a problem because list comprehensions,
> together with other functional features (map, zip, filter, etc),
> relieve a lot of the need for nested loops. This decreases the
> indentation level in itself, but it also makes functions less likely
> to need more than a screenful.
>
> If it _is_ a problem for some, they can solve it easily by using the
> right editor. (Now where have I heard that before?) ;-)
Hi,
Without as much confidence as I had hoped for (argh!):
I believe that a language should force the user to remember as little as
possible, freeing as many brain cells as it can to focus on the intent
of the program. C makes me remember "too much"
about machine-level data representation. Perl makes me remember "too
much" about $<foo>. Python has helped immensely in both realms, letting
me focus more on the problem. With full-blown lambdas and macros and ...
, lisp has done more still.
For 90%+ of code, python's use of indentation seems just fine. The code
looks good and shows the intent clearly. It runs into trouble (for me,
anyway) in longer code chunks with heavy nesting. It's hard to match the
top of a block with it's bottom when all you have is whitespace as a
guide, and it forces me to remember more during editing. The more python
gets functional, the less this will occur. The more we have the
code-folding and color-coding editors, the less difficult the remaining
occurrences will be to read.
I'm not deep enough into language issues to give definitive statements.
My personal experience is that Python is a line-oriented language (like
a big progn), and while indentation-delimiting has some drawbacks during
editing, it at least produces a good-looking result for that kind of
code. Lisp is an expression-oriented language, and parentheses make
sense. To extend this a bit, I think lisp would be a disaster w/o
parentheses, while Python would gain a little during editing and lose at
least as much during reading the end result.
Eric
Robert Braddock
> k...@ashi.footprints.net (Kaz Kylheku) writes:
>> In article <32062266...@naggum.net>, Erik Naggum wrote:
>> > retarded. Despite being much older than C, the Lisp family did a large
>> > number of things right that the C/Unix folks still have not grasped the
>> > significance of.
--Or don't know about. For example, even having really positive experience
with scheme (used it in early programming classes, as well as a language
design class), I find Lisp is suprisingly more than I had understood it to
be. This takes almost an impressive lack of advocacy. Here, I am already
indictrinated to the code style, know the slowness is a myth, am actively
looking around for new languages, and it has taken quite some time for me to
catch some of the most important details, many of which required following
up on my own to get enough information to actually evaluate -- and all this
_after_ having read a book on lisp programming!! What's more, I'm generally
reliably good at "feeling" unspoken details/meanings/attitudes, so my
experience is very likely quite far from the worst case.
>> I got into Lisp when I came across convincing advocacy, which stated
>> facts about the amazing things you can do in Lisp. But I think that
>> understanding and being impressed by the advocacy required experience
>> in computing; a newbie might not catch what the fuss is about.
Also, the apparent complexity in, say, C or Perl, is more obvious because
it's more local textually, and more straightforward logically. There's
nothing like this to learn with Lisp, so they are hit right off with the
larger issues and so have to see larger code fragments to grasp the meaning,
and that has to precede noting the differences.
>> as significant, unless you have already spent much time carving macros
>> with a blunt instrument like the C preprocessing language, and experienced
>> first hand how hard it was to create clean extensions to the language.
> He might not believe you even if he has done this because (1) he doesn't
> want to admit he's wasted a lot of time needlessly or (2) he has puzzled
> hard on this problem and so convinced himself that it can't be made
> better that he simply thinks you are lying or deluded.
I don't think (1) or (2) characterizes the situation quite right (and people
almost always toss out something like those, which creates an unwelcome
feeling for a "interested bystander" and generally starts things off on the
wrong foot).
From what I've seen in others, and looking back over some periods in my own
programming, the real issue is what we _think_ we're doing in the language.
C programmers in general (and often this increases along with skill) become
very versed in and even proud of all the little details. They have an
extensive range of experience and references they call on for all kinds of
details--even extending into details that _can't_ matter. It's part truth,
part lore, and these equate with judgements of skill/talent/experience.
Then they come to something like lisp, and all those things are gone! This
can be very uncomfortable, really, as the programmer has trouble convincing
himself that something "this simple" is in fact the correct program to
write. The clash in styles gives them the feeling of having missed important
details. If you can't convince yourself your program is correct, how can you
trust it? If you can't write a program you trust, what good is the
environment at all?
Even without writing anything one sees/feels things are "missing". "What
will I *be doing* when I'm writing the program?" "How will it take *as long
as it is supposed to take*?" To fill the gap, you figure the unaccounted for
"work" is still there somewhere--you just can't see it. You can't get a
handle on what you take to be the rest of the important programming
knowledge. So you _clearly_ aren't ready to do any "real" programming. So
you go back to what you've used, where things work like they are supposed
to, and your return of comfort solidifies your inertia for your language and
against the new one.
I think most people don't recognize this at all. They just know someone
indoctrinated into using their language often stays and likes it, but
people just told to try it usually dislike it... So everyone assumes
everyone else is stupid and goes about their business :)
[PS: You all shouldn't harp on perl so much: throw out its syntax and I
believe it will turn out suprisingly similar to Lisp itself--MOP included.]
--
Robert Braddock
Kent M Pitman
> For example, even having really positive experience
> with scheme (used it in early programming classes, as well as a language
> design class), I find Lisp is suprisingly more than I had understood it to
> be. This takes almost an impressive lack of advocacy.
Good point.
In defense of that non-advocacy, I think there is a certain
community-wide disdain for the idea that advocacy should make or break
a language. Lisp people tend to focus their time on substance and hope
that the substance will end up mattering in the long run.
> > He might not believe you even if he has done this because (1) he doesn't
> > want to admit he's wasted a lot of time needlessly or (2) he has puzzled
> > hard on this problem and so convinced himself that it can't be made
> > better that he simply thinks you are lying or deluded.
>
> I don't think (1) or (2) characterizes the situation quite right (and people
> almost always toss out something like those, which creates an unwelcome
> feeling for a "interested bystander" and generally starts things off on the
> wrong foot).
[Hmm. Sorry.]
> From what I've seen in others, and looking back over some periods in my own
> programming, the real issue is what we _think_ we're doing in the language.
> C programmers in general (and often this increases along with skill) become
> very versed in and even proud of all the little details. They have an
> extensive range of experience and references they call on for all kinds of
> details--even extending into details that _can't_ matter. It's part truth,
> part lore, and these equate with judgements of skill/talent/experience.
It's true that I've often described C and such as languages for people
who want to micromanage their data because they are languages about how
to control the implementation, not the abstraction. You never really quite
rise above being concerned about how things are implemented. Lisp is more
about abstraction and expression, and like a good manager in a company who
does not over-supervise his employees, it doesn't get down into the internals
of the "things below". Avoiding the tendancy to need to see inside makes
one vertically flexible and lets one rise as abstraction levels are layered.
Languages overly concerned about implementation (and GC vs manual allocation
is a related matter of implementation) simply does not scale.
> Then they come to something like lisp, and all those things are gone! This
> can be very uncomfortable, really, as the programmer has trouble convincing
> himself that something "this simple" is in fact the correct program to
> write. The clash in styles gives them the feeling of having missed important
> details. If you can't convince yourself your program is correct, how can you
> trust it? If you can't write a program you trust, what good is the
> environment at all?
Again the learned desire to micromanage. Yes, I agree that's an issue.
Of course, they're maybe not used to a language that DOES something for them.
(The "worse is better" problem where you get used to designs that throw
all the hard parts back onto you.)
In fairness, it does require a tremendous faith to program in Lisp because,
for want of a better way of putting it, doing things the easy way makes
you soft. You have to believe the "easy way" is going to continue to be
tehre or you find yourself isoalted from necessary skills of pain endurance,
trivia collection, and sheer brute strength of typing billions of lines of
code that would be used routinely elsewhere if you ever had to go back to it.
I and others who've spent a lifetime in Lisp but who've occasionally had to
fear (or actually do) going to work in another language have run into this
and it's very scary, not to be poo-pooed. But at some point, you have to
say that it's worth risking something for the chance that there might BE
a reliably easier way. If Lisp failed, I don't think I'd be a C programmer;
I'd rather be a sci-fi author or a lawyer or a teacher.
> Even without writing anything one sees/feels things are "missing". "What
> will I *be doing* when I'm writing the program?"
I know this feeling exactly because it's part of the design methodology.
For example, active condition handling (signaling) rather than passive
(error code return) is there to let you just call things like READ-CHAR
with simple args and not have to worry about eof, because you'll get an
error if you fail to handle it when it needs handling. But I can see how
if you've slowly trained yourself to have to handle this, you'd feel like
you were adrift. My paper
http://world.std.com/~pitman/Papers/Exceptional-Situations-1990.html
deals with this specific issue in more detail.
> "How will it take *as long as it is supposed to take*?"
I accept this one though it surprises me. You didn't have other work to
do after?
> To fill the gap, you figure the unaccounted for
> "work" is still there somewhere--you just can't see it. You can't get a
> handle on what you take to be the rest of the important programming
> knowledge.
I see. Again, this is part of the design -- to hide as many pecies of
ritual business as possible. So yes, I guess they could be disconcerting.
Myabe teaching texts should include little blurbs saying "Replaces these
activities in regular programming: ..."
> So you _clearly_ aren't ready to do any "real" programming. So
> you go back to what you've used, where things work like they are supposed
> to, and your return of comfort solidifies your inertia for your language and
> against the new one.
Programming by checklist. Yes. I've started off to write installation
guides that were like that. And eventually I figured out that rather
than have a person (an imperfect processor) execute those steps, it was
better to do them by program. (Fortunately, in modern software, most
installation procedures are automatic. Thank goodness SOME things move
forward.) But programming languages for some reason are not among the
things which routinely try to find makework and hide it, and so I can see
what you're getting at.
> I think most people don't recognize this at all. They just know someone
> indoctrinated into using their language often stays and likes it, but
> people just told to try it usually dislike it... So everyone assumes
> everyone else is stupid and goes about their business :)
Well, although the things I offered above [(1) and (2)] were things that
have, in some context, put you or others off, they are intended less as
means of direct dialog with people and more at ways of analyzing people
in ways that show them doing something that might seem intelligent in
some context, just not in ours. I don't think people are stupid. I just
assume they come from a different context. But you make some excellent
points about other ways to interpret the context, and I'm really happy you
went to the trouble to detail this out. I think there's a lot for us
to learn from in your context.
This post of yours is a good example of what I keep saying about how
experience kills intuition. We can only get perceptions like yours from
someone who has recently been on the outside; those of us who have been
here for a while have either long ago forgotten the experience or are
sometimes not sure any remembrances we have are still valid.
Doug Alcorn
This is pretty far off topic, but how would you go about doing this.
I'm not sure how to record keystrokes in (x)emacs. Plus, once they
were recorded I'm not sure I would know how to do the frequency
analysis to find the most used idioms. The only thing I can think of
would be to brute force record every n-long keystroke expression and
track that frequency. The question would then be what's the optimal
value of n?
--
(__) Doug Alcorn (mailto:do...@lathi.net http://www.lathi.net)
oo / PGP 02B3 1E26 BCF2 9AAF 93F1 61D7 450C B264 3E63 D543
|_/ If you're a capitalist and you have the best goods and they're
free, you don't have to proselytize, you just have to wait.
Kent M Pitman
> t...@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
>
> > Kent M Pitman <pit...@world.std.com> writes:
> >
> > I know someone who once tracked his keystrokes in emacs, identified
> > the idioms, and bound them to keys. Alt- and Super- are completely
> > untouched in standard emacs bindings, leaving a *huge* space in
> > which to bind idiomatic sequences. Once he got used to his new
> > bindings, it was amazing to see him work. As far as I know, he
> > still looks for idioms in his current usage, and adds those.
>
> This is pretty far off topic, but how would you go about doing this.
> I'm not sure how to record keystrokes in (x)emacs.
No idea. But I'd start by looking up how "c-h l" works.
> Plus, once they
> were recorded I'm not sure I would know how to do the frequency
> analysis to find the most used idioms.
Well, I was recommending this as a tractable project but maybe not
totally trivialy. Perhaps a good senior project for an undergrad?
Aren't they forever looking for something to do? Rather than do
frequency analysis per se, since you don't know the sequence length
and starting point, I might take some popular compression algorithms
and see if their various ways of recognizing recurrences could be
adapted for this purpose. If you go read about or implement a
compression algorithm, you'll easily see the part I'm talking about.
There's a phase (usually interleaved) that concerns itself with
finding the long strings that will be referred to in short form in
order to accomplish the compression.
> The only thing I can think of
> would be to brute force record every n-long keystroke expression and
> track that frequency. The question would then be what's the optimal
> value of n?
Compression algorithms are usually smarter than this. Read about
some. The GIF/LZW algorithm is quite straightforward in spite of patent
issues for using LZW itself. The gzip algorithm has no such patent
problems, though I've been having trouble finding a document which is
both coherent and adequately detailed and is not code-itself to describe
it. (Pointers anyone?)
Gavin E. Mendel-Gleason
I think there is a very straitforward reason that zlib doesn't describe how it works. It because if they
did then someone could claim they already had the patent (which after spending several days reading it,
I'm almost positive is true!). As it is the only description that I was able to find about how it works, is
some fairly difficult to read source code.
--
Gavin E. Mendel-Gleason
(let ((e-mail-address "PGIU...@VGIHKRR.TKZ"))(loop with new-string = (make-string (length e-mail-address))
for count from 0 to (1- (length e-mail-address)) for char-code = (char-code (aref e-mail-address count))
for new-char-code = (if (and (> char-code 64)(< char-code 123))(+ (mod (+ 13 char-code) 52) 65) char-code)
do (setf (aref new-string count) (code-char new-char-code)) finally (return new-string)))
Gavin E. Mendel-Gleason
Edited version in literate english (I just woke up before writing the previous version):
I think there is a very straitforward reason that zlib doesn't describe how it works. It is because if the
authors described it accurately, then it would be easier to claim that it was covered by an extisting patent.
I'm fairly sure this is the case after having spent several days reading it.
There isn't any descriptive documentation that I was able to find, and the source code is very difficult to
read, having been restructured for time effiecency (and possibly for obfuscation).
T. Kurt Bond
> t...@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
>
> > Kent M Pitman <pit...@world.std.com> writes:
> >
> > I know someone who once tracked his keystrokes in emacs, identified
> > the idioms, and bound them to keys. Alt- and Super- are completely
> > untouched in standard emacs bindings, leaving a *huge* space in
> > which to bind idiomatic sequences. Once he got used to his new
> > bindings, it was amazing to see him work. As far as I know, he
> > still looks for idioms in his current usage, and adds those.
>
> This is pretty far off topic, but how would you go about doing this.
> I'm not sure how to record keystrokes in (x)emacs.
In GNU Emacs:
open-dribble-file is an interactive built-in function.
Start writing all keyboard characters to a dribble file called FILE.
If FILE is nil, close any open dribble file.
(open-dribble-file FILE)
--
T. Kurt Bond, t...@tkb.mpl.com
Rob Warnock
+---------------
| Duane Rettig <du...@franz.com> writes:
| > #+ignore (frazzle gorp ...)
|
| It's apparently possible to learn something every day. That is a
| _slick_ way of eliminating an s-exp...
+---------------
Another way -- if the s-expr you want to "comment out" isn't the last one
in a block -- is just to quote it. Takes only one character. Any decent
compiler should eliminate it as a dead constant. [Works in Scheme, too.]
The only problem I've had is because the quote is *so* small, you sometimes
overlook it when you're trying to figure out why you can't get the code
working again... ;-} ;-}
-Rob
-----
Rob Warnock, 30-3-510 <rp...@sgi.com>
SGI Network Engineering <http://reality.sgi.com/rpw3/> [until 8/15]
1600 Amphitheatre Pkwy. Phone: 650-933-1673
Mountain View, CA 94043 PP-ASEL-IA
[Note: aaan...@sgi.com and zedw...@sgi.com aren't for humans ]
Rob Warnock
+---------------
| > I know someone who once tracked his keystrokes in emacs, identified
|
| This is pretty far off topic, but how would you go about doing this.
See <URL:ftp://ftp.cpsc.ucalgary.ca/pub/Redirect/the.reactive.keyboard/
00-intro.txt> for a thingy called "The Reactive Keyboard", by John Darragh,
which did such a predictive trick in realtime with ordinary shell sessions.
While I haven't used it myself, I've seen friends of mine navigate incredibly
quickly through their software development environments using it. From one
of the abstracts:
This paper describes the operations and sketches the design
and construction of a terminal interface to an operating system
(Unix [1]) which is intended to aid the interactive user by
reducing the amount he has to type. It works by predicting the
entries that he is about to make. Predictions are displayed
in reverse video on the VDU terminal, and the user has the option
of accepting correct predictions as though he had typed them
himself. Incorrect predictions can be eradicated by simply
typing over them; thus the user may ignore the predictions
and continue typing normally if he does not wish to disturb
his keying rhythm. In all cases the display looks as though
he had typed the whole entry himself.
But the software at that site is dated 1990, so you might want to do
a web search and see if a more up-to-date version is around anywhere...
Rob Warnock
+---------------
| For example, if someone tells you that you can write clean, seamless
| code-transforming macros that can compute things rather than merely
| substitute arguments into replacement text, this is might not register
| with a blunt instrument like the C preprocessing language, and experienced
| first hand how hard it was to create clean extensions to the language.
Or unless you're old enough to have used *assemblers* that had "real"
macros systems, too, such as MACRO-10 (the assembler for the PDP-10).
I've written here previously several times (at too-great length) about
the wonderful things you could do with it [e.g., define recursive
block-structure macros, do significant compile-time computation,
write macros that define macros, etc.], so I won't repeat that again.
But having had that experience, when C came along its "macros" instantly
were seen as terribly anemic! It wasn't until I found my way to Lisp many
years later (by way of Scheme) that I found an environment that equalled
(indeed, surpassed) the old MACRO-10 macros in expressiveness.
-Rob
-----
Rob Warnock, 30-3-510 <rp...@sgi.com>
SGI Network Engineering <http://reality.sgi.com/rpw3/> [until 8/15]
1600 Amphitheatre Pkwy. Phone: 650-933-1673
Mountain View, CA 94043 PP-ASEL-IA
[Note: aaan...@sgi.com and zedw...@sgi.com aren't for humans ]
brl...@my-deja.com
> Another way -- if the s-expr you want to "comment out" isn't the last one
> in a block -- is just to quote it. Takes only one character. Any decent
> compiler should eliminate it as a dead constant. [Works in Scheme, too.]
Won't those other methods also fail if it's the last s-expr in a block?
Likely the previous s-expr is there for side effect and will return a
value more difficult to debug than the quoted s-expr.
--
Bruce R. Lewis http://brl.sourceforge.net/
I rarely read mail sent to brl...@my-deja.com
Thomas F. Burdick
> rp...@rigden.engr.sgi.com (Rob Warnock) writes:
>
> > Another way -- if the s-expr you want to "comment out" isn't the last one
> > in a block -- is just to quote it. Takes only one character. Any decent
> > compiler should eliminate it as a dead constant. [Works in Scheme, too.]
>
> Won't those other methods also fail if it's the last s-expr in a block?
> Likely the previous s-expr is there for side effect and will return a
> value more difficult to debug than the quoted s-expr.
Well, it depends on why you're commenting the line out. I often find
myself doing:
(cond
((case-a-p) (do-case-a))
((case-b-p) (do-case-b))
(t (possibly-buggy-function)))
=>
(cond
((case-a-p) (do-case-a))
((case-b-p) (do-case-b))
(t (stub) #+ignore (possibly-buggy-function)))
(Well, actually, I'd been using #+nil until a few days ago)
Where possibly-buggy-function is called for its value, and stub gives
me something I can at least work with for the moment. The odds that
'(possibly-buggy-function) is such a value are pretty low :)
Reini Urban
: [2] I was using Win 3.11's very twisted idea of a telnet client
: to modify some code controlling some experiments running on the
: other side of the world. It couldn't handle emacs even vi was
: messed up to where I would have to exit every now and again to
: reset the terminal. In that case I found it was just easier to
: have a paren per line, you couldn't even could them since
: scrolling the terminal left junk every where, is it a paren or a
: display fragment? I usually had to do a :wq reset ; cat foo.lisp
: to find out for sure.
exactly that's why we finally removed telnetd from our lab server.
people got used to very bad habits using windows telnet.exe.
typical ssh client like putty are way better and let us/them use emacs,
not speaking about forwarding X.
we will see if this will improve style, but it certainly cut our support
costs (=time).
--
Reini Urban
http://xarch.tu-graz.ac.at/acadwiki/AutoLispFaq
Christian Lynbech
Doug> I'm not sure how to record keystrokes in (x)emacs.
One possibility would be to use `post-command-hook' (at least for GNU
Emacs) which is a list of functions that is called after each command
has been executed, and you can access variables such as
`last-input-event' or `last-command' (there are more of these).
Here is a small silly example (works in GNU Emacs 20.7):
(defvar my-command-count-table (make-hash-table :test 'eq))
(defun my-count-commands ()
(interactive)
(setf (gethash last-command my-command-count-table)
(1+ (or (gethash last-command my-command-count-table) 0)))
(let ((max-cmd nil) (max-count 0))
(maphash (lambda (k v) (if (> v max-count)
(setq max-cmd k
max-count v)))
my-command-count-table)
(message "most popular command is: %s" max-cmd)))
(add-hook 'post-command-hook 'my-count-commands)
;;style is not good, but note the CL'isms ;-)