Fundamental Problems of Lisp

xahlee@gmail.com wrote:

> btw, i have a question... are those AST created in the parsing process
> as some kinda explicit datatype? Wouldn't it be easy to print them out
> like lisp's nested paren?
>
> it is my wild guess, that the idea all or almost all languages will
> have a nested syntax like lisp (as a layer), might actually be a
> reality say in maybe 20 or 50 years.

GCC has a Lisp-like internal language when compiling code, see this page
for details:

http://gcc.gnu.org/onlinedocs/gccint/RTL.html

--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

On 25 ago, 17:58, "xah...@gmail.com" <xah...@gmail.com> wrote:
> With the profileration of tools today... i probably can hackup a
> interpreter for some new language in say, perl.

Funny you enjoy bashing perl and Larry so much and still want to rely
on it.

> as for language's syntax, i do not find nested syntax ideal...i find the nested
> syntax problematic...i've been thinking, a ideal syntax that completely ditchs any
> form of nesting in syntax...

You put too much worth on syntax. From the wonderful
"Programming Languages: Application and Interpretation", by Shriram
Krishnamurthi:

----
The first insignificant attribute is the syntax. Syntaxes are highly
sensitive topics,1 but in the end, they
don’t tell us very much about a program’s behavior. For instance,
consider the following four fragments:
1. a [25]
2. (vector-ref a 25)
3. a [25]
4. a [25]
Which two are most alike? The first and second, obviously! Why?
Because the first is in Java and the
second is in Scheme, both of which signal an error if the vector
associated with a has fewer than 25 entries;
the third, in C, blithely ignores the vector’s size, leading to
unspecified behavior, even though its syntax is
exactly the same as that of the Java code. The fourth, in ML or
Haskell, is an application of a to the list
containing just one element, 25: that is, it’s not an array
dereference at all, it’s a function appliction!
----

It's an online book. You could give it a try.

> as for interests, i have much more interest in perfecting my expertise
> in elisp, and learning Haskell, and learning a theorem proving lang
> such as coq to enhance my understanding in mathematical logic.

Good. I've noticed you dropped all the gratuitous insulting in
current posts. I hope that manic phase is gone for good, because
otherwise you do provide some joyful reading.

My god, that AST stuff comes eerily close to the translation program
I'm dabbling on.

First note that I'm only using it to learn and don't think it will
actually work well.

But basically you would parse some code, eg. C, into a descriptive XML
or other data
(I just happen to be using CL-parse able s-expressions by
coincidence!)

Then for the language you are translating to, find the equivalent s-
expression tree.
Substitute in the variables into the equivalent s-expression tree.
Use a language-specific printer function to print the new s-
expressions as source code.

This would hopefully imitate a human manually porting code from one
language to another, which isn't a bad "best-case" scenario.
The unfortunate part is that it would be very hard to automatically
find equivalent code where language features are not present, eg. C
pointers.

Still, I might learn something in the process, however pointless the
exercise.


> No. My knowledge and experience of parsers and compilers is basically zero.

I've designed two languages, one was a lisp, the other wasn't. You
don't need a computer to create a language either, mine was all done
on a *lot* of paper.

Maybe you can even find logical reasoning which would facilitate quote
chars ' and line comments ; in your language, but you don't have to.

Doing this could change your mind on some things.
For instance, I'm not naturally inclined toward programming in
multiple name spaces for functions and variables.
However I can now see that there can be good reasoning for them, and
am all the more tolerant of them for it.

> Even that will take me perhaps half a year or more

No no, that's the beauty of lisp's simplicity, it will take you two
weeks max. to get a basic lisp running in your favourite language.

> and when done it'd be basically a useless toy.

Can't argue with you on that one!
If you can write a good FFI for it and don't mind running code through
it slowly, you could still use it for small things though.

On Mon, 25 Aug 2008 14:31:43 -0700 (PDT), namekuseijin
<namekuseijin@gmail.com> wrote:

