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/

☄

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

2008-08-26

First of all, if you don't have a master degree in computer science,
and, if your specialization is not in computer languages design (i.e.
logics, mathematical formalism, some elements of computational
linguistics), then, you probably won't understand this post. However,
if you are bright, and have a open mind, then the views expressed post
can be meaningful or beneficial to you.

To begin, let me make it explicit that this post is about the concept
of syntax and semantics in computer languages. For example, are
computer languages defined by syntax and semantics? Does syntax and
semantics comprise the whole of a computer language? What is a
computer language? What is syntax, what is semantics? etc.

First, lets note few facts:

• there is no formal and universally accepted definition of what is
meant by “semantics�. There may be some, if so defined, they are
typically based on “models� over idealized, abstract hardware (i.e.
operations on values in storage; as in finite state machine).

• semantics is tied to syntax. There cannot be semantics without
syntax. We could conceptualize a semantic without any syntax, but this
is basically not done.

• a computer language, is typically mathematically defined as a setof
operations on a set of chars. This typical definition, covers
effectively just the syntax. (See http://en.wikipedia.org/wiki/Formal_language)

in general, the study of design of computer languages as languages for
practical use, does not have much formal background. Typically, some
computer scientists (the real ones are properly known as
Mathematicians), create a lang that is LOSELY based on their idea of
some mathematical theory (such as lambda calculus, or other sub
branches of logic.) Lisp, prolog, haskell, apl are such examples. For
vast majority of langs, such as pascal, logo, C, C++, Java, perl, awk,
sh, python, php, ruby, tcl, basic, fortran,... etc, basically their
design, creation, are far removed from any mathematics. It is pretty
much a so-called “art�. Any dummy, can conceive and create a computer
language from scratch based on basically just his personal experiences
in using lang and intuition. This does not mean the lang will be
“bad�. In fact, most successful or widely used langs, results from
such personal creativity.

One of the question we want to ask is, what is a computer language? As
we know, formal methods, such as those based on automata, has nothing
to do with actual langs and is basically just the study of syntax. A
formal languages, of course does also have semantics, but that
semantics basically means transformation of strings. This sense is far
different from what mean by “semantics� in pop books that deal with
real langs (such as the the text book “Programming Languages:
Application and Interpretation�", by Shriram Krishnamurth).

The other question we want to ask, related to the above, is “what
exactly is a computer language?�. There is a popular, unconcious
belief, that a computer language is made up of syntax and semantics.
However, as we know from above, there are no formal definition on what
exactly is semantics that can be applied to computer languages in
daily use.

So, what is then, a computer language? Is there a formal definition
that makes Java, C, perl, lisp, as computer languages? The answer is
just no in our current state of mathematics.

Why is syntax far more important than whatever we intuitively
understood as “semantics�? Because, it is syntax that we actually see
and use in a computer lang, and it is syntax that drives the
development of semantics. When you design a language, you start with
syntax, coupled with some vague idea of what u want to happen, then,
once you wrote a compiler, then is semantics born.

another reason syntax is far more important can be seen from the
history of math notations. Tech geekers might think, notation doesn't
mean much except some convenience aspects. But if you are acquainted
in history of math notation, you'll know that notation largely drove
many development and directions of mathematics. Examples include
arabic numeral with decimal positional notation, symbols for variables
→ abstract algebra, matrix notation → linear algebra, some notations →
calculus. (notations, is somewhat like terminology, in that sometimes
the existance of a notation/terminology have huge impact from
awareness of the concept to major influence on thought of a subject.)

Xah
∑ http://xahlee.org/

☄


On Aug 25, 1:58Â*pm, "xah...@gmail.com" <xah...@gmail.com> wrote:
> On Aug 25, 9:01 am, Ali <emailalicl...@gmail.com> wrote:
>
> > On Aug 25, 3:23 pm, "xah...@gmail.com" <xah...@gmail.com> wrote:
>
> > > On Aug 25, 6:09 am, Ali <emailalicl...@gmail.com> wrote:
> > > > c) Create a new lisp, but without these problems, and follow b)?
>
> > > Yes.
>
> > And one (hopefully last) question. Have you considered writing a lisp,
> > or other language, yourself without these irregularities?
>
> No. My knowledge and experience of parsers and compilers is basically
> zero. Say, below any studious person who just graduated from college
> with a computer science degree.
>
> I have some interest in parsers, so this year i started to read and
> learn tools about parsers. In particular, my interest in parsers is
> writing tools for text processing, in particular processing nestedsyntaxsuch as lisp and xml. I have no interest in compilers though.
>
> With the profileration of tools today... i probably can hackup a
> interpreter for some new language in say, perl. Even that will take me
> perhaps half a year or more, and when done, it'd be basically a
> useless toy.
>
> as for language'ssyntax, i do not find nestedsyntaxideal. I have
> been programing elisp as hobby on and off for 2 years. For all my love
> of uniformality, AI, functional programing, honestly i find the nestedsyntaxproblematic. (not counting lisp irregularity since the few lispsyntaxirregularity doesn't matter that much in practice).
>
> (i find nestedsyntaxproblematic for practical reasons. Namely,
> reading the source code and typing it. The other major reason that
> sting me as i start to write more complex programs, is that sequencing
> functions forces me into so much nesting (i.e. several nested mapcar).
> I have some detail in this article:
> “The Concepts and Confusions of Prefix, Infix, Postfix and Fully
> Nested Notations�http://xahlee.org/UnixResource_dir/writ/notations.html
> )
>
> Recently i've been thinking, a idealsyntaxthat completely ditchs any
> form of nesting insyntax. Â*That is, the source code is just a bunch
> of lines, each line is just a sequence of functions. For example,
> Mathematica's prefix notation “f@g@x� or postfix notation“x//g//f�,
> or unix pipe (e.g. “x | g | f�), and APL'ssyntaxis similar idea.
>
> The problem with such asyntaxis that it limits functions to one arg
> only. A solution might be that for any function that needs 2 or more
> args, the lang makes everything as list. But then, this means simple
> things like “1+2*3� becomes something like polish notation “[2 3] * 1
> +�, which is quite unreadable and unatural. APL solves it by allowing
> both binary and uninary functions ... but then i don't think that'd be
> a perfectsyntax.
>
> another train of thought i had recently, is that, i think all langs
> should have lisp's nestedsyntax(with no irregularities), then
> another layer on top of it, whatever it may be. This is how
> Mathematica'ssyntaxis, and i presume also liskell. Since all textual
> langs has a abstractsyntaxtree, and the nestedsyntaxis isomorphic
> to trees, so theoretically all langs could have a nestedsyntaxlike
> lisp's. I'm not sure how difficult this actually is to do, or how
> difficult for a existing lang to add such a layer. I guess its rather
> trivial in the context of compiler science, but i don't know much
> about parsers/compilers to be sure.
>
> if all lang support the pure nestedsyntax, then it will have a major
> impact on cross-lang understanding, usher practical major progress on
> programer's understanding of the role ofsyntaxin langs, and have
> major impact on language translation (aka compiling). (after all,
> theoretically, proper parser/compiler creates a AST in the parsing
> stage anyway. A pure nestedsyntaxcould be made as a explicit stage.
> That is, sugarsyntax→ nestedsyntax→ AST)
>
> 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 nestedsyntaxlike lisp (as a layer), might actually be a
> reality say in maybe 20 or 50 years.
>
> Â* Â* Â* Â* Â* Â* Â* * Â* Â* Â* Â* Â* Â* Â** Â* Â* Â* Â* Â* Â* Â**
>
> 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.
>
> I also have far more interest in many math subjects and geometry
> programing subjects. I have much existing projects to be done in
> geometry of plane curves, tiling theory, algorithmic mathematical art,
> surface theory, etc. (you can find these on my website)
>
> my interest in computational mathematics (computational logic,
> programing geometry) outshine my interest in programing langs or
> typical computer science issues. (am expert in programing geometry; am
> newbie in computational logic)
>
> Â*Xah
> ∑http://xahlee.org/
>
> ☄

"xahlee@gmail.com" <xahlee@gmail.com> writes:
> To begin, let me make it explicit that this post is about the concept
> of syntax and semantics in computer languages. For example, are
> computer languages defined by syntax and semantics? Does syntax and
> semantics comprise the whole of a computer language? What is a
> computer language? What is syntax, what is semantics? etc.
>
> First, lets note few facts:
>
> • there is no formal and universally accepted definition of what is
> meant by “semantics�. There may be some, if so defined, they are
> typically based on “models� over idealized, abstract hardware (i.e.
> operations on values in storage; as in finite state machine).

I think that something along the lines of "the results of evaluating an
expression or statement written in the language" would be a suitable
working definition. No, I don't have a citation for that. But in my
experience, people don't tend to be too confused as to what "semantics"
means.

> • semantics is tied to syntax. There cannot be semantics without
> syntax. We could conceptualize a semantic without any syntax, but this
> is basically not done.

I think you have this backwards. Syntax is meaningless without
semantics. The same set of semantics can have multiple syntactic
expressions (this was the original intent behind Lisp's [lack of]
syntax, so far as I know). Further, similar syntaxes (sp?) can have
very different semantics. See the plethora of rather diverse languages
with C-based syntax for examples.

Semantics can exist without syntax. It's just difficult to talk about.

> • a computer language, is typically mathematically defined as a set of
> operations on a set of chars. This typical definition, covers
> effectively just the syntax. (See
> http://en.wikipedia.org/wiki/Formal_language)
>
> in general, the study of design of computer languages as languages for
> practical use, does not have much formal background. Typically, some
> computer scientists (the real ones are properly known as
> Mathematicians), create a lang that is LOSELY based on their idea of
> some mathematical theory (such as lambda calculus, or other sub
> branches of logic.) Lisp, prolog, haskell, apl are such examples. For
> vast majority of langs, such as pascal, logo, C, C++, Java, perl, awk,
> sh, python, php, ruby, tcl, basic, fortran,... etc, basically their
> design, creation, are far removed from any mathematics. It is pretty
> much a so-called “art�. Any dummy, can conceive and create a computer
> language from scratch based on basically just his personal experiences
> in using lang and intuition. This does not mean the lang will be
> “bad�. In fact, most successful or widely used langs, results from
> such personal creativity.

Many successful and widely used languages are built from such personal
creativity. Perl and Python come to mind.

There are exceptions, however: Standard ML has a complete mathematical
definition of its semantics for at least the core language (see "The
Definition of Standard ML"). Haskell also has a lot of formalism about
it, but I am not sure how thoroughly its semantics are defined.

> One of the question we want to ask is, what is a computer language? As
> we know, formal methods, such as those based on automata, has nothing
> to do with actual langs and is basically just the study of syntax. A
> formal languages, of course does also have semantics, but that
> semantics basically means transformation of strings.

Patently false. Formal languages, such as definitions of Turing
machines, are typically dealt with without any particular syntax. You
can express them in a variety of ways (an annotated state diagram, a
table, a list of functions), and they are semantically equivalent.

Lambda calculii probably have a more consistent syntax, but the syntax
remains just a representation of the abstract concepts.

> This sense is far different from what mean by “semantics� in pop books
> that deal with real langs (such as the the text book “Programming
> Languages: Application and Interpretation�", by Shriram Krishnamurth).

> The other question we want to ask, related to the above, is “what
> exactly is a computer language?�. There is a popular, unconcious
> belief, that a computer language is made up of syntax and semantics.
> However, as we know from above, there are no formal definition on what
> exactly is semantics that can be applied to computer languages in
> daily use.

The graduate level programming languages course I took in my
undergraduate years had a pretty good definition, I thought: "a language
capable of expressing every computable function."

> So, what is then, a computer language? Is there a formal definition
> that makes Java, C, perl, lisp, as computer languages? The answer is
> just no in our current state of mathematics.

Using the definition above, all that is necessary to show that they are
programming languages is to demonstrate that is possible to reduce a
Turing machine (the definition of computability) to them. That they are
computer languages is self-evident -- they are languages processable by
or controlling computers.

They may not be well-defined languages, but they certainly are
programming languages.

> Why is syntax far more important than whatever we intuitively
> understood as “semantics�? Because, it is syntax that we actually see
> and use in a computer lang, and it is syntax that drives the
> development of semantics. When you design a language, you start with
> syntax, coupled with some vague idea of what u want to happen, then,
> once you wrote a compiler, then is semantics born.

Again, not necessarily true. It may be true in some languages (perhaps
Perl), but not in others. As stated above, Standard ML has a complete
semantic definition. In the Python community, when adding new language
features, there have been times when they new most of what they wanted
semantically but it took some time to nail down what the syntax would
be.

I would argue that development goes in exactly the opposite description
you describe: one first thinks of what one wants to tell the computer to
do, and then figures out how to write it down.

> another reason syntax is far more important can be seen from the
> history of math notations. Tech geekers might think, notation doesn't
> mean much except some convenience aspects. But if you are acquainted
> in history of math notation, you'll know that notation largely drove
> many development and directions of mathematics. Examples include
> arabic numeral with decimal positional notation, symbols for variables
> → abstract algebra, matrix notation → linear algebra, some notations →
> calculus. (notations, is somewhat like terminology, in that sometimes
> the existance of a notation/terminology have huge impact from
> awareness of the concept to major influence on thought of a subject.)

Sure, syntax and notations are nice. But that does not make them more
important than semantics. It simply means that syntax makes it easier
to discuss semantics coherently.

- Michael

--
mouse, n: A device for pointing at the xterm in which you want to type.