Re: The Fundamental Confusion of Xah

On 17 Jul., 00:46, "xah...@[EMAIL PROTECTED]
" <xah...@[EMAIL PROTECTED]
> 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$B"N(Bdata" is equivalent, ok?

Don't know. I would agree that Mathematica (and a bunch of other
languages)
also sup****t 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
> transformation language
(http://en.wikipedia.org/wiki/XML_transformation_language
> ))

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 do***entation 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 im****tant 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 do***entation 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 ****ed 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' do***entation string still is
there,
but the semicolon comment has been lost.


<your drivel deleted>