The Fundamental Problems of Lisp

67 views
Skip to first unread message

xah...@gmail.com

unread,
Jul 13, 2008, 10:53:38 AM7/13/08
to
Fundamental Problems of Lisp

Perm url:
http://xahlee.org/UnixResource_dir/writ/lisp_problems.html

plain text version follows.

----------------------------------------------
...

Since i'm writing... n i wrote a lot in the past on diverse issues
scattered
in various essays... i'll sum some fundamental problems of lisp.

• Lisp relies on a regular nested syntax. However, the lisp syntax has
several
irregularities, that reduces such syntax's power and confuses the
language
semantics. (i.e. those «' # ; ` ,» chars.) (and whenever i tried to
get some
technical answer about this to clarify at least my own understanding,
the lisp
fuckheads muck and obfuscate the truth)

• Lisp's irregular syntax those «' # ; ` ,» things, are practically
confusing
and made the lang less powerful. i.e. in elisp, there's no form of
comments in
matching delimiters (and consequently no nested comment). The reliance
on EOL
chars as part of the syntax semantics is one of the major fuckup to
the power
of pure nested syntax.

• Lisp relies on a regular nested syntax. Because of such regularity
of the
syntax, it has very powerful consequences, at least theoretically.
(and
practically, lispers realized just one: the lisp macros) For example,
since
the syntax is regular, one could easily have alternative, easier to
read
syntaxes as a layer. (the concept is somewhat known in early lisp as
M-expression) Mathematica took this advantage (probably independent of
lisp's
influence), so that you really have easy to read syntax, yet fully
retain the
regular form advantages. Lisp, on the other hand, such alternative
syntax has
been done and tried here and there in various forms or langs, but
never caught
on due to largely social reasons. Part of these reasons are political.
(thanks
to, in part, the Lisp old hats that suppresses it.)

• One of the advantage of pure fully functional syntax is that a
programer
should never, ever need to format his source code (i.e. pressing tabs,
returns) in coding, and save the hundreds hours of labor, guides,
tutorials,
advices, publications, editor tools, on what's known as “coding style
convention”, because the editor can trivially reformat the source code
on the
fly based on a simple lexical scan. This is done in Mathematica
version 3
(~1996). In coding elisp, i'm pained to no ends by the manual process
of
formatting lisp code. The lisp community, established a particular way
of
formatting lisp code as exhibited in emacs's lisp modes and written
guides in
conventions. The recognization of such convention further erode any
possibility and awareness of automatic, uniform, formatting.

• Lisp relies on a regular nested syntax. One of the power of such
pure syntax
is that you could build up layers on top of it, so that the source
code can
function as markup of conventional mathematical notations (i.e. LaTeX)
and or
as a word-processing-like file that can contain structures, images,
yet lose
practical nothing. This is done in Mathematica in ~1996 with release
of
Mathematica version 3.

Further readings:

* The Concepts and Confusions of Prefix, Infix, Postfix and Fully
Functional
Notations
* The Harm of Hard-wrapping Lines
* A Text Editor Feature: Syntax Tree Walk
* A Simple Lisp Code Formatter

The above are some of the damages lispers has done to themselfs, with
respect
to its nested functional syntax. The other major one is the cons
business.

• Lisp at core is based on functional programing on lists. This is
very
powerful. However, for historical reasons, lisp's list is based on the
hardware concept of “cons” cell. This fundamentally handicapped the
advantages
of power of list processing.

Lisp being historically based the cons for like 2 or 3 decades. The
cons (and
cdr, car, caadar etc) are fundamentally rooted in the lisp langs, is
thus not
something that can be easily fixed. Quite unfortunate. However, this
situation
could be improved. But, whenever i discuss this, you can see that the
lisper
slaves here, their mentality, prevents any possible improvement. (in
general,
this is because, lispers usually do not have serious experience or
investment
in other functional langs, such as Mathematica, Haskell, etc.)

One of the myth that are quickly embedded into budding lispers, is
that cons
are powerful. Powerful my ass. It is powerful in the sense any
assembly lang
is powerful. Lisp's cons is perhaps the greatest fuck up in the
history of
computer languages.

Further readings:

* Lisp's List Problem
* My First Encounter And Impression Of Lisp
* The Jargon “Lisp1” vs “Lisp2”

Will Lisp ever be Popular?

Mathematica today sells for over 2 thousands dollars. Its sales
record,
throughout its history, is probably more than ALL commercial lisps
combined.
Such a illuminating social fact, in not known in lisp communities.
These
fuckheads thinks that lisp is more popular.

10 years ago, in the dot come days (~1998), where Java, Javascript,
Perl are
screaming the rounds. It was my opinion, that lisp will inevitably
become
popular in the future, simply due to its inherent superior design,
simplicity,
flexibility, power, whatever its existing problems may be. Now i don't
think
that'll ever happen as is. Because, due to the tremendous
technological
advances, in particular in communication (i.e. the internet and its
consequences, e.g. Wikipedia, youtube, youporn, social networks sites,
Instant
chat, etc) computer languages are proliferating like never before.
(i.e.
because the abundance of tools, libraries, parsers, existance of
infrastructure) New langs, basically will have all the advantages of
lisps or
lisp's fundamental concepts or principles. I see that, perhaps in the
next
decade, as communication technologies further hurl us forward, the
proliferation of langs will reduce to a trend of consolidation (e.g.
fueled by
virtual machines such as Microsoft's .NET. (and, btw, the breaking of
social
taboo of cross communication led by Xah Lee)).

There is one slight hope for Lisp the lang as we understood it, and
that is
emacs lisp. Due to, it being deeply rooted in the industry as a
powerful text
editor, and the embedded lisp have major practical impact in getting
people to
know lisp and also actually use it for practical need. (this
satisfying
prospect is however mar'd by the tech geekers. e.g. the Common
Lispers, and
Scheme Lispers, perennially inject snide and sneer at emacs lisp that
harms
its progress, while the fucking emacs priests, want to coffin emacs
perpetually in its 1980s UI and terminologies.)

Xah
http://xahlee.org/


Vassil Nikolov

unread,
Jul 13, 2008, 12:31:07 PM7/13/08
to

On Sun, 13 Jul 2008 07:53:38 -0700 (PDT), "xah...@gmail.com" <xah...@gmail.com> said:
| ...

| i.e. in elisp, there's no form of comments in matching delimiters
| (and consequently no nested comment).

That is not entirely true. XEmacs, at least, implements the `#+'
syntax, which can be used to comment out well-formed S-expressions
without relying on newlines, and such constructs do nest: if we
start with

(foo)
(bar)
(baz)
(quux)

then in

(foo)
#+(or) (
(bar)
(baz)
)
(quux)

(FOO) and (BAR) are effectively commented out, and then in

#+(or) (
(foo)
#+(or) (
(bar)
(baz)
)
(quux)
)

the whole thing is commented out.

| ...


| since the syntax is regular, one could easily have alternative,
| easier to read syntaxes as a layer. (the concept is somewhat known
| in early lisp as M-expression)

M-expressions are not an "alternative syntax as a layer". Rather,
they are an (abstract) algorithmic language, which can be translated
into S-expressions as forms in the Lisp programming language.

M-expressions make an extensive appearance in John Allen's
_Anatomy of LISP_ (recommended reading whether or not the reader is
interested in M-expressions). I don't have a good pointer to an
Internet source (as of this writing, the Wikipedia article is not
much to go by).

---Vassil.


--
Peius melius est. ---Ricardus Gabriel.

Gene

unread,
Jul 13, 2008, 1:14:46 PM7/13/08
to
On Jul 13, 10:53 am, "xah...@gmail.com" <xah...@gmail.com> wrote:
> Fundamental Problems of Lisp
>
> Perm url:http://xahlee.org/UnixResource_dir/writ/lisp_problems.html
>
> plain text version follows.
>

> Will Lisp ever be Popular?


>
> Mathematica today sells for over 2 thousands dollars. Its sales
> record,
> throughout its history, is probably more than ALL commercial lisps
> combined.

You infer that Mathematica is popular due to its syntax as a
programming language and ignore that it was the first user-friendly
symbolic math system and gained its user base on that strength. Much
of that base is people who are far more interested in the math than
the programming language aspect. I'm neither a Lisp nor a Mathematica
zealot. But I've used both. Mathematica has its own warts, and a
long list of them at that, thought its good enough for what it does.
As a general purpose programming language, it would be a failure.

jon.harro...@gmail.com

unread,
Jul 13, 2008, 2:09:53 PM7/13/08
to
xah...@gmail.com breaking news:
> Fundamental Problems of Lisp

Xah, I love you, we should become friends!

There seems to be no real contents in your postings, only some pseudo
scientific Lisp bashing.
Exactly the same art I'm specialized in.

Congrats, keep up your good work! Together we will win them all!

Jon Harrop

Evans Winner

unread,
Jul 13, 2008, 4:11:03 PM7/13/08
to

"xah...@gmail.com" <xah...@gmail.com> writes:

Lisp relies on a regular nested syntax. However, the
lisp syntax has several irregularities, that reduces
such syntax's power and confuses the language
semantics. (i.e. those «' # ; ` ,» chars.)

I am not a lisp expert. My understanding is that the
standard quote, as in 'foo is syntactic sugar for (quote
foo), and that the correspondence is one-to-one. So you
could, if you liked, simply write all your code without it.
You could, of course, also write all your code without
comments, as well. You might like using a more "pure" (so
to speak) dialect of lisp than Common Lisp or even Emacs
Lisp. I wish there was a port of Lisp 1 or Lisp 1.5
available for common modern systems (is there?) to play
with, but I do believe there a few lisps available based on
such a model. Or perhaps you could write one.

[...] in elisp, there's no form of comments in matching


delimiters (and consequently no nested comment). The
reliance on EOL chars as part of the syntax semantics is
one of the major fuckup to the power of pure nested
syntax.

I don't know how the built-in documentation mechanism works,
but I gather that it has to do with the fact that a defun
only returns its last value. Maybe that concept could be
extended to work with other embedded strings, as in:

(defun foo (slaz)
"This function grovels the slaz. Then returns t"
(grovel slaz) "This is a comment"
"This functions like a comment too."
t)

Of course this adds the comments to your lisp image, but
then maybe it would allow for "literate programming" style
practices. Maybe some of the most common operators could be
programed to take an optional throw-away argument where you
could plug in comments.

But really, unless your purpose is to make those comments
available in your image, what difference does it make? The
comments are there for humans reading the code, so what
difference does it make if EOL is made the comment end syntax?

since the syntax is regular, one could easily have
alternative, easier to read syntaxes as a layer. (the
concept is somewhat known in early lisp as M-expression)

It's debatable whether M syntax is easier to read than S
syntax. But it is interesting that, that having been the
initial intent of McCarthy et al, there was never enough
motivation to actually implement it. Certainly I prefer
lisp syntax to that of any other language I have dabbled
with. And then I believe that a number of macro-based
alternate syntaxa /have/ been implemented in lisp. (What is
the plural of syntax, anyway?)

One of the advantage of pure fully functional syntax is
that a programer should never, ever need to format his

source code (i.e. pressing tabs, returns) [\ldots]

That sounds nice. I believe it is the CADR lisp machine
(not sure) that I once played with (under QEMU, I believe)
that had a nice feature that once you typed a final end
parenthesis for a form, the form was evaluated without you
having to hit enter. I implemented that for myself with
slime a while back for fun. But that is really a REPL
feature, not a language feature per se. Where your
interface to the language interpreter is through an editor,
as is obviously the case with Emacs lisp, it is arguable
that code grinding or formatting or whatever it is called is
an editor feature, not a language feature. Granted, the
syntax of the language can make implementing that more or
less difficult. Using EOL for comment ends makes having the
editor parse it and reformat it more difficult, but I
wouldn't think impossible.

I guess my point is that it is not really possible (as I
understand it) or convenient to build a programming language
that is absolutely nothing but lambda calculus. You still
need some things like an eval function, and a means of
telling it when to evaluate code or not, and a way to embed
comments in code, and so on. In order to be useful, the
language has to solve some problems of a purely practical
nature that aren't really part of the core concept of the
language. I'm no language designer, so I readily admit I
may not know what I'm talking about here. But having said
that, there are automatic code formatters out there for
languages like C; I would be surprised there are not for
lisp, precisely because it /does/ have such a generally
regular syntax.

Lisp relies on a regular nested syntax. One of the power
of such pure syntax is that you could build up layers on
top of it, so that the source code can function as
markup of conventional mathematical notations
(i.e. LaTeX) and or as a word-processing-like file that
can contain structures, images, yet lose practical
nothing.

I may not understand what you are saying here, but available
for at least Common Lisp are packages that turn
s-expressions into xml/html/sgml, etc, and into some kind of
(La)TeX I believe.


Lisp being historically based the cons for like 2 or 3
decades. The cons (and cdr, car, caadar etc) are
fundamentally rooted in the lisp langs, is thus not
something that can be easily fixed. Quite
unfortunate.

It is not immediately obvious to me why cons is a bad
thing. It's also not immediately obvious to my why it's a
good thing, either, so I would be interested in exactly what
it is that is bad about it.

Rob Warnock

