The Fundamental Confusion of Xah - comp.lang.lisp

The old Google Groups will be going away soon, but your browser is incompatible with the new version.

« Groups Home

comp.lang.lisp

Discussions

+ new post

About this group

Subscribe to this group

This is a Usenet group - learn more

Message from discussion The Fundamental Confusion of Xah

joswig@corporate-world.li sp.de

View profile

More options Jul 16 2008, 7:43 am

Newsgroups: comp.lang.lisp

From: "jos...@corporate-world.lisp.de" <jos...@corporate-world.lisp.de>

Date: Wed, 16 Jul 2008 04:43:03 -0700 (PDT)

Local: Wed, Jul 16 2008 7:43 am

Subject: Re: The Fundamental Confusion of Xah

Print | View thread | Show original | Report this message | Find messages by this author

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.

Account Options