Re: About Emacs Modernisation Project

[Xah Lee]

On May 31, 4:31 pm, p...@informatimago.com (Pascal J. Bourguignon)
wrote:
> Alessandro Piras <lay...@gmail.com> writes:
> > LanX <lanx.p...@googlemail.com> writes:
>
> >> Hi
>
> >> I doubt that Python would be a good choice, Perl for instance has much
> >> more in common with LISP.
>
> >> And I doubt that eLISP is the reason why many people have problems
> >> with emacs, it's more that many "modern" GUI mechanisms and
> >> terminologies are not default in emacs, which frustrates newbies.
>
> >> IMHO an alternative (but compatible ) eLISP-dialect simply allowing to
> >> swap parens and functionnames and to write "message(...)" instead of
> >> "(message...)" would increase the acceptance immidiately.
>
> > Sounds Like M-expressions. It has been tried in the past in the Lisp world,
> > without much success. Most programmers realize after few time the
> > sweetness of S-expressions and macros. I think it would just lead to a
> > small amount of M-expressions code that would be soon refactored as
> > S-expressions.. Not worth the effort I suspect.
>
> This is important to understand.
>
> Asking to write   function(argument)  in lisp, is like asking to write:
>
>    int a[]=1{2,3,4};
>
> in C.
>
> Yes, 1{2,3,4}  instead of {1,2,3,4} is totally silly in C.  Why would
> you want to put the first element of a list of values outside of the
> list?
>
> It just happen that code is data and there is no more any point in
> putting the first element of a function application outside of the
> list.
>
> f(a,b,c) goes in most languages, because they make an artificial
> distinction between code and data, and the implication of this is that
> they need big parsers, and cannot mix compilation time with run time.
>
> But in lisp, since we write (f a b c) like we write (1 2 3 4), the
> parser becomes trivial, and the code can be processed as easily as any
> other data, therefore we can write macros (which are compiler hooks)
> and use the compiler at run-time.
>
> This feature is called "homoiconicity".

The above opinion is biased and basically bullshit.

The throwing in of the jargon homoiconicity is just to a sales pitch.

if you read Wikipedia:
http://en.wikipedia.org/wiki/Homoiconicity

you see this paragraph:

---------------
Languages which are considered to be homoiconic include members of the
Lisp family, Nemerle, Curl, REBOL, SNOBOL, XSLT, XQuery, TRAC, Tcl,
Io, Ioke, Joy, Factor, Pico, PostScript, Prolog, R, Mathematica, V
and Clojure.[citation needed]

In Von Neumann architecture systems (including the vast majority of
general purpose computers today), raw machine code also has this
property, the data type being bytes in memory.
----------------

So, this “homoiconicity” has little to do with lisp's syntax or
whatever it is supposed to be relevant.

also, note that XML also has lisp's advantage of regular syntax, and
there are computing langs based on xml syntax today. Note that lisp
syntax is not strictly regular. For a more regular syntax, there's XML
and Mathematica.

also, the oft quoted concept of “code is data” is seldom ever defined.
When asked a lisp, each has different take. Basically, it means
nothing more than a strictly uniform and regular syntax, which lisp's
isn't the better example among languages.

another thing lisp lovers inevitable love to cite is macros. Note
that, a whole class of languages that are based on pattern matching,
is a order of magnitude more powerful than classic lisps.

For detail, see:

• Fundamental Problems of Lisp
  http://xahlee.org/UnixResource_dir/writ/lisp_problems.html

  Xah
∑ http://xahlee.org/

☄