unread,
Jul 13, 2008, 9:36:01 PM7/13/08
to
Vassil Nikolov <vnikolo...@pobox.com> wrote:
+---------------

| That is not entirely true. XEmacs, at least, implements the `#+'
| syntax, which can be used to comment out well-formed S-expressions...
...

| #+(or) (
| (bar)
| (baz)
| )
| (FOO) and (BAR) are effectively commented out...
+---------------

Ever since a long-ago thread [in which Erik Naggum was an active
participant, so that tells you how long ago it was!!] in which
this style was presented as a better alternative to #+NIL [which
can break if :NIL ever got onto *FEATURES*], I've found it rather
distasteful -- *not* because there's anything technically "wrong"
with it [there's not], but because of the cognitive dissonance of
the "+" implying the exact *opposite* of what you're trying to do!!
Ditto "#-(or)" to un-comment something -- flat-out backwards! So
ever since then I've been using Erik's suggestion from that thread:

#+(and) to *enable* an S-expression.

#-(and) to "comment out" an S-expression.

Now the "+"/enable and "-"/disable semantics line up:

#-(and) ( ;turn off (BAR) & (BAZ)
(bar)
(baz)
)

Yes, using AND is one character longer than using OR, but
reading it [by humans!] is simply more reliable.


-Rob

p.s. O.k., confession time: Even more recently I've started getting
a bit lazy and using "#-+" to enable and "#+-" to comment out.
My mnemonic is that "#-+" represents a "rising edge", that is,
goes "from off to on" (enables), while the "falling edge" "#+-"
goes "from on to off" (*dis*ables). Yes, it depends upon
(INTERSECTION '(:+ :-) *FEATURES*) being NIL, but that's
really, *really* unlikely to be violated.

-----
Rob Warnock <rp...@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607

Vassil Nikolov

unread,
Jul 13, 2008, 11:04:14 PM7/13/08
to

On Sun, 13 Jul 2008 20:36:01 -0500, rp...@rpw3.org (Rob Warnock) said:
| ...

| the cognitive dissonance of
| the "+" implying the exact *opposite* of what you're trying to do!!
| Ditto "#-(or)" to un-comment something -- flat-out backwards! So
| ever since then I've been using Erik's suggestion from that thread:

| #+(and) to *enable* an S-expression.

| #-(and) to "comment out" an S-expression.

| Now the "+"/enable and "-"/disable semantics line up:

| #-(and) ( ;turn off (BAR) & (BAZ)
| (bar)
| (baz)
| )

| Yes, using AND is one character longer than using OR, but
| reading it [by humans!] is simply more reliable.

You may well be right that `#-(AND)' is cognitively safer; myself,
not only had I forgotten that particular part about preferring
`#-(AND)' to `#+(OR)', but I didn't perceive the plus sign as one
for "adding" anything in this context, either, but applied the
(private) mnemonic that the latter is like "'hash-sign' and 'or'",
i.e. `#|'.

(Until one starts perceiving this idiomatically, working out #-(AND)
involves working out a double negation, of which I am not a
particularly big fan, but that probably matters little. In other
words, I'd prefer ``(WHEN false ...)'' (`#+(OR)') to ``(UNLESS true ...)''
(`#-(AND)').)

---Vassil.

P.S. Sadly, Erik Naggum will not be explaining how wrong I am (and I
am not being sarcastic here).

Maciek Pasternacki

unread,
Jul 14, 2008, 5:24:59 AM7/14/08
to
On Sun, 2008-07-13 at 20:36 -0500, Rob Warnock wrote:
> p.s. O.k., confession time: Even more recently I've started getting
> a bit lazy and using "#-+" to enable and "#+-" to comment out.
> My mnemonic is that "#-+" represents a "rising edge", that is,
> goes "from off to on" (enables), while the "falling edge" "#+-"
> goes "from on to off" (*dis*ables). Yes, it depends upon
> (INTERSECTION '(:+ :-) *FEATURES*) being NIL, but that's
> really, *really* unlikely to be violated.

Is it any less likely than (MEMBER :NIL *FEATURES*) not being NIL?
Seems even twice as likely, since it depends on two, not one, unlikely
feature not being present... and #+NIL / #-NIL is more intuitive than
any of alternatives.

--
-><- This signature intentionally left blank. -><-

Pascal J. Bourguignon

unread,
Jul 14, 2008, 5:34:08 AM7/14/08
to
Vassil Nikolov <vnikolo...@pobox.com> writes:

You could also use:
'(
#+(and) x
#+(not (and)) y
)

--
__Pascal Bourguignon__ http://www.informatimago.com/

"Remember, Information is not knowledge; Knowledge is not Wisdom;
Wisdom is not truth; Truth is not beauty; Beauty is not love;
Love is not music; Music is the best." -- Frank Zappa

Mark Wooding

unread,
Jul 14, 2008, 8:37:41 AM7/14/08
to
Maciek Pasternacki <ja...@zenbe.com> wrote:

> Is it any less likely than (MEMBER :NIL *FEATURES*) not being NIL?

Remember that NIL (New Implementation of Lisp) was actually Lisp system
-- and one of the inspirations for Common Lisp. Presumably, NIL indeed
did put :NIL in *FEATURES*.

Note that NIL (as opposed to :NIL) is not likely to be an element of
*FEATURES*, even on NIL, and it is still a symbol. Of course, #+ and #-
bind *PACKAGE* to the KEYWORD package (2.4.8.17), but you can still type
NIL as (), so...

* (push :nil *features*)
(:NIL :MDW :ASDF ...)
* #+nil t #-nil nil
T
* #+() t #-() nil
NIL

Alternatively, :T is also unlikely to be on *FEATURES*, since T is/was
an dialect/implementation of Scheme. Therefore, #+t may be considered a
safe way of omitting the next S-expression.

Objectionable, no? ;-)

-- [mdw]

Paul Foley

unread,
Jul 14, 2008, 9:51:18 AM7/14/08
to
On Sun, 13 Jul 2008 20:36:01 -0500, Rob Warnock wrote:

> Vassil Nikolov <vnikolo...@pobox.com> wrote:
> +---------------
> | That is not entirely true. XEmacs, at least, implements the `#+'
> | syntax, which can be used to comment out well-formed S-expressions...
> ...
> | #+(or) (
> | (bar)
> | (baz)
> | )
> | (FOO) and (BAR) are effectively commented out...
> +---------------

> Ever since a long-ago thread [in which Erik Naggum was an active
> participant, so that tells you how long ago it was!!] in which
> this style was presented as a better alternative to #+NIL [which
> can break if :NIL ever got onto *FEATURES*], I've found it rather
> distasteful -- *not* because there's anything technically "wrong"
> with it [there's not], but because of the cognitive dissonance of
> the "+" implying the exact *opposite* of what you're trying to do!!

But it's not; #+(or) is like (when nil ...), which is exactly what I
would write if I ever wanted to write that sort of thing; also, #+xxx
is normally "special" (i.e., likely-to-be-disabled) case, so if you
start using #-(and) and #+(and) you're suddenly reversing the normal
sense of #+ and #- ... that's not good.

> Yes, using AND is one character longer than using OR, but
> reading it [by humans!] is simply more reliable.

Not by this human!

> p.s. O.k., confession time: Even more recently I've started getting
> a bit lazy and using "#-+" to enable and "#+-" to comment out.

At least it uses #+ the right way around


--
Tact is the ability to tell a man he has an open mind when he has a
hole in his head.

(setq reply-to
(concatenate 'string "Paul Foley " "<mycroft" '(#\@) "actrix.gen.nz>"))

Thomas F. Burdick

unread,
Jul 14, 2008, 11:47:53 AM7/14/08
to
On Jul 14, 2:37 pm, Mark Wooding <m...@distorted.org.uk> wrote:
> Maciek Pasternacki <ja...@zenbe.com> wrote:
> > Is it any less likely than (MEMBER :NIL *FEATURES*) not being NIL?
>
> Remember that NIL (New Implementation of Lisp) was actually Lisp system
> -- and one of the inspirations for Common Lisp.  Presumably, NIL indeed
> did put :NIL in *FEATURES*.
>
> Note that NIL (as opposed to :NIL) is not likely to be an element of
> *FEATURES*, even on NIL, and it is still a symbol.  Of course, #+ and #-
> bind *PACKAGE* to the KEYWORD package (2.4.8.17), but you can still type
> NIL as (), so...

Your thinking is completely backwards here. NIL already names a pre-
Common MACLISP successor. The name is taken, meaning you should be no
more likely to find a future Common Lisp implementation that calls
itself NIL than INTERLISP, MACLISP or LISP 1.5. I'm pretty sure your
code demends on at least CLTL if not ANSI Common Lisp, so it's not
going to run out of the box on NIL anyhow.

> Alternatively, :T is also unlikely to be on *FEATURES*, since T is/was
> an dialect/implementation of Scheme.  Therefore, #+t may be considered a
> safe way of omitting the next S-expression.
>
> Objectionable, no? ;-)

Yes :-)

xah...@gmail.com

unread,
Jul 14, 2008, 6:48:43 PM7/14/08
to
Xah Lee wrote:
«
Fundamental Problems of Lisp
http://xahlee.org/UnixResource_dir/writ/lisp_problems.html
»

Jon Harrop wrote:
> Xah, I love you, we should become friends!
>
> There seems to be no real contents in your postings, only some pseudo
> scientific Lisp bashing.
> Exactly the same art I'm specialized in.
>
> Congrats, keep up your good work! Together we will win them all!

I must say, sometimes i lookup to your courage in frequent cross
posting, even though i consider your posts are proper with respect to
the various forum's explicit or implicit charters. (though, i do see
your tendency to peddle your website, and freely inject your little
personal gripes about Mathematica or whatever)

When i cross post, and if my subject or opinion is controversial, and
or my writting demeanor is to be non-conformal, i limit myself to
maybe 1 post per week or month, as a matter of self-imposed discipline
and respect for the larger community. I've been following this more or
less since about 2004.

And, when i post controversial or non-conformal ways, i made sure i
spend great time on it. (1 or 2 hours is typical. 6 hours composition,
broken into multiple days, is not unusual) I almost never, do a post
that's trivial like just few lines. (i've been gradually relaxing this
rule in recent years, however.)

For example, some of these philosophies i've written publically before
(often with the result of being ostracized from the community).

• Philosophies of Netiquette
http://xahlee.org/UnixResource_dir/writ/phil_netiquette.html

• “Old School Netiquette (The traffic of Well-written vs One-liner
posts)”
http://xahlee.org/UnixResource_dir/writ/os_netiquette.html