>[...]
>
>You put too much worth on syntax. From the wonderful
>"Programming Languages: Application and Interpretation", by Shriram
>Krishnamurthi:
>
>----
>The first insignificant attribute is the syntax. Syntaxes are highly
>sensitive topics,1 but in the end, they
>don$B!G(Bt tell us very much about a program$B!G(Bs behavior. For instance,
>consider the following four fragments:
>1. a [25]
>2. (vector-ref a 25)
>3. a [25]
>4. a [25]
>Which two are most alike? The first and second, obviously! Why?
>Because the first is in Java and the
>second is in Scheme, both of which signal an error if the vector
>associated with a has fewer than 25 entries;
>the third, in C, blithely ignores the vector$B!G(Bs size, leading to
>unspecified behavior, even though its syntax is
>exactly the same as that of the Java code. The fourth, in ML or
>Haskell, is an application of a to the list
>containing just one element, 25: that is, it$B!G(Bs not an array
>dereference at all, it$B!G(Bs a function appliction!
>----
>
>It's an online book. You could give it a try.

FYI, here's the URL:

http://www.cs.brown.edu/~sk/Publicat...gs/2007-04-26/

The above-mentioned quotation is on page 3.

Just to be fair, the number 1 (superscript in the original text) after
the above-mentioned "Syntaxes are highly sensitive topics" part does
refer to the following footnote:

[1] Matthias Felleisen: "Syntax is the Viet Nam of programming
languages."

This may imply that this newsgroup is the Viet Nam of programming
language communities. ;-)

-- Benjamin L. Russell

On Aug 26, 4:29 am, Benjamin L. Russell <DekuDekup...@Yahoo.com>
wrote:
> On Mon, 25 Aug 2008 14:31:43 -0700 (PDT), namekuseijin
>
>
>
> <namekusei...@gmail.com> wrote:
> >[...]
>
> >You put too much worth on syntax. From the wonderful
> >"Programming Languages: Application and Interpretation", by Shriram
> >Krishnamurthi:
>
> >----
> >The first insignificant attribute is the syntax. Syntaxes are highly
> >sensitive topics,1 but in the end, they
> >don’t tell us very much about a program’s behavior. For instance,
> >consider the following four fragments:
> >1. a [25]
> >2. (vector-ref a 25)
> >3. a [25]
> >4. a [25]
> >Which two are most alike? The first and second, obviously! Why?
> >Because the first is in Java and the
> >second is in Scheme, both of which signal an error if the vector
> >associated with a has fewer than 25 entries;
> >the third, in C, blithely ignores the vector’s size, leading to
> >unspecified behavior, even though its syntax is
> >exactly the same as that of the Java code. The fourth, in ML or
> >Haskell, is an application of a to the list
> >containing just one element, 25: that is, it’s not an array
> >dereference at all, it’s a function appliction!
> >----
>
> >It's an online book. You could give it a try.
>
> FYI, here's the URL:
>
> http://www.cs.brown.edu/~sk/Publicat...gs/2007-04-26/
>
> The above-mentioned quotation is on page 3.
>
> Just to be fair, the number 1 (superscript in the original text) after
> the above-mentioned "Syntaxes are highly sensitive topics" part does
> refer to the following footnote:
>
> [1] Matthias Felleisen: "Syntax is the Viet Nam of programming
> languages."
>
> This may imply that this newsgroup is the Viet Nam of programming
> language communities. ;-)

Does that make the CL programmers the Vietcong? (... or the
French?!?)

In any case, I can only quote Kurtz on many of these threads: the
horror, the horror.

Cheers
--
Marco

2008-08-26

some people here has the belief that “semantics� is more important
than “syntax�, and quote a fashionable text book on this.

in this post, i like to correct some widely popular misconception.

syntax is much more important than semantics. Syntax influences
thought, and is all there is to computer langs. Semantics merely tags
alone as a form of more machine code. If the world are made up all
morons, then language semantics will improve, syntax won't.

the so-called semantics in comp lang is just a by-product of
engineering. It is similar to shits like int, long, float, double,
memory address (that induced so-called “garbage collection�), pointer,
cons business, tail recursion, iterator and enumerator, etc.

The gist of a computer lang is manifestly just its syntax. You should
think that a computer language is just its syntax. Once you embrace
this view, languages get better.

what's a good example?

For example, semantics gave us: (cons 1 (cons 2 (cons 3 nil))), and
consequently all the problems of the cons business. If syntax has been
clearly thought of 30 years ago, it'd be {1,2,3} or (1,2,3) or
[1,2,3], and there wouldn't be the cons business.

the force that drove lang progress into functional langs, is the idea
that computer langs are just math notation.

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

PS the above phrasing on the role of syntax and semantics is not
perfect... i haven't yet found the perfect way to describe the
situation... but also, a comp lang isn't just syntax and semantics ...
there are quite a lot issues

Xah
∑ http://xahlee.org/

☄

consing was deliberately put in lisp, so you would have something to blabber
about 50 years after its conception.

Cor
--
Mijn Tools zijn zo modern dat ze allemaal eindigen op 'saurus'
(defvar My-Computer '((OS . "GNU/Emacs") (IPL . "GNU/Linux")))
SPAM DELENDA EST http://www.clsnet.nl/mail.php
1st Law of surviving armed conflict : Have a gun !

"xahlee@gmail.com" <xahlee@gmail.com> wrote on Tue, 26 Aug 2008:
> For example, semantics gave us: (cons 1 (cons 2 (cons 3 nil))), and
> consequently all the problems of the cons business. If syntax has been
> clearly thought of 30 years ago, it'd be {1,2,3} or (1,2,3) or [1,2,3], and
> there wouldn't be the cons business.

What about
'(1 2 3)
That seems to be a syntax just as simple as your three "clearly thought"
examples.

Perhaps Lisp syntax was "clearly thought of 30 years ago" after all?

-- Don
__________________________________________________ _____________________________
Don Geddis http://don.geddis.org/ don@geddis.org
If you think a weakness can be turned into a strength, I hate to tell you this,
but that's another weakness. -- Deep Thoughts, by Jack Handey

On Aug 26, 2:15*pm, "xah...@gmail.com" <xah...@gmail.com> wrote:
> in this post, i like to correct some widely popular misconception.

Go ahead, genius.

> syntax is much more important than semantics.

Yeah right.

> The gist of a computer lang is manifestly just its syntax.

Really?! I thought the example from the "fashionable text book" made
it quite clear the same syntax used in java, c and ocaml/haskell meant
quite different things.

What about blocks like these: {}?
They mean lexically scoped blocks in Java, closures in Ruby, and
unevaluated arguments to Tcl procedures.

By reading a piece of syntax alone, you can infer almost nothing from
what it's supposed to mean.

I'm sorry, but behaviour/meaning/content is far more important than
the syntatic wrapper it comes in. And if you don't like current
syntax, in Lisp at least you can always define new more convenient
syntax at will.

> For example, semantics gave us: (cons 1 (cons 2 (cons 3 nil))), and
> consequently all the problems of the cons business. If syntax has been
> clearly thought of 30 years ago, it'd be {1,2,3} or (1,2,3) or
> [1,2,3], and there wouldn't be the cons business.

I'd like to clarify to you that in Haskell, [1,2,3] is syntatic sugar
(macro if you will) for 1:2:3:[]
Yes, ":" is cons in Haskell. Go there bother than about "this whole
cons business"...

In comp.lang.scheme xahlee@gmail.com <xahlee@gmail.com> wrote:
> syntax is much more important than semantics. Syntax influences
> thought, and is all there is to computer langs.

I'd have to disagree with this. Syntax is a guide to the semantics of
a programming language. You can pick languages that show each in the
extreme and are basically useless for everyday use languages.

Let's take an example like the Unlambda programing language. Here is
a program to compute the fibonnaci sequence, emitting strings of asterisks
representing the number sequence:

```s``s``sii`ki`k.*``s``s`ks``s`k`s`ks``s``s`ks``s `k`s`kr``s`k`sikk`k``s`ksk

I'd call that some pretty regular and very simple syntax.

You can look it up on line to find out the exact meanings (is this
statement ironic in this context or what?) of the above symbols. But
basically, it is functional application and substitution.

However, the meaning of the above is not easy to discern.

> the so-called semantics in comp lang is just a by-product of
> engineering. It is similar to shits like int, long, float, double,
> memory address (that induced so-called ?garbage collection?), pointer,
> cons business, tail recursion, iterator and enumerator, etc.

Semantics describes the *meaning* of a program. The reason why this is so
important is because you can formally describe something like transforming
(define foo 42) into (set! foo 42) while exactly specifying contraints
about your programming language (like how this relates to the definition
of a new variable in your enclosing environment) that must be held true
while the transformation takes place.

Semantics tells you things like the CPS transformation of a direct-style
human written scheme program is *equivalent* to it and *always* will be,
for any direct-style human written scheme program.

Semantics describes meanings and subsequent transformations of those
meanings, possibly under some contraints.

> The gist of a computer lang is manifestly just its syntax. You should
> think that a computer language is just its syntax. Once you embrace
> this view, languages get better.

The syntax of a language is important, I mean, who would want to do long
division in roman numerals? But the real key is how closely does the
syntax of the language mesh in a one to one mapping with the fundamental
entities upon which and with which that language operates?

> For example, semantics gave us: (cons 1 (cons 2 (cons 3 nil))), and
> consequently all the problems of the cons business. If syntax has been
> clearly thought of 30 years ago, it'd be {1,2,3} or (1,2,3) or
> [1,2,3], and there wouldn't be the cons business.

You've used cons here as a red herring. Anyone would have written (list
1 2 3) or (quote 1 2 3) or '(1 2 3) and have been done with it. Do you
know the real difference between those representations? The first is
allocated from heap, meaning that if you pass that line multiple times
in the code, you get multiple in memory objects and can be modified with
things like set-car!, the second/third is unique and may not be modified
with set_car!. The only difference between the second and third is that
human like to type less, hence a syntactic contraction.

Semantics lets us formally understand the difference between:
(list 1 2 3)
and
(quote 1 2 3)

and to understand they might not be interchangable in all cases, but could be
in specialized cases--that semantics allows us to formally detect.

IMHO, syntax is an implementation of semantics.

Later,
-pete