My own dilemma in recent years, is whether i shall keep aloof with
some sense of immaculateness in limiting sensitive posts to a few, yet
persistent possibly until i die. Or, should i just “relax”, mix-in,
adapt more of a every-body-is-a-friend writing style, and post
profusely, like multiple posts per day, with just one or two line per
post (like “thanks, but i don't agree.”), like them.

The litanies of nagging has its powers.

For example, in recent years i have spent great energy in emacs lisp.
I spent several months out of my decade long keyboarding experience to
have deviced a ergonomic shortcut for emacs (or any text editing tasks
on computer keyboard). (been thinking of patent it) By my usual
practice, i would put it on my web page (so it's public), make a
announcement in appropriate forums once, and never speak of it again.
The basic philosophy is that I, don't do peddling. If it is good, let
people come to it. Marketing is a necessity, but its not something I,
shall deign to do. Like, if Einstein invented relativity, and nobody
belived it, that's their problem. History, will possibly eventually
recognize good things, possibly a while after the inventor is dead.
(long list of examples here... e.g. Dvorak keymap in our context.
(btw, Richard Stallman, is somewhat aloof like this, however, he
invented the the Gnu General Public (viral) License, Free Software
Foundation, full-fledged with laws and lawers, which in the end made
him and his ideas successful, as opposed to the huge number of free-
spirited software such as BSDs etc. (Richard Stalman, also, freely
abused English words such as “hacker”, “freedom”, to sell his
ideas.)))

But, i have second thoughts. Fame, power, leadership, seduces me. For
example, instead of my aloof behavior, i could just be like a “normal”
human animal. When i see people asking about difficult emacs
keybindings in emacs forums, which happens frequently maybe at least
once a month, i could just say, “hey, by chance i did this keymap. Try
it out, maybe it'll help!”. And whenever i did minor update to my page
about it, or have some minor thoughts about my keymap design, i'll
just post: “hi guys, thanks a lot for previous feedback. Recently i've
been thinking xyz design, what do you think?” Usually, the more
trivial the question, the more numerous the reply. People, especially
in modern society, in particular the tech geekers, are a very lonely
bunch. They are EAGER to help, contribute their opinions. We NEED the
emontional touch. (every book on friendship, leadership or politics,
will tell you about the importance of establishing supporters) Also,
avoid making a post that's more than, say, 2 short paragraphs long, or
construct very logical sentences, or use big words. That makes you
less approachable.

I'm not sure Socrates or Plato would approve such relationship style.
But by Allah, didn't Goddess Fortuna put Socrates to death by poison
drinking?

Ok, 2.5 hours went into this post. I shall make a stop and post what i
have now, lest i become unapproachable.

Xah
http://xahlee.org/


Vassil Nikolov

unread,
Jul 14, 2008, 8:50:42 PM7/14/08
to

On Mon, 14 Jul 2008 11:24:59 +0200, Maciek Pasternacki <ja...@zenbe.com> said:

| On Sun, 2008-07-13 at 20:36 -0500, Rob Warnock wrote:

|| ...


|| Yes, it depends upon
|| (INTERSECTION '(:+ :-) *FEATURES*) being NIL, but that's
|| really, *really* unlikely to be violated.

| Is it any less likely than (MEMBER :NIL *FEATURES*) not being NIL?

Here is one reason why `#+NIL' is more fragile than `#+-': consider
how this innocently-looking code,

(pushnew (intern (string feature) :keyword) *features*)

would lose if FEATURE is NIL (say, because of an initialization
bug).

---Vassil.

Vassil Nikolov

unread,
Jul 14, 2008, 9:03:44 PM7/14/08
to

On Mon, 14 Jul 2008 08:47:53 -0700 (PDT), "Thomas F. Burdick" <tbur...@gmail.com> said:

| On Jul 14, 2:37 pm, Mark Wooding <m...@distorted.org.uk> wrote:
|| Maciek Pasternacki <ja...@zenbe.com> wrote:
|| > Is it any less likely than (MEMBER :NIL *FEATURES*) not being NIL?
||
|| Remember that NIL (New Implementation of Lisp) was actually Lisp system
|| -- and one of the inspirations for Common Lisp.  Presumably, NIL indeed
|| did put :NIL in *FEATURES*.
||
|| Note that NIL (as opposed to :NIL) is not likely to be an element of
|| *FEATURES*, even on NIL, and it is still a symbol.  Of course, #+ and #-
|| bind *PACKAGE* to the KEYWORD package (2.4.8.17), but you can still type
|| NIL as (), so...

| Your thinking is completely backwards here. NIL already names a pre-
| Common MACLISP successor. The name is taken, meaning you should be no
| more likely to find a future Common Lisp implementation that calls
| itself NIL than INTERLISP, MACLISP or LISP 1.5. I'm pretty sure your
| code demends on at least CLTL if not ANSI Common Lisp, so it's not
| going to run out of the box on NIL anyhow.

Nil novum sub soli (pun intended): see
<http://groups.google.com/group/comp.lang.lisp/msg/841ab3ac2a9d5846>,
(especially the two paragraphs starting with "But part of the intent").

Kaz Kylheku

unread,
Jul 14, 2008, 9:03:54 PM7/14/08
to

There are two nice ways to exclude EXPR:

#+(or) EXPR
#-(and) EXPR

The virtue is that these are not hinged to the presence or absence of
any symbol in *FEATURES*.

John Thingstad

unread,
Jul 15, 2008, 3:04:13 PM7/15/08
to
På Sun, 13 Jul 2008 16:53:38 +0200, skrev xah...@gmail.com
<xah...@gmail.com>:

comp.lang.lisp is a group for Common Lisp.
Many of us have hundreds of thousands of lines of code written in that
language.
Some of us need to get work done and have no time to wine over minor
improvements.
If it breaks the code base it is not welcome.
That does not mean I do not want a cleaner more coherent lisp.
I have studied Hascell, ML, OCALM and Mathematica too.
But it wouldn't be Common Lisp and I would discuss it on
comp.lang.functional.

Besides your bad english and lack of respect, etiquette and manners makes
it less than rewarding to discuss with you.

--------------
John Thingstad

xah...@gmail.com

unread,
Jul 15, 2008, 4:32:50 PM7/15/08
to
Addendum:

in lisp communities, it is widely recognized that lisp's regular
syntax has the property that “code is data; data is code”. However,
there was never, clear, explanation what this means exactly.

Here's what it means exactly, in one concise paragarph.

A regular nested syntax, makes it easy (possible) to do source code
transformations with a lexical scan. (think of XML. See
http://en.wikipedia.org/wiki/XML_transformation_language )

The consequence of the ability to do such source code transformation,
are many as i discussed in previous article. (see
http://xahlee.org/UnixResource_dir/writ/lisp_problems.html (Among
which, is lisp's so-called “macros”, pattern matching or term
rewriting (lisp's so-called “macros” is simple form of so-called term-
rewriting).))

among lispers, often when people ask what it means about lisp's “code
is data; datais code”, usually they are unable to explain it exactly,
because they don't possess mathematician's analytic abilities. Here
i'll repeat, and please remember it.

A regular nested syntax, makes it possible to do systimatic and
generalized source code transformations and trivial to implement.
There are important consequences. Some of the examples are: lisp's
macros, general pattern matching, term rewriting, source code dual
functioning as markup lang for presentation (i.e. word-processor,
notebook), mathematical markup (MathML;LaTeX), in general all benefits
of XML, on-the-fly source code “formatting” for a automatic, uniform,
universal, source code display (aka “coding style convention”).

(Note the phrase “automatic, uniform, universal, source code display”.
The “uniform” and “universal” aspect is a well-known propery of Python
lang's source code. The reason Python's source code has such uniform
and universal display formatting is because it is worked into the
language's sematics. i.e. the semantics of the code depends on the
formatting (i.e. where you press tabs and returns). But also note,
Python's source code is not and cannot be automatically formatted,
precisely because the semantics and formatting is tied together, with
a inprecise relation. A strictly regular nested syntax, such as
Mathematica's, can, and is done, since 1996. Lisp, despite its bunch
of irregularities such as thos «` ' # ; ,» chars, i think it still can
have a automatic formatting at least to a large, practical, extent.
(one of my future elisp project would be this) Once lisp has automatic
on-the-fly formatting (think of emacs's fill-sexp, auto-fill-sexp),
then lisp code will achieve uniform and universal source code
formatting display. By “uniform”, it is meant that there is one human-
readible cannonical way to display the source code. By “universal” is
meant that all programers, will recognize and habituated with this one
cannonical way, as a standard. (they can of course set their editor to
display it in other ways) The advantage of having a automatic,
uniform, universal, source code display for a language is that, by
having such properties, it will actually have a impact on how
programer codes in the language. i.e. what kind of idioms they choose
to use, where type of comments they make. This, further influences the
evolution of the language, i.e. what kind of functions or features are
added to the lang.

for some detail on this aspect, see:
“The Harm of Manual Code Formating”
http://xahlee.org/UnixResource_dir/writ/hard-wrap.html
)

------------------------------

The other point in my previous article discussed lisp's cons problems.
Here's what it means in a concise, mathematical perspective:

From a mathematical point of view, what this means is that lisp's
lists is limited to a max of 2 elements. If you want a longer list,
you must nest it and interpret it in a special way. (i.e. effectively
creating a mini-protocol of nesting lists, known as proper lists.) The
cons fundamentally crippled the development of list processing.

------------------------------

The cons issue bugged me for 10 years, since i first tried to learn
scheme in ~1999. I've never worked with lisp (other than academic
reading) until in recent years with emacs lisp since 2005. Several
times i tried to explain to lispers this problem, but usually with
paragraphs and paragraphs of descriptions, analogies, examples,
frustrated by how hard it is to convey such a simple flaw (aided by
their blind, deep-seated, lisp fanaticsm). Yesterday it hit on me. The
above mathematical aspect of lisp's cons is the first time i
formulated the cons problem concisely. (my previous verbose
explanation here: http://xahlee.org/emacs/lisp_list_problem.html
)

Also, about lisp's regular syntax being “data is code; code is
data”... it was also my first time seeing it clearly. (in my 10 years
of comp.lang.lisp reading, you read confusions.)

Xah
http://xahlee.org/

Christophe

unread,
Jul 15, 2008, 5:03:37 PM7/15/08
to


I beg your pardon in advance but, your post is just a joke.

Do you think really that they only one syntax in Lisp ? I hope no !

The real power of Lisp is : it's a pure system to create DSL.

Best regards, Christophe

Christophe

unread,
Jul 15, 2008, 5:09:01 PM7/15/08
to

They are no problem with cons, Community publish a lot of articles to
explain how avoid it. Read this before.

Matthias Buelow

unread,
Jul 15, 2008, 7:47:27 PM7/15/08
to
xah...@gmail.com wrote:

> Like, if Einstein invented relativity, and nobody
> belived it, that's their problem.

You're not Einstein, even though you probably believe you are.

xah...@gmail.com

unread,
Jul 15, 2008, 8:01:17 PM7/15/08
to
John,

don't begin, to be a lisp moron.

John wrote:
« Some of us need to get work done and have no time to wine over minor
improvements. If it breaks the code base it is not welcome. »

Seeds of ideas, code, got mutilated by Common Lisp fuckheads, before
it even had a chance for proper discussion.

Like, suppose you are thinking about some issues of a greener planet.
Before you begin, some Bush fuckhead shouts: “No, changing human habit
is not likely. We want our trucks.”.

That's what you are doing now, not unlike, the gazillion Common Lisp
fuckheads are doing in “comp.lang.lisp”.

John wrote:
«comp.lang.lisp is a group for Common Lisp.»
«But it wouldn't be Common Lisp and I would discuss it on
comp.lang.functional.»

comp.lang.lisp is a group for lisp, not just for Common Lisp.

Go create your own “comp.lang.lisp.common”.

«Besides your bad english and lack of respect, etiquette and manners
makes it less than rewarding to discuss with you.»

The respect in my response to people's writings is based on this
ratio: (knowledge+love)/disrespectfulness exhibited in their posts.
(for example, if disrespectfulness is constant, then the greater their
knowledge and love, the greater will be my respect for them. Suppose
the knowledge+love is constant, then the greater their outward
disrespect, will gain greater of my disrepsect. If their knowledge
+love is greater than their outward disrespect, then overall they
still gain my respect. However, if their knowledge+love is less than
their show of disrespectfulness, then i dispise them.)

We all have different levels of IQs, environment we grew up, areas of
expertise, weaknesses. No human animal, knows all (in fact in modern
word hardly any human animal knew 1/10^googolplex percent of
knowledge). This is when discussion, comes in. When you know
something, and you sincerely believe you know it, dont be shy. When
you don't know something, don't fucking be a ass. The problem with
most sophomorons, is not knowing the extent of their ignorance.

When i encounter tech geekers, usually they don't know shit of the
subject relative to me, yet they are so aggressive, militant, to the
point to ban me or whatnot (e.g. eliminating any possible discussion
or explanation i could contribute or defend of their accusations).
That is when, you begin to see fuckheads and motherfucks sprinkled in
my writings.

My impression of you, is that you are usally if not always, on topic,
post with substance, and i haven't seen you going into wild defensive
drivels or sputtering moronic language xyz dogma like most common
lispers do.

You should buy me pizza.

O, i almost forgot, you wrote: «Besides your bad english....».

The level of badness of my english, is proportional to the number of
grammar pundits in the world (you can see them slaving in
alt.usage.english, for example). When society ceases to be influenced
by these morons, my english might become something you would
characterize as orthodox.

Further readings:

“Language and English”
http://xahlee.org/Periodic_dosage_dir/bangu/bangu.html

--------------------

PS 2 recently posted message here that touched on netiquette, is
archived permanently here:

What Do Tech Geeking Morons Want?
http://xahlee.org/UnixResource_dir/writ/techgeeking_morons.html

Aloofness vs Approachable
http://xahlee.org/UnixResource_dir/writ/aloof_vs_approachable.html

Xah
http://xahlee.org/

jos...@corporate-world.lisp.de

unread,
Jul 15, 2008, 10:13:22 PM7/15/08
to
On 15 Jul., 22:32, "xah...@gmail.com" <xah...@gmail.com> wrote:
> Addendum:
>
> in lisp communities, it is widely recognized that lisp's regular
> syntax has the property that “code is data; data is code”. However,
> there was never, clear, explanation what this means exactly.
>
> Here's what it means exactly, in one concise paragarph.

You are still totally confused.

Code is data and data is code:

Lisp uses the same external s-expression representation of Lisp
data for Lisp code.
Lisp programs can read, print and manipulate Lisp code like any
other Lisp data.

> Mathematica's, can, and is done, since 1996. Lisp, despite its bunch
> of irregularities such as thos «` ' # ; ,» chars, i think it still can
> have a automatic formatting at least to a large, practical, extent.

Sure it can. Many years before Mathematica it could already.

> (one of my future elisp project would be this)

Would be? So it isn't?

> Once lisp has automatic
> on-the-fly formatting (think of emacs's fill-sexp, auto-fill-sexp),
> then lisp code will achieve uniform and universal source code
> formatting display. By “uniform”, it is meant that there is one human-
> readible cannonical way to display the source code. By “universal” is
> meant that all programers, will recognize and habituated with this one
> cannonical way, as a standard. (they can of course set their editor to
> display it in other ways) The advantage of having a automatic,
> uniform, universal, source code display for a language is that, by
> having such properties, it will actually have a impact on how
> programer codes in the language. i.e. what kind of idioms they choose
> to use, where type of comments they make. This, further influences the
> evolution of the language, i.e. what kind of functions or features are
> added to the lang.

This has been done already several times. But it hasn't found much
following in the last years.
See chapter 16 of http://www.bitsavers.org/pdf/xerox/interlisp/3101273_InterlispD_2_Oct85.pdf
for the most prominent attempt.

Structure editors made sure that every source manipulation would
result in a valid s-expression.

Editors like Emacs allow us to write invalid or partially valid s-
expressions:

(defun foo a b + a b is not a valid s-expression. We can make it
valid:

(defun foo a b + a b) this is a valid s-exypression, but not valid
Lisp code. We can make it valid:

(defun foo (a b) (+ a b)) this is both a valid s-expression and
valid Lisp code.

A structure editor usually would allow only to create valid s-
expressions. Otherwise it would need to know how to deal
with invalid s-expressions (input, formatting, ...).

So, the most primitive approach would be to type free form in Emacs,
read the code using some command and then
use pretty printing to display the result in the buffer.
That's relatively easy to implement.

> ------------------------------
>
> The other point in my previous article discussed lisp's cons problems.
> Here's what it means in a concise, mathematical perspective:
>
> From a mathematical point of view, what this means is that lisp's
> lists is limited to a max of 2 elements. If you want a longer list,
> you must nest it and interpret it in a special way. (i.e. effectively
> creating a mini-protocol of nesting lists, known as proper lists.) The
> cons fundamentally crippled the development of list processing.

Hmm, sounds completely confused.

Why struggle with this? Write some code and be happy. Maybe use
Mathematica instead?

xah...@gmail.com

unread,
Jul 16, 2008, 1:33:10 AM7/16/08
to
Dear Rainer Joswig,

Rainer wrote:
> Code is data and data is code:
>
> Lisp uses the same external s-expression representation of Lisp
> data for Lisp code.
> Lisp programs can read, print and manipulate Lisp code like any
> other Lisp data.

Yeah, and?

I wrote: «A regular nested syntax, makes it possible to do systematic
source code transformation in a way that's also trivial to implement.


There are important consequences. Some of the examples are: lisp's

macros, structural pattern matching, term rewriting, source code dual
functioning as markup lang for presentation (e.g. word-processor,
Mathematica's “Notebook”), mathematical markup (e.g. MathML), in
general all benefits of XML, on-the-fly source code “formatting” for a
automatic, uniform, universal, source code display (aka “coding style
convention”).»

Did you disagree with this? Further, your statement is basically
equivalent with mine, and, if i may argue, mine is more general and
clear, stated in a way understandable to any programer, and applicable
to any langs, as opposed to the lisp's in-world view with its fucking
readers and printers and motherfucking “objects”. Are you saying my
statement is wrong?

I dont' care about politness in newsgroup, but in discussion, you need
to acknowledge points you recognize as valid or worthy to make
progress, ok?

About automatic formatting of code, you wrote:
«Sure it [common lisp] can. Many years before Mathematica it could
already.»

We discussed this in a thread about ~3 months ago. (and at least once
before that too) What is your problem?

In that thread, if i may summarize: some experienced common lisp coder
posted his first version of code to do the reformatting of lisp code,
you, and other Common Lisp morons, sprang to feet and chocked him out
of breath. The final outcome of the thread is that, Common Lisp can
reformat the code, but will lose comments (and few other problems
(such as dealing with macros or something)), which is not usable for
the purpose of automatically formatting source code for editing. If i
recall correctly, i made the last post in that thread summarize the
situation.

I don't want to spend 5 min to google up that thread, because it is no
use to you and other common lisp fuckheads. (for those interested, go
to groups.google.com, view comp.lang.lisp group, then search for “Xah,
Rainer” (or joswig) in that group, then arrange by date. It should be
on the first few pages.)

The number one Common Lisp moron slaving in comp.lang.lisp, keeping a
vigil to smother any seed of progress that may be out of CL tradition,
is currently probably you.

Also, you (and quite a handful of other CL morons) have a nasty habit,
which i also stated in the past half year. Namely, you patently ignore
any pertinent point about other langs that has been brought up, but
always drive the discussion into CL technicalities. This is done to a
degree that you and your cohorts seem even unwilling or unable to show
code in emacs lisp. Do you have any expertise or familiarity in any
other high level lang at all?

Jon Harrop commented once (within the past half year), that a problem
with Common Lisp old hats is that you morons (MY term. Yay!) don't
really know any modern functional langs.

Did you one day got relevation from Zeus, and he told you Common Lisp
is the greatest lang on earth?

This is likely my last post in this thread. Drivel is starting to flow
in. I've had enough writing excursion this week.

PS I'm posting this reply back to all the groups that started this
thread in: comp.lang.lisp, comp.emacs, comp.lang.scheme,
comp.lang.functional . The rational is that, so you Common Lispers (or
any single lang fanatics), dont get into a cartel of patting each
other's back.

Xah
http://xahlee.org/

Christophe

unread,
Jul 16, 2008, 5:04:14 AM7/16/08
to

xah...@gmail.com a écrit :

We found the Harrop Ningen Copy.

Just a question, what is the interest of this topic ?

Best Regards,

Christophe

Tamas K Papp

unread,
Jul 16, 2008, 5:30:32 AM7/16/08
to
On Tue, 15 Jul 2008 21:04:13 +0200, John Thingstad wrote:

> På Sun, 13 Jul 2008 16:53:38 +0200, skrev xah...@gmail.com
> <xah...@gmail.com>:
>

> Besides your bad english and lack of respect, etiquette and manners
> makes it less than rewarding to discuss with you.

Then why are you guys doing it? He writes these posts because he
believes that he has an audience here.

I just switched newsreaders recently. When it loaded the headers, I
realized that there was something wrong. In a minute, Xah and Harrop got
score -9999, forever, end of problem.

Have a nice day,

Tamas

jos...@corporate-world.lisp.de

unread,
Jul 16, 2008, 7:43:03 AM7/16/08
to
On 16 Jul., 07:33, "xah...@gmail.com" <xah...@gmail.com> wrote:


> Dear Rainer Joswig,

Dear Xah!

>
> Rainer wrote:
> > Code is data and data is code:
>
> >    Lisp uses the same external s-expression representation of Lisp
> > data for Lisp code.
> >    Lisp programs can read, print and manipulate Lisp code like any
> > other Lisp data.
>
> Yeah, and?
>
> I wrote: «A regular nested syntax, makes it possible to do systematic
>
> source code transformation in a way that's also trivial to implement.
> There are important consequences. Some of the examples are: lisp's
> macros, structural pattern matching, term rewriting, source code dual
> functioning as markup lang for presentation (e.g. word-processor,
> Mathematica's “Notebook”), mathematical markup (e.g. MathML), in
> general all benefits of XML, on-the-fly source code “formatting” for a
> automatic, uniform, universal, source code display (aka “coding style
> convention”).»
>
> Did you disagree with this? Further, your statement is basically
> equivalent with mine, and, if i may argue, mine is more general and
> clear, stated in a way understandable to any programer, and applicable
> to any langs, as opposed to the lisp's in-world view with its fucking
> readers and printers and motherfucking “objects”. Are you saying my
> statement is wrong?

It's missing the core of the issue. code as data is not about syntax.
It's a question
a simple representation of code and a function from external source to
code as data (-> READ)
and code as data to external source (-> PRINT). There are other syntax
variants (say, like
XML) that can be used for that. s-expressions are relatively primitive
and easy to implement/use. That's one of the features of Lisp, that
this mechanism is relatively simple (compare that to the spec of XML
which includes additional things like Schemas, but no computation).

The transformations in Lisp are not done on textual source. They are
done
on source as data. At that point s-expression syntax is gone (because
it is READ already) and we are talking about syntax over structural
data:
special forms, macros, functions, ...

Lisp dialects usually (the Scheme standard is an exception) see
parsing
of s-expressions as a dynamic feature of the reader. This is both good
and
bad. Good: you get the flexibility to manipulate the reader to do
a lot of interesting things. Bad: there is no fixed syntax.
Just like in Emacs where keystrokes call Lisp functions, reading
characters
will call Lisp functions that decided what to do. The function
for the character ( reads the rest of a list, for-example.

There is no fixed syntax and a fixed programmed scanner/parser for
that syntax in Lisp
(exception: as I mentioned Scheme has a fixed syntax, though Scheme
implementations
will often provide a typical 'read' mechanism as an extension).
That's just the way it is and it offers interesting possibilities,
but also makes it impossible to parse for example arbitrary Common
Lisp
code without a full Common Lisp reader.

> I dont' care about politness in newsgroup, but in discussion, you need
> to acknowledge points you recognize as valid or worthy to make
> progress, ok?

Ok, my point was that you were missing the core of the issue when
insisting on syntax. It's just easy in Lisp, because it is so
'primitive'.

> In that thread, if i may summarize: some experienced common lisp coder
> posted his first version of code to do the reformatting of lisp code,
> you, and other Common Lisp morons, sprang to feet and chocked him out
> of breath. The final outcome of the thread is that, Common Lisp can
> reformat the code, but will lose comments (and few other problems
> (such as dealing with macros or something)), which is not usable for
> the purpose of automatically formatting source code for editing. If i
> recall correctly, i made the last post in that thread summarize the
> situation.

I remember that thread, right.

That's not just a problem of Common Lisp, that's a problem of Lisp in
general.

It's true for a certain class of comments. Mainly comments
for ; and #| ... |#. You can program the reader to get those
comments read, but I haven't seen this done for a long time.
You need to use comments that are part of the s-expressions.
Common Lisp allows documentation strings in certain places.

CL-USER 15 > (defun foo (a) "this is a documentation string" a)
FOO

CL-USER 16 > (documentation 'foo 'function)
"this is a documentation string"

The other thing is to define some comment form that is part of the
source, but
does nothing.

(defun foo (a)
(sin a) (comment 1 "computes the sin of a")
)

(defun comment (level text) (declare (ignore level text)))

What you need to do with the code-as-data approach, is to make
comments to be data and part of the code, too. Check the Interlisp
pointer I gave you, it deals with comments in code.

That's one of the reasons structure editors for Lisp code are
not more popular - most programmers insist on putting
their comments where they want. Take away that facility
and reading, formatting of code gets easier.

I'm not saying that this shouldn't be tried and that it is
not interesting to do that. All I say is that it has been
tried and has some drawbacks. In the XML world structure
editing is common (see XMLspy). In the Lisp world the
discussion on structure vs. text editing was seeing
a heated discussion. Richard Stallman argued against it.

Try to get a copy of the old book 'Interactive Programming
Environments'
(ISBN 0-07-003885-6) by Barstow, Shrobe and Sandewall - 1984. There
you find lots of discussions about these issues. You will find a
letter
of Stallman on page 75 where he argues against structure editing.

Stallman (page 76):
"Here are the advantages of editing text rather than list structure.

1. The user can specify any style of indentation and the system will
never
override it. The editor supplies standard indentation as a
default.
2. Comments are easily stored and formatted as the user likes them.
3. The user can create unbalanced parenthese while editing a
function.
This causes no trouble as as the function is not redefined from
the
text at such times. The user can also move, delele, copy blocks
of syntactically unbalanced text. In a list-structure
editor,these operations
are impossible or require peculiar and unintuitive commands.
4. The editor can provide commands to move over balanced objects ...
5. A text editor can support extended syntax. ...
6. A text editor can be used for languages other than Lisp with no
change. ...
..."

So, Stallman was no fan of structure editing and probably also
not of automatic code formatting (indentation is fine, as long as it
can
be overridden.). Automatic code formatting is part of most
structure editors.

Again, I'm not saying that it (automatic code formatting) should not
be done.
As I mentioned earlier the Symbolics Lisp machine has commands for
that.

Just try to implement it for Emacs, I'll bet it would find some users.

See also:

http://portal.acm.org/citation.cfm?doid=356744.356754
Surveyor's Forum: Structured Editing with a Lisp - Richard Stallman
(unfortunately I don't have a better reference for that).

> The number one Common Lisp moron slaving in comp.lang.lisp, keeping a
> vigil to smother any seed of progress that may be out of CL tradition,
> is currently probably you.

Too much honor.

> Also, you (and quite a handful of other CL morons) have a nasty habit,
> which i also stated in the past half year. Namely, you patently ignore
> any pertinent point about other langs that has been brought up, but
> always drive the discussion into CL technicalities. This is done to a
> degree that you and your cohorts seem even unwilling or unable to show
> code in emacs lisp.

You were talking about Lisp and you were posting to comp.lang.lisp .
Emacs Lisp
is mainly just a subset of Common Lisp (no closures, no CLOS, ...)
anyway.
I don't know why you are so excited about Emacs Lisp. It's a very
small domain specific Lisp variant that was designed to implement
editor
extensions. That's all. For that it does relatively well.
Everybody who understands Common Lisp can learn Emacs Lisp in a day
and
then struggle with the large Emacs library. ;-) The concepts
of Emacs Lisp are all very old and most predate Common Lisp, Scheme
and
other Lisp dialects. Many of the things that the basic Emacs does have
been implemented in Editors written in Scheme or Common Lisp also.

<Drivel deleted>

viper-2

unread,
Jul 16, 2008, 10:13:48 AM7/16/08
to
On Jul 16, 7:43 am, "jos...@corporate-world.lisp.de" <jos...@corporate-

world.lisp.de> wrote:
> On 16 Jul., 07:33, "xah...@gmail.com" <xah...@gmail.com> wrote:
>

> Try to get a copy of the old book 'Interactive Programming
> Environments'
> (ISBN 0-07-003885-6) by Barstow, Shrobe and Sandewall - 1984. There
> you find lots of discussions about these issues. You will find a
> letter
> of Stallman on page 75 where he argues against structure editing.
>

OK, I'll make a note to add this one to my bookshelf!

> > The number one Common Lisp moron slaving in comp.lang.lisp, keeping a
> > vigil to smother any seed of progress that may be out of CL tradition,
> > is currently probably you.
>
> Too much honor.

I must say Rainer that you are, indeed, gracious to reply in such
informative detail to someone who has repeatedly dubbed you a "moron";
this time with no less honour than the "Number One Common Lisp
Moron" .

Still limited in English, Xah misinterprets Stallman's use of "hacker"
and "freedom" as abuse. Perhaps he believes the word "moron" is
complimentary?

> > Also, you (and quite a handful of other CL morons) have a nasty habit,
> > which i also stated in the past half year. Namely, you patently ignore
> > any pertinent point about other langs that has been brought up, but
> > always drive the discussion into CL technicalities. This is done to a
> > degree that you and your cohorts seem even unwilling or unable to show
> > code in emacs lisp.
>

> I don't know why you are so excited about Emacs Lisp.

I think the problem is that Xah craves recognition for his technical
abilities. He, like many of us, is still struggling to master Common
Lisp. Xah tries to compensate by parlaying his knowledge of Emacs
Lisp. But to expect members of this group to reply in kind with Elisp
code, would be asking us to pander.

As Xah himself said:

Regarding your patronizing concern and officious
advice of learning Common Lisp, you might want
to be acquainted with the fact i have no interest
in learning Common Lisp whatsoever.

http://groups.google.com/group/comp.lang.lisp/msg/6809921006d8ca28?hl=en

So I think the latter is Xah's own admission, himself, that he might
be more at home in a group that discusses Emacs Lisp. As you noted,
comp.lang.lisp is for discussions about Common Lisp - i.e. "CL
technicalities".

--agt

Rainer Joswig

unread,
Jul 16, 2008, 10:59:24 AM7/16/08
to
In article
<b543d1ed-6cf4-441a...@s50g2000hsb.googlegroups.com>,
viper-2 <visi...@mail.infochan.com> wrote:

> On Jul 16, 7:43 am, "jos...@corporate-world.lisp.de" <jos...@corporate-
> world.lisp.de> wrote:
> > On 16 Jul., 07:33, "xah...@gmail.com" <xah...@gmail.com> wrote:
> >
>
> > Try to get a copy of the old book 'Interactive Programming
> > Environments'
> > (ISBN 0-07-003885-6) by Barstow, Shrobe and Sandewall - 1984. There
> > you find lots of discussions about these issues. You will find a
> > letter
> > of Stallman on page 75 where he argues against structure editing.
> >
>
> OK, I'll make a note to add this one to my bookshelf!

I think it's a real classic.

> > > The number one Common Lisp moron slaving in comp.lang.lisp, keeping a
> > > vigil to smother any seed of progress that may be out of CL tradition,
> > > is currently probably you.
> >
> > Too much honor.
>
> I must say Rainer that you are, indeed, gracious to reply in such
> informative detail to someone who has repeatedly dubbed you a "moron";
> this time with no less honour than the "Number One Common Lisp
> Moron" .

He is a moron, too. ;-) He posts to the wrong newsgroups most
of the time, insults a lot of people, writes stuff that
insults whole group of people, etc. But I'll give him
a bonus sometimes, since he tries to learn some of that stuff, writes
things down and thinks whether it is useful or not. He then
posts it again to the wrong newgroups. Okay. But it is quite
useful to think for example about usability and even though
Emacs is quite some achievement, stuff like the keyboard mappings
are a real pain. So, thinking about it and how to improve that
is very useful, IMHO. With other stuff he is on the wrong track.
But it might interest him to know that some people disagree and why.
When things get too ugly I stop responding...

> > I don't know why you are so excited about Emacs Lisp.
>
> I think the problem is that Xah craves recognition for his technical
> abilities. He, like many of us, is still struggling to master Common
> Lisp.

He is struggling to master Emacs Lisp, I'd say. Though I'm surprised
a bit - Emacs Lisp is not that difficult. Sometimes it is
a hurdle and after getting over some hurdle it suddenly gets much
easier. Typical hurdles for Lisp are understanding closures,
for Scheme it would be continuations, for Haskell it would be monads.
But Emacs Lisp doesn't have that stuff.

If he posts some Lisp code and wants feedback (even better if it were
in the correct newsgroup), fine by me. I think newsgroups
like comp.lang.lisp are a great way to get feedback from
very different people. I'm learning from that, too. One
just has to learn to live with all the different opinions.
One problem with posting Emacs Lisp code or questions is
that one gets Common Lisp answers back - quite often. It's
the preferred language on comp.lang.lisp - IMHO.
But often the answers can be adapted to some other dialects.

One thing that interests me is to understand what helps people
over the initial hurdles to start doing useful things with Lisp.
I had last month some communication with a student, who
was learning some Lisp and he and his tutor asked me to give him some
tasks. I was positively surprised to see that the student was
able to do some useful coding (in Common Lisp using the
LispWorks Personal Edition) after a relatively short
period of time. There was one point where he was struggling
with a CAPI callback. I explained the use of closures for that
and he got it and understood why that is a useful thing.
That was a good sign for me.

Btw., the frog seller has no interest in Lisp at all and just
spams here - so there is no point to respond to that guy.
That other troll that we see here just posts simple questions
and has no idea what to do with the answers.

> Xah tries to compensate by parlaying his knowledge of Emacs
> Lisp. But to expect members of this group to reply in kind with Elisp
> code, would be asking us to pander.
>
> As Xah himself said:
>
> Regarding your patronizing concern and officious
> advice of learning Common Lisp, you might want
> to be acquainted with the fact i have no interest
> in learning Common Lisp whatsoever.
>
> http://groups.google.com/group/comp.lang.lisp/msg/6809921006d8ca28?hl=en
>
> So I think the latter is Xah's own admission, himself, that he might
> be more at home in a group that discusses Emacs Lisp. As you noted,
> comp.lang.lisp is for discussions about Common Lisp - i.e. "CL
> technicalities".

I don't think comp.lang.lisp is for exclusive discussions of
Common Lisp. It is just that many here use Common Lisp or are interested
in it. The newsgroup is equally there for discussing other Lisp
dialects. Though the usual rule would be to use the most
specific newsgroup. Common Lisp has no other specific newsgroup,
so it's discussed here. Scheme has comp.lang.scheme, Emacs Lisp
has some Emacs related newsgroup. Most Emacs-Lisp-specific postings
belong there. Many other Lisps and implementations are discussed
on specific mailing lists. See here:

http://dir.gmane.org/index.php?prefix=gmane.lisp

>
> --agt

--
http://lispm.dyndns.org/

Pascal J. Bourguignon

unread,
Jul 16, 2008, 11:02:33 AM7/16/08
to
"jos...@corporate-world.lisp.de" <jos...@corporate-world.lisp.de> writes:


C has a syntax for data:

Something s={{1,2,"abc",{3,4}},42};

Assuming the right header, and/or the right language extension, in C
we could write programs as data:

Form form={"if",{"a","==",42},
{"printf",{"\"got it\\n\""}},
"else",
{"printf",{"\"a=%d\\n\"","a"}}};

void example(){
eval(form);
}

Do you still think syntax doesn't matter for the usability of
program <=> data <=> program?

Notice how when we write programs (in any programming language), the
separator of terms in the sentences (statements, expressions) is the
space:

if a=b then writeln('Hello');

(if (= a b) (writeln "Hello"))
vs.
{if,{a,=,b},{writeln,{"Hello"}}}


Notice also how the first iteration of LISP used commas to separate
elements in list. We could have spaces in symbol names:

(WITH OPEN FILE,(MY FILE,SRC.TXT),(READ,MY FILE))

happily, quickly enough the inventors of lisp realized it was better
(for pgm<=>data) to use the space rather than the comma.

> Ok, my point was that you were missing the core of the issue when
> insisting on syntax. It's just easy in Lisp, because it is so
> 'primitive'.

Well, it's not because lisp syntax is easy and primitive that it is
not a determinant factor in the quality of the language.

> You were talking about Lisp and you were posting to comp.lang.lisp .
> Emacs Lisp is mainly just a subset of Common Lisp (no closures, no
> CLOS, ...) anyway.

It is not a subset of Common Lisp in the legal sense. The problem
being that (declare (special var)) is not mandatory. But there is a
subset of emacs lisp that is a subset of Common Lisp indeed.
http://www.lispworks.com/documentation/HyperSpec/Body/01_g.htm

--
__Pascal Bourguignon__

Rainer Joswig

unread,
Jul 16, 2008, 11:29:58 AM7/16/08
to
In article <7c7ibla...@pbourguignon.anevia.com>,

I know. Lot's of programming languages have syntax for data.

>
> Something s={{1,2,"abc",{3,4}},42};
>
> Assuming the right header, and/or the right language extension, in C
> we could write programs as data:
>
> Form form={"if",{"a","==",42},
> {"printf",{"\"got it\\n\""}},
> "else",
> {"printf",{"\"a=%d\\n\"","a"}}};
>
> void example(){
> eval(form);
> }
>
>
>
> Do you still think syntax doesn't matter for the usability of
> program <=> data <=> program?

Do I think that? Of course it matters for usability.

Would I rather write

(a b c)

or

<s-expression>
<atom>a</atom>
<atom>b</atom>
<atom>c</atom>
</s-expression>

and use the whole XML machinery?

> Notice how when we write programs (in any programming language), the
> separator of terms in the sentences (statements, expressions) is the
> space:
>
> if a=b then writeln('Hello');
>
> (if (= a b) (writeln "Hello"))
> vs.
> {if,{a,=,b},{writeln,{"Hello"}}}
>
>
> Notice also how the first iteration of LISP used commas to separate
> elements in list. We could have spaces in symbol names:
>
> (WITH OPEN FILE,(MY FILE,SRC.TXT),(READ,MY FILE))
>
> happily, quickly enough the inventors of lisp realized it was better
> (for pgm<=>data) to use the space rather than the comma.

Depends on the use case. Now you write:

(|Albert Einstein| |Max Planck| |Marie Curie|)

Instead of

(Albert Einstein, Max Planck, Marie Curie)


> > Ok, my point was that you were missing the core of the issue when
> > insisting on syntax. It's just easy in Lisp, because it is so
> > 'primitive'.
>
> Well, it's not because lisp syntax is easy and primitive that it is
> not a determinant factor in the quality of the language.
>
>
>
> > You were talking about Lisp and you were posting to comp.lang.lisp .
> > Emacs Lisp is mainly just a subset of Common Lisp (no closures, no
> > CLOS, ...) anyway.
>
> It is not a subset of Common Lisp in the legal sense. The problem
> being that (declare (special var)) is not mandatory. But there is a
> subset of emacs lisp that is a subset of Common Lisp indeed.
> http://www.lispworks.com/documentation/HyperSpec/Body/01_g.htm

I'm not talking about the legal sense. There is no way to get
a legal label for a language to be a subset of CL.

Emacs Lisp is a subset 'conceptually' - minus some 'minor'
differences. Many Emacs Lisp programs can be translated to Common Lisp
(minus the Emacs Lisp library) without much change. There
is some mismatch with some data structures.

There are other related languages which are more like
'subsets' of Common Lisp: SubL, CL0, ...

--
http://lispm.dyndns.org/

viper-2

unread,
Jul 16, 2008, 12:56:08 PM7/16/08
to
On Jul 16, 10:59 am, Rainer Joswig <jos...@lisp.de> wrote:
>
> I don't think comp.lang.lisp is for exclusive discussions of
> Common Lisp. It is just that many here use Common Lisp or are interested
> in it. The newsgroup is equally there for discussing other Lisp
> dialects.

Your tolerance is commendable, for how else would people like Xah
learn? It seems you would make an excellent professor, unlike me. I
have neither the patience nor the interest.

I do recognize that cll is not exclusively for discussions in Common
Lisp. In fact, comparisons with other dialects, here, might invite
plurality and debate leading to more profound understanding of CL
itself.

I think the point I was trying to make is that Xah seems to consider
responses in terms of "CL technicalities" (from a newsgroup primarily
concerned with CL) to be "moronic".

I'm coding in law temporarily, not Lisp (unfortunately); got to
compile - and run! ;-)

--agt

xah...@gmail.com

unread,
Jul 16, 2008, 6:46:03 PM7/16/08
to
Dear Rainer,

You wrote: «It's missing the core of the issue. code as data is not
about syntax. ... Lisp dialects usually (the Scheme standard is an


exception) see parsing of s-expressions as a dynamic feature of the

reader. This is both good and bad. ... »

When a language, such as Lisp or Mathematica, that deals with symbols,
the 2 formulation about “code⇔data” is equivalent, ok?

Sure you can bury your head into Common Lisp technicalities, by
starting to bitch about how Scheme Lisp is breaking the “code⇔data”
property.

Also, you may or may not be aware, that people are making XML into a
general purpose language. i.e. a language with XML as syntax. (e.g.
O:XML ( http://www.o-xml.org/ ), and to a lesser degree MathML and XML
transformation language ( http://en.wikipedia.org/wiki/XML_transformation_language
))

About a tool that autoformat lisp code, you wrote: «That's not just a
problem of Common Lisp, that's a problem of Lisp in general. ...


There is no fixed syntax and a fixed programmed scanner/parser for
that syntax in Lisp (exception: as I mentioned Scheme has a fixed

syntax, though Scheme implementations ... It's true for a certain


class of comments. Mainly comments for ; and #| ... |#. You can
program the reader to get those comments read, but I haven't seen this
done for a long time. You need to use comments that are part of the s-

expressions. Common Lisp allows documentation strings in certain
places. ... »

So, you are implicitly admitting, one of my ciritism of lisp
( http://xahlee.org/UnixResource_dir/writ/lisp_problems.html ), that
the irregularities of lisp syntax (e.g. “; ”) is a problem?

Further, practically speaking, today there's no tool to autoformat
lisp code as i described in my criticism (see the link above for
detail ). This is a practical need. You kept meddeling with this
negative fact, yet kept talking about how Common Lisp can and have in
the past done great using CL's read/print notions that have just
“minor” issues, adding belittering remarks about how i could
contribute by creating such a tool. What is your problem? Can you not
see, your CL fanaticism is doing harm to lisp in general and CL as
well?

(The thread about creating a lisp re-indenting tool is here:
Newsgroups: comp.lang.lisp
From: Jeremy Smith
Date: Sat, 26 Jan 2008 19:16:47 GMT
Subject: Lisp indenting tool

http://groups.google.com/group/comp.lang.lisp/browse_thread/thread/e95564e3550bbcfd?tvc=2
)

People, lisp's lack of automatic formatting tool, is a problem. I
described in the above article several paragraphs of details about it.
You may or may not agree the degree of the problem or degree of
benefit, or my views about how this problem occurred. However, having
a automatic formatting tool for lisp would still a great benefit.
Please spread this fact whenever you can. Common Lisp fuckheads, you
need to stop befuddle criticisms.

it looks like the monikor moron for some Common Lispers here, ceases
to appear a hyperbole or playful. (this becomes apparent in another
thread last month or so about Closure. (
http://groups.google.com/group/comp.lang.lisp/browse_thread/thread/634ae034c6a71c66?tvc=2
))

----------------
Postscript:

A post in this thread related to netiquette, is now perm archived
here:
“(Knowledge + Love) / Disrespectfulness”
http://xahlee.org/Netiquette_dir/disrespectfulness.html

Also, this post is posted to: comp.lang.lisp, comp.emacs,
comp.lang.scheme, comp.lang.functional . The post that this post
replies to, is by Rainer only in comp.lang.lisp, can be view here:
http://groups.google.com/group/comp.lang.lisp/msg/65797f4df62df54f?

Xah
http://xahlee.org/

Vassil Nikolov

unread,
Jul 16, 2008, 7:44:17 PM7/16/08
to

On Wed, 16 Jul 2008 17:29:58 +0200, Rainer Joswig <jos...@lisp.de> said:
| ...
| Would I rather write

| (a b c)

| or

| <s-expression>
| <atom>a</atom>
| <atom>b</atom>
| <atom>c</atom>
| </s-expression>

| and use the whole XML machinery?

Or for the language mentioned earlier (where the XSL to generate
code that legacy compilers can recognize is omitted for brevity, but
without doubt the reader will be able to reconstruct it easily),

<?xml version="1.0"?>
<!DOCTYPE translation-unit SYSTEM "ansic-source-draft.dtd">

<ansic:translation-unit>

<ansic:control-line>
<ansic:include>
<ansic:header-name location="system">stdio.h</ansic:header-name>
</ansic:include>
</ansic:control-line>


<ansic:external-declaration>
<ansic:function-definition>

<ansic:declaration-specifiers>
<ansic:type-specifier><ansic:INT/></ansic:type-specifier>
</ansic:declaration-specifiers>
<ansic:declarator>
<ansic:direct-declarator>
<ansic:identifier>main</ansic:identifier>
</ansic:direct-declarator>
<ansic:parameter-type-list>
<ansic:parameter-list>
<ansic:parameter-declaration>
<ansic:declaration-specifiers>
<ansic:type-specifier><ansic:CHAR/></ansic:type-specifier>
</ansic:declaration-specifiers>
<ansic:declarator>
<ansic:pointer><ansic:STAR/><ansic:STAR/></ansic:pointer>
<ansic:direct-declarator>
<ansic:identifier>argv</ansic:identifier>
</ansic:direct-declarator>
</ansic:declarator>
</ansic:parameter-declaration>
<ansic:parameter-declaration>
<ansic:declaration-specifiers>
<ansic:type-specifier><ansic:INT/></ansic:type-specifier>
</ansic:declaration-specifiers>
<ansic:declarator>
<ansic:direct-declarator>
<ansic:identifier>argc</ansic:identifier>
</ansic:direct-declarator>
</ansic:declarator>
</ansic:parameter-declaration>
</ansic:parameter-list>
</ansic:parameter-type-list>
</ansic:declarator>

<ansic:compound-statement>

<ansic:statement>
<ansic:expression-statement>
<ansic:expression>
<ansic:assignment-expression>
<ansic:conditional-expression>
<ansic:logical-OR-expression>
<ansic:logical-AND-expression>
<ansic:inclusive-OR-expression>
<ansic:exclusive-OR-expression>
<ansic:AND-expression>
<ansic:equality-expression>
<ansic:relational-expression>
<ansic:shift-expression>
<ansic:additive-expression>
<ansic:multiplicative-expression>
<ansic:cast-expression>
<ansic:unary-expression>
<ansic:postfix-expression>
<ansic:primary-expression>
<ansic:identifier>puts</ansic:identifier>
</ansic:primary-expression>
<ansic:argument-expression-list>
<ansic:assignment-expression>
<ansic:conditional-expression>
<ansic:logical-OR-expression>
<ansic:logical-AND-expression>
<ansic:inclusive-OR-expression>
<ansic:exclusive-OR-expression>
<ansic:AND-expression>
<ansic:equality-expression>
<ansic:relational-expression>
<ansic:shift-expression>
<ansic:additive-expression>
<ansic:multiplicative-expression>
<ansic:cast-expression>
<ansic:unary-expression>
<ansic:postfix-expression>
<ansic:primary-expression>
<ansic:string-literal>"hello\n"</ansic:string-literal>
</ansic:primary-expression>
</ansic:postfix-expression>
</ansic:unary-expression>
</ansic:cast-expression>
</ansic:multiplicative-expression>
</ansic:additive-expression>
</ansic:shift-expression>
</ansic:relational-expression>
</ansic:equality-expression>
</ansic:AND-expression>
</ansic:exclusive-OR-expression>
</ansic:inclusive-OR-expression>
</ansic:logical-AND-expression>
</ansic:logical-OR-expression>
</ansic:conditional-expression>
</ansic:assignment-expression>
</ansic:argument-expression-list>
</ansic:postfix-expression>
</ansic:unary-expression>
</ansic:cast-expression>
</ansic:multiplicative-expression>
</ansic:additive-expression>
</ansic:shift-expression>
</ansic:relational-expression>
</ansic:equality-expression>
</ansic:AND-expression>
</ansic:exclusive-OR-expression>
</ansic:inclusive-OR-expression>
</ansic:logical-AND-expression>
</ansic:logical-OR-expression>
</ansic:conditional-expression>
</ansic:assignment-expression>
</ansic:expression>
</ansic:expression-statement>
</ansic:statement>

<ansic:statement>
<ansic:jump-statement>
<ansic:RETURN/>
<ansic:expression>
<ansic:assignment-expression>
<ansic:conditional-expression>
<ansic:logical-OR-expression>
<ansic:logical-AND-expression>
<ansic:inclusive-OR-expression>
<ansic:exclusive-OR-expression>
<ansic:AND-expression>
<ansic:equality-expression>
<ansic:relational-expression>
<ansic:shift-expression>
<ansic:additive-expression>
<ansic:multiplicative-expression>
<ansic:cast-expression>
<ansic:unary-expression>
<ansic:postfix-expression>
<ansic:primary-expression>
<ansic:constant>0</ansic:constant>
</ansic:primary-expression>
</ansic:postfix-expression>
</ansic:unary-expression>
</ansic:cast-expression>
</ansic:multiplicative-expression>
</ansic:additive-expression>
</ansic:shift-expression>
</ansic:relational-expression>
</ansic:equality-expression>
</ansic:AND-expression>
</ansic:exclusive-OR-expression>
</ansic:inclusive-OR-expression>
</ansic:logical-AND-expression>
</ansic:logical-OR-expression>
</ansic:conditional-expression>
</ansic:assignment-expression>
</ansic:expression>
</ansic:jump-statement>
</ansic:statement>

</ansic:compound-statement>

</ansic:function-definition>
</ansic:external-declaration>

</ansic:translation-unit>

viper-2

unread,
Jul 16, 2008, 7:54:19 PM7/16/08
to
On Jul 16, 11:29 am, Rainer Joswig <jos...@lisp.de> wrote:
>
>
> Depends on the use case. Now you write:
>
> (|Albert Einstein| |Max Planck| |Marie Curie|)
>
> Instead of
>
> (Albert Einstein, Max Planck, Marie Curie)

Show a disposition towards balance, harmony, Yin-Yang - innate
features of a true hacker, I'd say!
;-)

--agt


jos...@corporate-world.lisp.de

unread,
Jul 16, 2008, 8:07:31 PM7/16/08
to
On 17 Jul., 00:46, "xah...@gmail.com" <xah...@gmail.com> wrote:
> Dear Rainer,
>
> You wrote: <<It's missing the core of the issue. code as data is not
>
> about syntax. ... Lisp dialects usually (the Scheme standard is an
> exception) see parsing of s-expressions as a dynamic feature of the
> reader. This is both good and bad. ... >>
>
> When a language, such as Lisp or Mathematica, that deals with symbols,
> the 2 formulation about "code⇔data" is equivalent, ok?

Don't know. I would agree that Mathematica (and a bunch of other
languages)
also support the 'code is data' idea.

<drivel>

> Also, you may or may not be aware, that people are making XML into a
> general purpose language. i.e. a language with XML as syntax. (e.g.

> O:XML (http://www.o-xml.org/), and to a lesser degree MathML and XML

Sure, I heard of XML. There are plenty attempts in XML to do that.

> About a tool that autoformat lisp code, you wrote: <<That's not just a
> problem of Common Lisp, that's a problem of Lisp in general. ...
> There is no fixed syntax and a fixed programmed scanner/parser for
> that syntax in Lisp (exception: as I mentioned Scheme has a fixed
> syntax, though Scheme implementations ... It's true for a certain
> class of comments. Mainly comments for ; and #| ... |#. You can
> program the reader to get those comments read, but I haven't seen this
> done for a long time. You need to use comments that are part of the s-
> expressions. Common Lisp allows documentation strings in certain
> places. ... >>
>
> So, you are implicitly admitting, one of my ciritism of lisp

> (http://xahlee.org/UnixResource_dir/writ/lisp_problems.html), that


> the irregularities of lisp syntax (e.g. "; ") is a problem?

What 'problem'? It sounds dramatic as only Lisp has such a 'problem'.
The 'problem' just is that the reader by default
is throwing away comments introduced by semicolon and #| |# and that
the
pretty-printer also does not know about those comments.
As Lisp systems are currently used this and automatic formatting of
textual
code is mostly not needed.

It's a design choice. Other features (like a programmable reader)
were more important than 'comments as data'. Most Lisp systems
ignore comments and don't read it. As I mentioned Common Lisp
has several places where comments and documentation can be
used in the source as data. Those will not be lost after
reading or pretty-printing code.

Still I would agree that it is interesting to have one and to get
more practical experience if it is useful or not.

As I said, either solve the problem by

a) ignore the comment problem (why not?) and just write a code
formatter.
Could be a start.

b) implement the fully general solution by modifying the reader
to also return comments and their position

c) implement a different lexical analysis tool within Emacs which
parses a version of Lisp syntax that is fixed and deals with
comments.
Probably not that easy, but possible.

Anyway, a real good code formatting tool is not that easy to write.

> Further, practically speaking, today there's no tool to autoformat
> lisp code as i described in my criticism (see the link above for
> detail ). This is a practical need.

Not for me. I'm usually fine with semi-automatic indenting or with a
real structure editor.

Anyway, I have a Lisp system which already has code formatting (minus
the
problem with comments). I wasn't using the formatter much.


It looks like this - a fucked up formatting of some function:


(defun test-function

(arg1 arg2

arg3

argument-with-longer-name)

"this function is just a test"

(setf argument-with-longer-name (* arg1 ; use this
first

arg2 (sin arg3)))
(* argument-with-longer-name argument-with-longer-name argument-with-
longer-name argument-with-lo\
nger-name))


Now the command 'M-x format code' and 'M-x lowercase in region'
produces the following formatting:


(defun test-function (arg1 arg2 arg3 argument-with-longer-name)
"this function is just a test"
(setf argument-with-longer-name (* arg1 arg2 (sin arg3)))
(* argument-with-longer-name
argument-with-longer-name
argument-with-longer-name
argument-with-longer-name))


You can see that the 'comment as data' documentation string still is
there,
but the semicolon comment has been lost.


<your drivel deleted>

Peter Keller

unread,
Jul 16, 2008, 8:13:47 PM7/16/08
to
In comp.lang.scheme xah...@gmail.com <xah...@gmail.com> wrote:
[snip]

Really, does it matter?

LISP is just another Turing complete language like any other where some
semantic idioms are nice to express and others difficult. I hear some
people like it and other people don't. What's the difference? Every single
language is like that. Every. Single. One.

If you seriously are upset about what you think are deficiencies in
the language, the world would be better serviced by you writing code,
or contributing to a compiler, or making an IDE, or writing papers to
prove why your way is better than the current way, or any other number of
things except writing volumes of crap that from my point of view mostly
exists to cause strife in the newsgroups.

I'm not avoinding your criticisms either. I'm saying that you aren't
doing anything about your criticisms other than kicking up dust so
others can't see. And that seems to be a waste of time....

-pete

Benjamin Teuber

unread,
Jul 17, 2008, 9:09:46 PM7/17/08
to
Hi everybody,

I've been spending some time thinking about this code formatting
issue. Although the task of writing a good formatter is quite
demanding by itself, I think the real problem is whether or not we are
willing to drop macros with "special formatting" in order to get a
canonical format. E.g., you might want to have different indentation
levels for the parameter list and the body of a function, as

(defun myfun
(long-parameter-list-argument-1 ..)
("heureka"))

looks quite weird. Or maybe you like

(if x
"true"
"false")

which at least one editor I tried gives.
But if this special indentation rules are important, there should be
some way to give a hint when defining a macro about how to indent it
correctly, as a user-macro should have the same rights as defmacro =)
At least this is what I would do if I had to reinvent Lisp from
scratch - which in fact I might be doing ;-)

Regards,
Benjamin

Joost Diepenmaat

unread,
Jul 17, 2008, 9:23:31 PM7/17/08
to
Benjamin Teuber <bet...@web.de> writes:

> Hi everybody,

[ ... ]

> But if this special indentation rules are important, there should be
> some way to give a hint when defining a macro about how to indent it
> correctly, as a user-macro should have the same rights as defmacro =)
> At least this is what I would do if I had to reinvent Lisp from
> scratch - which in fact I might be doing ;-)

Isn't that why &body is for?

Also: why did you not start a new thread for this?

--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/

Pascal J. Bourguignon

unread,
Jul 18, 2008, 1:32:44 AM7/18/08
to
Benjamin Teuber <bet...@web.de> writes:

> Hi everybody,
>
> I've been spending some time thinking about this code formatting
> issue. Although the task of writing a good formatter is quite
> demanding by itself, I think the real problem is whether or not we are
> willing to drop macros with "special formatting" in order to get a
> canonical format. E.g., you might want to have different indentation
> levels for the parameter list and the body of a function, as
>
> (defun myfun
> (long-parameter-list-argument-1 ..)
> ("heureka"))
>
> looks quite weird.

Yes.

emacs indents it like this both in emacs-lisp-mode and in common-lisp-mode:

(defun myfun
(long-parameter-list-argument-1 ..)
("heureka"))

> Or maybe you like


>
> (if x
> "true"
> "false")
>
> which at least one editor I tried gives.

Because it is not indenting Common Lisp code, but some older lisp,
like emacs lisp.

(if test
(single form evaluated when test is true)
(in emacs lisp)
(we can have)
(several forms with)
(an implicit progn)
(in the else branch))


> But if this special indentation rules are important, there should be
> some way to give a hint when defining a macro about how to indent it
> correctly, as a user-macro should have the same rights as defmacro =)
> At least this is what I would do if I had to reinvent Lisp from
> scratch - which in fact I might be doing ;-)

Have fun!


--
__Pascal Bourguignon__ http://www.informatimago.com/

Nobody can fix the economy. Nobody can be trusted with their finger
on the button. Nobody's perfect. VOTE FOR NOBODY.

Kenny

unread,
Jul 18, 2008, 2:13:16 AM7/18/08
to
> Benjamin Teuber <bet...@web.de> writes:
>
>> Hi everybody,

That's just the kind of attitude we do not need around here.

>> At least this is what I would do if I had to reinvent Lisp from
>> scratch - which in fact I might be doing ;-)

Well that certainly sets you off from all the other people who discover
Lisp on day zero and on day one decide to write their own. So they can
be programming in C all day.

The one thing you know about someone who reacts to being handed a
Formula I race car by heading to the machine shop to make a wheel is
that they have no interest in driving.

WTF am I still doing in this walking dead NG???

:)

kt

Benjamin Teuber

unread,
Jul 18, 2008, 5:14:24 AM7/18/08
to
On 18 Jul., 03:23, Joost Diepenmaat <jo...@zeekat.nl> wrote:

> Isn't that why &body is for?

Right, but I'm not sure whether this is enough - maybe there happens
to be a macro with two bodies or some other reason for different
indentation. Question to the experienced guys: Did you ever stumble
across a macro where &body alone wasn't enough to specify a good
indentation?

> Also: why did you not start a new thread for this?

Well, because it's a discussion of the one point I more or less liked
about Xah's post - but if you prefer, we can move to another thread.

Benjamin Teuber

unread,
Jul 18, 2008, 5:15:32 AM7/18/08
to
On 18 Jul., 07:32, p...@informatimago.com (Pascal J. Bourguignon)
wrote:

> Benjamin Teuber <bet...@web.de> writes:
> > Or maybe you like
>
> > (if x
> >     "true"
> >   "false")
>
> > which at least one editor I tried gives.
>
> Because it is not indenting Common Lisp code, but some older lisp,
> like emacs lisp.

Thanks for clarifying that.

Benjamin Teuber

unread,
Jul 18, 2008, 5:16:20 AM7/18/08
to
On 18 Jul., 08:13, Kenny <kentil...@gmail.com> wrote:
> > Benjamin Teuber <bet...@web.de> writes:
>
> >> Hi everybody,
>
> That's just the kind of attitude we do not need around here.

Like ... greeting?


>
> >> At least this is what I would do if I had to reinvent Lisp from
> >> scratch - which in fact I might be doing ;-)
>
> Well that certainly sets you off from all the other people who discover
> Lisp on day zero and on day one decide to write their own. So they can
> be programming in C all day.

I feel honored at least not be put put into the very worst category =)

> The one thing you know about someone who reacts to being handed a
> Formula I race car by heading to the machine shop to make a wheel is
> that they have no interest in driving.

Well, "reinvent from scratch" was an exeggeration - my plan would
rather be building a tuning kit people can use to make their say
japanese car behave more like a race car. But nevermind, I should not
start the spamming before having something in my hands, so I'd better
shut up now..

Pascal J. Bourguignon

unread,
Jul 18, 2008, 5:49:18 AM7/18/08
to
Benjamin Teuber <bet...@web.de> writes:

> On 18 Jul., 03:23, Joost Diepenmaat <jo...@zeekat.nl> wrote:
>
>> Isn't that why &body is for?
>
> Right, but I'm not sure whether this is enough - maybe there happens
> to be a macro with two bodies or some other reason for different
> indentation. Question to the experienced guys: Did you ever stumble
> across a macro where &body alone wasn't enough to specify a good
> indentation?

Of course, it happens.

That's where the lisp-indent-function property of emacs symbols comes
into play. See C-h f lisp-indent-function RET

(defun mymacro (a b c d e f &body g) ...)

#+emacs (put 'mymacro 'lisp-indent-function '3)

(mymacro a b
c
d e
f
g)


>> Also: why did you not start a new thread for this?
>
> Well, because it's a discussion of the one point I more or less liked
> about Xah's post - but if you prefer, we can move to another thread.

It would be better yes. A lot of people killfile Xah.

--
__Pascal Bourguignon__

Kent M Pitman

unread,
Jul 18, 2008, 12:23:31 PM7/18/08
to
Benjamin Teuber <bet...@web.de> writes:

> On 18 Jul., 03:23, Joost Diepenmaat <jo...@zeekat.nl> wrote:
>
> > Isn't that why &body is for?
>
> Right, but I'm not sure whether this is enough - maybe there happens
> to be a macro with two bodies or some other reason for different
> indentation. Question to the experienced guys: Did you ever stumble
> across a macro where &body alone wasn't enough to specify a good
> indentation?

It's extremely rare and usually not an issue, not because it can't be
wanted but because Lisp syntax doesn't really allow for it.

The problem comes that if you wanted multiple bodies, there would be
no obvious cue about how to divide them. So usually what you do is
like what COND does where you do:

(defmacro my-cond (&body clauses)
...
(dolist (clause clauses)
... (destructuring-bind (test &body forms) clause ...) ...)
...)

Or else you just take one as a form and make the user use progn, as in:

(defmacro my-multiple-value-bind (bindings value-form &body forms) ...)

where in practice one often occasionally wishes for

(defmacro my-multiple-value-bind (bindings &body value-forms
&more-body other-forms)
...)

The fact is that &body is not the source of any problem, it just reminds you
that there are inherent limitations with positionally supplied semantics.
That problem is a problem of the universe, not even of Lisp. e.g., it comes
up with regular expressions, for example, when you try to juxtapose to *
wildcards and either combinatoric answers come up or the string doesn't
compile, depending on the tool. It's also the reason that if you're wanting
something scanf-like, as in (setf (format nil "~D" x) "3"), you can't
allow cases like (setf (format nil "~D~D" x y) "357") to set multiple values
because you can't know what the partitioning is. &body is just another case
of this broad class of issues.



Jon Harrop

unread,
Jul 18, 2008, 4:34:00 PM7/18/08
to
Peter Keller wrote:
> In comp.lang.scheme xah...@gmail.com <xah...@gmail.com> wrote:
> [snip]
>
> Really, does it matter?
>
> LISP is just another Turing complete language like any other where some
> semantic idioms are nice to express and others difficult. I hear some
> people like it and other people don't. What's the difference? Every single
> language is like that. Every. Single. One.

The difference is productivity. Modern software obviously benefits
enormously from the use of recently adopted technologies like garbage
collection and closures. If you want to compete, you must understand what
the options are and what trade-offs they make.

> If you seriously are upset about what you think are deficiencies in
> the language, the world would be better serviced by you writing code,
> or contributing to a compiler, or making an IDE, or writing papers to
> prove why your way is better than the current way, or any other number of
> things except writing volumes of crap that from my point of view mostly
> exists to cause strife in the newsgroups.

If you want to design and implement a new language then you should survey
what already exists and study the trade-offs exhaustively.

--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u

Tobias C. Rittweiler

unread,
Jul 19, 2008, 7:44:25 AM7/19/08
to
Kent M Pitman <pit...@nhplace.com> writes:

> Benjamin Teuber <bet...@web.de> writes:
>
> > Right, but I'm not sure whether this is enough - maybe there happens
> > to be a macro with two bodies or some other reason for different
> > indentation. Question to the experienced guys: Did you ever stumble
> > across a macro where &body alone wasn't enough to specify a good
> > indentation?
>
> It's extremely rare and usually not an issue, not because it can't be
> wanted but because Lisp syntax doesn't really allow for it.

I sometimes wish for an equivalent to &BODY for functions:

(defun call-with-foo (context &thunk fn)
...)
Such that

(call-with-foo (current-context)
#'(lambda (foo) ...))

instead of

(call-with-foo (current-context)
#'(lambda (foo) ...))

-T.

Kent M Pitman

unread,
Jul 19, 2008, 11:04:38 AM7/19/08
to
"Tobias C. Rittweiler" <t...@freebits.de> writes:

> I sometimes wish for an equivalent to &BODY for functions:
>
> (defun call-with-foo (context &thunk fn)
> ...)
> Such that
>
> (call-with-foo (current-context)
> #'(lambda (foo) ...))
>
> instead of
>
> (call-with-foo (current-context)
> #'(lambda (foo) ...))

Heh. This is nature's way of telling you that you wanted to write a
WITH-FOO macro that has &BODY. :)

In fact, although I don't think you'd find any historical record
showing this to be true in fact, I think the reason you see &body in
macros but not functions is that this particular situation is in fact
the most common and is amenable to macros. The only other case where
I have ever wanted it was in a long list of keywords, as with certain
calls to OPEN or many of the functions in CLIM.

There's also a practical matter that there are usually other ways
involving variables that long function calls can be phrased differently
so that some of those issues can be rearranged.

And, finally, I think the real flaw here is not in CL but in the community
not having a way of declaring indentation portably. This is an easily
layerable thing, and the real thing is not that CL was trying to add the
only way to do it in DEFMACRO, but rather CL was saying "we can't tell you
how this is done on a per-implementation basis, but it's possible to sneak
in for macros so we'll hide it on a limited basis." With functions the
issues are more complicated, not just because of APPLY, but also because
functions can come and go dynamically at runtime.

In that regard, this is a little like the LispM's &quote, which was like
a fexpr and is happily gone. The idea is appealing at some level.
((LAMBDA (&QUOTE X) X) A) => A
but the problem is that this is really a property of the name of the function,
not of the value of the function. So when the value is picked up and moved
to other names or used with APPLY, the question is whether those dynamic uses
must recognize the usage. (APPLY #'(LAMBDA (&QUOTE X) X) '(A)) => A
which is a little bizarre since so (APPLY #'(LAMBDA (X) X) '(A)) => A
and it shows the &QUOTE is really riding around in the wrong place.
I think the same would be true of &body. What would (apply #'call-with-foo ..)
do with the information? I'm not saying these things don't have answers,
only that the answers are not as neat and pretty as the answers were with
the macro case.

And, finally, I have not looked at this stuff recently but I'm fairly sure
I was actually the one who first put data-driven body-style indentation
into TECO-based Emacs years ago. Before that, I think the indentation style
was generally the old-style MACLISP indent-under-arg-1 thing, possibly with
just a few special cases. I remember it bugged me a lot and I did some major
overhaul on it anyway. And while it made it possible to do this on functions
as well as definitions, the critical point was that you were supposed to
globally declare your intent, which you usually did in a Local Modes at the
end of a file full of code (for Emacs). e.g., one might write:

; -*- Mode: LISP; -*-
(defun blah ()
(foo
x))
^L
; Local Modes:
; Lisp FOO Indent: -1
; End:

I tried this just now on an ITS emulator and I'm amazed I still
mremembered how to write this syntax first try after
that many years... It's weird what the brain keeps around. The documentation
on the mode stuff is in the file EMACS1;INDENT > for anyone with such an
emulator wanting to look. I was looking at version 238, which offered this
doc:

!^R Indent for LISP:! !^R Indent this line for a Lisp-like language.
With arg, moves over and indents that many lines.
The variable Lisp Indent Language (default "Lisp") controls the dialect.
Handlers may be defined per-dialect to make this function win for other
Lisp-like languages. With a pre-comma arg, return indentation level instead
of changing anything and don't treat ;;; comments specially.!

!* Indentation is first computed by a long-standing indentation algorithm.
Relevant variables:
Lisp Indent Offset (default 0), if nonzero indent this many columns
past the most recent hanging "(" rather than worrying about indentation
relative to arguments.
Lisp Indentation Hook (default m.m& Standard Lisp Indentation Hook$) is
macroed to get extra refinement. The default has hairy options as
described below. It can return two values.
The second one, if nonzero, is the hpos to indent to.
If it is zero, the indentation of point (as point is left
by the hook) is used.
The first value, if nonzero, means that succeeding sexps
at the same level of nesting will not necessarily be
indented the same way. The value should be the char address
of the ( which starts the containing form.
According to the default behavior:
If a variable name Lisp ... Indent (where the ... is replaced by
the name of the operator at the head of the list -- eg, CAR looks
for Lisp CAR Indent exists, it will be interpreted as follows:
if a string, then macro it.
if a number, then
if -4 or less, undefined.
if -3, don't indent specially unless Lisp Indent DEFanything says to
if -2, don't indent specially.
if -1, indent as a defform.
if 0 or pos, indent as a specform.
If Lisp Indent DEFanything (default 1) if nonzero says that any operator
name beginning with DEF should be treated as a defform.
The amount of indentation used by the variables is special indentation
values -1 and up is given by Lisp Special Indent Offset (default 2)
and is an offset from the open paren of the enclosing form!

e.g., for a PROG (replacing control characters with printables), there was
actually a macro handler living in the q-register named q$Lisp PROG Indent$,
because it was too complicated to do this by a simple integer variable value:

!& Alternate Lisp PROG Hook:! !& Hook indents PROGs with tags left justified!

Z-qZj 0l @f^B_^]^Q $l !* Jump to head of line being indented !
0,1a*5+1:g..D-^^A"e ^X+1j ' !* Indent tags one way !
"# ^X+5j @f^B_^]^Q $l !* Else indent to normal place !
0,1af^B^M;$:"l ^X+1j'' !* being careful of bvl not on line 1 !
^X,0^\

Ah, TECO. Why ever did we leave you behind? *sniffle*

On the LispM, there was a more general mechanism that had a list of,
if I recall correctly, expression position and indent points, so that you
could tell multiple-value-bind that its value expression was to indent 4
and then its body only 2, so it permitted multiple indent points:
(multiple-value-bind (foo bar)
(returns-two-values)
(user-of foo bar))
But to get this right you were out of scope of anything &body could have
done [unless you had special rules for indentation of pre-&body expressions].

Probably modern packages have ways to customize this that are similar.
Heh, looking at my own emacs init, I see things like:
(put 'block 'lisp-indent-hook 1)
which look like transliterations of the teco

So, back to your original point, I agree with you there's a gap there,
and the gap may even have a subconscious political bent to it. But in
practice I think the main issue is that once you're outside of the
simple issue &body in defmacro solves, the number of subtleties is
sparse and distributed in multiple directions. Trying to patch it by
just extending the feeble &body hack to functions really misses the
big picture that there are a lot of issues in indentation, just as
with any typography, and getting them right involves a full-fledged
declarational facility.

Vassil Nikolov

unread,
Jul 19, 2008, 11:26:30 AM7/19/08
to

On Sat, 19 Jul 2008 13:44:25 +0200, "Tobias C. Rittweiler" <t...@freebits.de> said:

| ...


| I sometimes wish for an equivalent to &BODY for functions:

| (defun call-with-foo (context &thunk fn)
| ...)
| Such that

| (call-with-foo (current-context)
| #'(lambda (foo) ...))

| instead of

| (call-with-foo (current-context)
| #'(lambda (foo) ...))

In my opinion, the reason why there is relatively little demand for
this in Common Lisp (and hence why such a facility isn't (widely)
used) is that in most of the cases of this kind, one would use
macros, rather than higher-order programming. Again, this is just a
thesis; it would be interesting to hear the opposite point made.

Tobias C. Rittweiler

unread,
Jul 19, 2008, 11:39:44 AM7/19/08
to
Kent M Pitman <pit...@nhplace.com> writes:

> On the LispM, there was a more general mechanism that had a list of,

> if I recall correctly, expression position and indent points, ...

I'd like to take the opportunity to point to my editor-hints project at
http://common-lisp.net/project/editor-hints/, as such an indentation
declaration facility is one of its goals. Among many other things. See
the TODO file referenced on that page. I'll continue working on it
during upcomming breaks.

And thanks for your posting. I especially enjoyed the original TECO
snippet! :-)

-T.

Tobias C. Rittweiler

unread,
Jul 19, 2008, 11:59:04 AM7/19/08
to
Vassil Nikolov <vnikolo...@pobox.com> writes:

> On Sat, 19 Jul 2008 13:44:25 +0200, "Tobias C. Rittweiler" said:
>
> | ...
> | I sometimes wish for an equivalent to &BODY for functions:
> |
> | (defun call-with-foo (context &thunk fn)
> | ...)
> | Such that
> |
> | (call-with-foo (current-context)
> | #'(lambda (foo) ...))
> |
> | instead of
> |
> | (call-with-foo (current-context)
> | #'(lambda (foo) ...))
>
> In my opinion, the reason why there is relatively little demand for
> this in Common Lisp (and hence why such a facility isn't (widely)
> used) is that in most of the cases of this kind, one would use
> macros, rather than higher-order programming. Again, this is just a
> thesis; it would be interesting to hear the opposite point made.

CALL-WITH-FOO is nice if the continuation is a named function:

(call-with-foo (current-context) #'frob-foo)

vs.

(with-foo foo (current-context)
(frob-foo foo))


Now as names get longer, I'd prefer

(call-with-zurped-foobar (get-zurped-context)
#'frobnicate-a-zurped-foobar)

to

(call-with-zurped-foobar (get-zurped-context)
#'frobnicate-a-zurped-foobar)

Or

(call-with-zurped-foobar (get-zurped-context)
(make-foobar-frobnicator :zurp t))


There are other times where I'd have like an indentation like above,
for instance:

(frob-quux (some-context)
(make-some-data-structure :foo-slot (compute-foo)
:bar-slot (compute-bar)))


As a real-world example take

(defun maybecall (bool fn &rest args)
"Call FN with ARGS if BOOL is T. Otherwise return ARGS as multiple values."
(if bool (apply fn args) (values-list args)))

I'd like it be indented like

(maybecall (tasty-p food)
#'grab-and-eat food :smacking nil)


It doesn't come up all that often, of course. HTH,

-T.

Tobias C. Rittweiler

unread,
Jul 19, 2008, 12:04:31 PM7/19/08
to
"Tobias C. Rittweiler" <t...@freebits.de.invalid> writes:

> As a real-world example take
>
> (defun maybecall (bool fn &rest args)
> "Call FN with ARGS if BOOL is T. Otherwise return ARGS as multiple values."
> (if bool (apply fn args) (values-list args)))
>
> I'd like it be indented like
>
> (maybecall (tasty-p food)
> #'grab-and-eat food :smacking nil)

Stupid example, as you'd use WHEN here anyway. MAYBECALL can be useful
because it behaves like identity if the condition is not true, making it
practical for normalization of arguments.

-T.

Pascal J. Bourguignon

unread,
Jul 19, 2008, 12:44:54 PM7/19/08
to
"Tobias C. Rittweiler" <t...@freebits.de> writes:

#+emacs
(put 'call-with-foo 'lisp-indent-function 1)

and then it will indent it as:

(call-with-foo (current-context)
#'(lambda (foo) ...))


There are two practical ways to do that automatically:

1- use emacs local variables. Put at the end of the source:

;;; Local Variables:
;;; eval: (put 'call-with-foo 'lisp-indent-function 1)
;;; End:

so when you open this file, emacs will evaluate the expression, and
will know how to indent your operators.

However, recent versions of emacs thankfully ask you whether the
expression is safe to evaluate. This is nice to avoid viruses (if
only Microsoft could take a hint), but this is irritating having to
answer to a set of questions when loading a file. Also, the same
operator may appear in various files so this may lead to code
duplication and maintenance headache. Therefore:


2- nowadays, what I do, is to put these instructions in separate
lisp.indentations files, spread at various levels of my source
directory hierarchy, and I have an emacs command to load them with
M-x load-lisp-indentations RET


(require 'cl) ; of course

(defun cl-indent (symbol num-forms)
"
Put on the SYMBOL and its lower case and upper case variants
a 'lisp-indent-function property set to NUM-FORMS.
"
(dolist (property '(lisp-indent-function common-lisp-indent-function))
(put symbol property num-forms)
(put (intern (string-downcase (symbol-name symbol))) property num-forms)
(put (intern (string-upcase (symbol-name symbol))) property num-forms)))

(defun* read* (stream &optional (eof-error-p t) eof-value ignored)
(handler-case (read stream)
(end-of-file (err) (if eof-error-p
(error err)
eof-value))))


(defun %batch-cl-indent (&rest indent-symbols-list)
(dolist (item indent-symbols-list)
(let ((indent (car item)))
(dolist (sym (cdr item))
(cl-indent sym indent)
(let ((p (position (character ":") (symbol-name sym))))
(when p
(cl-indent (intern (subseq (symbol-name sym) (1+ p)))
indent)))))))

(defmacro* do-directories-up ((var dir-path &optional result) &body body)
"
DO: Evaluates body with var bound to dir-path, then dir-path's parent,
and so on up to the root directory.
RETURN: The evaluation of the result form.
"
`(do ((,var ,dir-path
(if (string-match "^\\(.*/\\)[^/]+/$" ,var)
(match-string 1 ,var)
"")))
((string-equal "" ,var) ,result)
,@body))


(defun load-lisp-indentations ()
"Processes a lisp.indentations file,
in the current directory, or in a parent."
(interactive)
(do-directories-up (dir default-directory)
(let ((file (concat dir "lisp.indentations")))
;; (message "file = %S" file)
(when (file-exists-p file)
(save-excursion
(let ((count (length (buffer-list)))) ; is there a better way?
(find-file file)
(goto-char (point-min))
(let ((killp (/= count (length (buffer-list)))))
(unwind-protect
(loop
for clause = (read* (current-buffer) nil (current-buffer))
until (eql clause (current-buffer))
do (message "(%%batch-cl-indent '%S)" clause)
do (%batch-cl-indent clause))
(when killp (kill-buffer (current-buffer)))))))))))

Here is an extract of my ~/lisp.indentations file:


;;-------------
;; COMMON-LISP
;;-------------

(defun lambda macrolet)
(((&whole 4 &rest (&whole 1 &lambda &body)) &body)
flet labels)
(((&whole 6 1 1 1 1 1 1) (&whole 4 1 1 1 1 1 1) &body)
destructuring-bind)
(0 progn)
;; (put 'progn 'lisp-indent-function 0), say, causes progn to be indented
;; like defun if the first form is placed on the next line, otherwise
;; it is indented like any other form (i.e. forms line up under first).
(1 block case catch ccase concatenate
do-all-symbols do-external-symbols do-symbols
dolist dotimes ecase eval-when
format
handler-case
if let let*
logical-pathname-translations make-instance