alright, as a consequence of the current thread “Xah on Lisp”, i took
some time to clean up my essay.
here's what i have so far on the syntax irregularity subsection:
----------------------------------------------
Fundamental Problems of Lisp
Xah Lee, 2008-07
In this article, we discuss 2 problems that are rooted in lisp. One is
the irregularity in its often cited regular syntax. The other is the
language's use of “cons” for list.
SYNTAX IRREGULARITIES
Lisp family of languages, in particular, Common Lisp, Scheme Lisp,
Emacs Lisp, are well know for its syntax's regularity, namely,
“everything” is of the form “(f x1 x2 ...)”. However, it is little
talked about that there are several irregularities in its syntax. Here
are some examples of the syntax irregularity.
* The comment syntax of semicolon to end of line “;”.
* The dotted notation for cons cell “(1 . 2)”.
* The single quote syntax used to hold evaluation, e.g. “'(1 2
3)”.
* The backquote and comma syntax used to hold but evaluate parts
of expression, e.g. “(setq x 1) (setq myVariableAndValuePair
`(x ,x))”.
* The “,@” for inserting a list as elements into another list.
e.g. “(setq myListX (list 1 2)) (setq myListY (list 3 4)) (setq
myListXY `(,@ myListX ,@ myListY))”
In the following, we detail how these irregularities hamper the power
of regular syntax, and some powerful features and language
developments that lisp have missed that may be caused by it.
--------------------
Confusing
Lisp's irregular syntax are practically confusing. For example, the
difference between “(list 1 2 3)”, “'(1 2 3)”, “(quote (1 2 3))” is a
frequently asked question. The use of “`”, “,”, “,@” etc are esoteric.
If for all these special syntactical elements use the regular form “(f
args)”, then much confusion will be reduced and people will understand
and use these features better. For example, The “'(1 2 3)” might be
changed to “(' 1 2 3)”, and
(setq myListXY `(,@ myListX ,@ myListY))
could have been:
(setq myListXY (eval-parts (splice myListX) (splice myListY)))
or with sugar syntax for typing convenience:
(setq myListXY (` (,@ myListX) (,@ myListY)))”
--------------------
Syntax-Semantics Correspondence
A regular nested syntax has a one-to-one correspondence to the
language's abstract syntax tree, and to a large extent the syntax has
some correspondence to the language's semantics. The irregularities in
syntax breaks this correspondence.
For example, programers can pretty much tell what piece of source code
“(f args)” do by just reading the function's name. As a contrast, in
syntax soup languages such as Java, Perl, the programmer must be
familiar with each of its tens of syntactical forms. (e.g. “if (...)
{...}”, “for (...; ...; ...) {...}”, “(some? this: that)”, “x++”,
“myList = [1, 2, 3]” etc.) As one example, if lisp's “'(1 2 3)” is
actually “(quote 1 2 3)” or shortcut form “(' 1 2 3)”, then it is much
easier to understand.
--------------------
Source Code Transformation
Lisp relies on a regular nested syntax. Because of such regularity of
the syntax, it allows transformation of the source code by a simple
lexical scan. This has powerful ramification. (lisp's macros is one
example) For example, since the syntax is regular, one could easily
have alternative, easier to read syntaxes as a layer. (the concept is
somewhat known in early lisp as M-expression) Mathematica took this
advantage (probably independent of lisp's influence), so that you
really have easy to read syntax, yet fully retain the regular form
advantages. In lisp history, such layer been done and tried here and
there in various forms or langs ( CGOL↗, Dylan↗), but never caught on
due to largely social happenings. Part of these reasons are political
and lisper's sensitivity to criticism of its nested parens.
--------------------
Automatic, Uniform, Universal, Source Code Formatting
One of the advantage of pure fully functional syntax is that a
programer should never need to format his source code (i.e. pressing
tabs, returns) in coding, and save the hundreds hours of labor,
guides, tutorials, advices, publications, editor tools, on what's
known as “coding style convention”, because the editor can reformat
the source code on the fly based on a simple lexical scan.
Because lisp's syntax has lots of nested parenthesis, the source code
formatting is much more a labor intensive than syntax soup languages
such as Perl, even with dedicated lisp editor such as emacs that
contain large number editing commands on nested syntax.
The lisp community, established a particular way of formatting lisp
code as exhibited in emacs's lisp modes and written guides of
conventions. The recognization of such convention further erode any
possibility and awareness of automatic, uniform, universal,
formatting. (e.g. the uniform and universal part of advantage is
exhibited by Python)
As a example, the Mathematica language features a pure nested syntax
similar to lisp but without irregularities. So, in that language,
since version 3 released in 1996, the source code in its editor are
automatically formatted on the fly as programer types, much in the
same way paragraphs are automatically wrapped in a word processor
since early 1990s
--------------------
Syntax As Markup Language
One of the power of such pure nested syntax is that you could build up
layers on top of it, so that the source code can function as markup of
conventional mathematical notations (i.e. MathML) and or as a word-
processing-like file that can contain structures, images (e.g.
Microsoft Office Open XML↗), yet lose practical nothing.
This is done in Mathematica in 1996 with release of Mathematica
version 3. (e.g. think of XML, its uniform nested syntax, its diverse
use as a markup lang, then, some people are adding computational
semantics to it now (i.e. a computer language with syntax of xml. e.g.
O:XML↗). You can think of Mathematica going the other way, by starting
with a computer lang with a regular nested syntax, then add new but
inert keywords to it with markup semantics. The compiler will just
treat these inert keywords like comment syntax when doing computation.
When the source code is read by a editor, the editor takes the markup
keywords for structural or stylitic representation, with title,
chapter heading, tables, images, animations, hyperlinks, typeset math
expression (e.g. think of MathML↗) etc. The non-marked-up keywords are
shown as one-dimentional textual source code just like source code is
normally shown is most languages.)
---------------------
I spend about 4 hours on it today. The cleaning up is only about 20%
done. There's probably few days full time work. Above is what i have
so far on the part about irregularities of syntax problem. No editing
has yet done on the cons business section (e.g. the very phrase “cons
business” needs to be rephrased, depending on what kind of publication
it's gonna go to). Also, the postscript and addendum sections and
possibly the FAQ section, together currently constitute more that 50%
of the text, needs to be incorporated into the main text. The section
“Will Lisp ever be Popular” needs to be removed from this article.
the article as it currently stands is at:
http://xahlee.org/UnixResource_dir/writ/lisp_problems.html
In general, editing newsgroup posts into book quality publication is
quite a lot work... Though, having a draft to start with is perhaps
50% of the work.
Xah
∑ http://xahlee.org/
☄
On Aug 24, 1:42 am, ·······@gmail.com" <······@gmail.com> wrote:
>
> (setq myListXY `(,@ myListX ,@ myListY))
>
> could have been:
>
> (setq myListXY (eval-parts (splice myListX) (splice myListY)))
>
> or with sugar syntax for typing convenience:
>
> (setq myListXY (` (,@ myListX) (,@ myListY)))”
>
No, it should be:
(setq myListXY (append myListX myListY))
Anyways the idea of the "reader shortcuts" is to remove extra braces,
your 3rd snippet, these reader shortcuts are simply re-definitions.
Cheers
leppie
2008-08-25
On Aug 24, 12:23 am, leppie <········@gmail.com> wrote:
> On Aug 24, 1:42 am, ·······@gmail.com" <······@gmail.com> wrote:
>
>
>
> > (setq myListXY `(,@ myListX ,@ myListY))
>
> > could have been:
>
> > (setq myListXY (eval-parts (splice myListX) (splice myListY)))
>
> > or with sugar syntax for typing convenience:
>
> > (setq myListXY (` (,@ myListX) (,@ myListY)))”
>
> No, it should be:
>
> (setq myListXY (append myListX myListY))
The example is to serve the purpose of illustration the meaning of “`”
and “,@”. As such, the example i gave:
(setq myListXY (` (,@ myListX) (,@ myListY)))
is to the point.
In particular, the example is not used in the context of “How to join
2 lists”.
> Anyways the idea of the "reader shortcuts" is to remove extra braces,
> your 3rd snippet, these reader shortcuts are simply re-definitions.
Again, the example i gave:
«
(setq myListXY `(,@ myListX ,@ myListY))
could have been:
(setq myListXY (eval-parts (splice myListX) (splice myListY)))
or with sugar syntax for typing convenience:
(setq myListXY (` (,@ myListX) (,@ myListY)))”
»
is to illustrate a alternative syntax variation design that are
consistent with lisp's syntax philosophy of regularity. In particular,
the example is not in the context of how to redefine a variable.
ultimately, you have to ask why lisper advocate nested syntax in the
first place.
if lispers love the nested syntax, then, the argument that there
should not be irregularities, has merit. If lispers think occational
irregularities of non parenthesized syntax is good, then there's the
question of how many, or what form. You might as well introduce “i++”
for “(setq i (1+ i))”.
Xah
∑ http://xahlee.org/
☄
> * The comment syntax of semicolon to end of line “;”.
(defmacro comment (&rest args)
nil)
(comment "My amazing code")
(defun blah (x)
...)
Not an entire solution, but for global comments at least, you have the
syntax you wanted.
The compiler will ignore your comments, as it should do.
On Aug 25, 5:26 am, Ali <·············@gmail.com> wrote:
> > * The comment syntax of semicolon to end of line “;”.
>
> (defmacro comment (&rest args)
> nil)
>
> (comment "My amazing code")
> (defun blah (x)
> ...)
>
> Not an entire solution, but for global comments at least, you have the
> syntax you wanted.
> The compiler will ignore your comments, as it should do.
The essay is a criticism on the design, it is not about “what are some
workarounds?”.
If your post is to argue that the criticism is invalid because there
are easy workaround, then that is not a good argument. For example, if
you criticise that a particula model of car's wheel is too small.
Then, some fan retort that you can easily install larger wheels. But
for the public at large, they still suffer from the small wheel
problem. For each person to install larger wheel has multiple costs.
The awareness of the need to change wheel is a cost of knowledge
transmission. The actual replacement costs money and time. Also, each
person may use different sized wheels, and the replacement may not be
well done... so in general, such workaround although is satisfactory
for individuals who knows about the issue and takes time to fix it,
but on the whole does not invalidate the criticism.
I would recommend this article in Wikipedia on
http://en.wikipedia.org/wiki/Critical_thinking
Xah
∑ http://xahlee.org/
☄
So what?
a) Should all lispers see the errors of lisp as critical and recommend
people not start using it?
b) Start using a different language that does not come with these
built-in problems?
c) Create a new lisp, but without these problems, and follow b)?
d) Continue using lisp, but drag our heads in shame at the nasty
horrible terrible hacks we endure?
That's not rhetorical, please could you reply with an "a", "b", "c",
"d" or "other"?
On Aug 25, 6:09 am, Ali <·············@gmail.com> wrote:
> So what?
> a) Should all lispers see the errors of lisp as critical and recommend
> people not start using it?
> b) Start using a different language that does not come with these
> built-in problems?
> c) Create a new lisp, but without these problems, and follow b)?
> d) Continue using lisp, but drag our heads in shame at the nasty
> horrible terrible hacks we endure?
>
> That's not rhetorical, please could you reply with an "a", "b", "c",
> "d" or "other"?
A criticism is just a criticism. My criticism in particular, does not
mean lisp is bad. In fact, i recommend lisp as a language. I myself
love and use emacs lisp extensively. As for Scheme Lisp and Common
Lisp, i consider them better languages than, say, C, Java, Perl,
Pyhton, PHP.
> a) Should all lispers see the errors of lisp as critical and recommend
> people not start using it?
Of course not.
> b) Start using a different language that does not come with these
> built-in problems?
No.
The importance of criticism is that it serves a particular aspect of
in the benefits of communication. You as a lisp programer, may or may
not agree to the severity of the criticism. However, nevertheless it
serves a purpose as a minor form of knowledge, namely that of
awareness of some issues.
As a example of positive outcome of such awareness, perhaps someone
working on a lang with lisp syntax (such as liskell) would now avoid
syntax irregularities. Apparantly Qi and Arc also used irregular
syntax. But, if the criticism about lisp's syntax irregularities is
well known, and if known ten years ago, then just perhaps Qi and Arc
would stick to a pure nested syntax without any irregularities.
Even if someone does not agree with the criticism on lisp's syntax
after serious evaluation, nevertheless some issues discussed in the
article does serve some type of infomation communication and ideas;
such as regularity of syntax and consequences and its relation to XML
and its various transformation technologies, markup lang based on
regularities of syntax, etc.
> c) Create a new lisp, but without these problems, and follow b)?
Yes. That would be a very direct and positive consequence of the
criticism.
(Whether if such a lang would actually be beneficial as the criticsim
implied, we perhaps have to see it in practice.)
> d) Continue using lisp, but drag our heads in shame at the nasty
> horrible terrible hacks we endure?
No.
Of course, negative criticisms always have certain bad aura.
Particularly when power is involved in the subject such as stances and
beliefs in political factions. The essay receives a lot sneering
precisely because computer language communities are in fact highly
political.
Computer langs are not religions per se. People can be attached to a
lang, but a language is nevertheless not a set of dogma on
metaphysical issues that makes up religion. Sensible discussion of
computer languages, technical comparison, should be encouraged. Issues
like what lang should be more used, or which is more popular, or what
makes a lang better, are subject to study under various branches of
psychology, sociology.
> That's not rhetorical, please could you reply with an "a", "b", "c",
> "d" or "other"?
Happy to do so. :D
Xah
∑ http://xahlee.org/
☄
On Aug 25, 3:23 pm, ·······@gmail.com" <······@gmail.com> wrote:
> On Aug 25, 6:09 am, Ali <·············@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?
On Aug 25, 9:01 am, Ali <·············@gmail.com> wrote:
> On Aug 25, 3:23 pm, ·······@gmail.com" <······@gmail.com> wrote:
>
> > On Aug 25, 6:09 am, Ali <·············@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 nested
syntax such 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's syntax, i do not find nested syntax ideal. 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 nested
syntax problematic. (not counting lisp irregularity since the few lisp
syntax irregularity doesn't matter that much in practice).
(i find nested syntax problematic 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 ideal syntax that completely ditchs any
form of nesting in syntax. 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 ··@·@x” or postfix notation “x//g//f”,
or unix pipe (e.g. “x | g | f”), and APL's syntax is similar idea.
The problem with such a syntax is 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 perfect syntax.
another train of thought i had recently, is that, i think all langs
should have lisp's nested syntax (with no irregularities), then
another layer on top of it, whatever it may be. This is how
Mathematica's syntax is, and i presume also liskell. Since all textual
langs has a abstract syntax tree, and the nested syntax is isomorphic
to trees, so theoretically all langs could have a nested syntax like
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 nested syntax, then it will have a major
impact on cross-lang understanding, usher practical major progress on
programer's understanding of the role of syntax in 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 nested syntax could be made as a explicit stage.
That is, sugar syntax → nested syntax → 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 nested syntax like 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/
☄
On 25 ago, 17:58, ·······@gmail.com" <······@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.
On Mon, 25 Aug 2008 14:31:43 -0700 (PDT), 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/Publications/Books/ProgLangs/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 <············@Yahoo.com>
wrote:
> On Mon, 25 Aug 2008 14:31:43 -0700 (PDT), 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’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/Publications/Books/ProgLangs/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
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.
······@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, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
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/
☄
·······@gmail.com" <······@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/ ···@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
Don Geddis <···@geddis.org> writes:
> ·······@gmail.com" <······@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, please stop.
1- it wasn't 30 years ago, it was 50 years ago.
2- the syntax for lisp code wasn't (1,2,3), it was list[1;2;3]
(and it was defined, not as CONSes,
but as combine[1;combine[2;combine[3,NIL]]]).
3- the syntax for lisp data was (1,2,3). So:
list[1;2;3] --> (1,2,3)
Which means that we don't write lisp CODE since ever LISP was
implemented 50 years ago, we feed it only lisp DATA, and it just
interprets it. Lisp code was only written in scientific papers.
--
__Pascal Bourguignon__ http://www.informatimago.com/
In a World without Walls and Fences,
who needs Windows and Gates?
On Aug 26, 2:15 pm, ·······@gmail.com" <······@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"...
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 !
In comp.lang.scheme ······@gmail.com <······@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 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.
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, ·······@gmail.com" <······@gmail.com> wrote:
> On Aug 25, 9:01 am, Ali <·············@gmail.com> wrote:
>
> > On Aug 25, 3:23 pm, ·······@gmail.com" <······@gmail.com> wrote:
>
> > > On Aug 25, 6:09 am, Ali <·············@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 ··@·@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/
>
> ☄
·······@gmail.com" <······@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.
·······@gmail.com" <······@gmail.com> wrote on Fri, 29 Aug 2008:
[...]
> To begin, let me make it explicit that this post is about the concept
> of syntax and semantics in computer languages.
[...]
Xah, I disagreed with much of what you wrote in that post. But rather than
comment negatively on the content, I wanted to comment positively on the
form. You didn't gratuitously insult your readers (much...), and you
attempted to be constructive. I appreciate the effort, at least (if perhaps
not so much the result).
-- Don
_______________________________________________________________________________
Don Geddis http://don.geddis.org/ ···@geddis.org
Computer Science is no more about computers than astronomy is about telescopes.
-- E. W. Dijkstra
On 30 ago, 00:28, Don Geddis <····@geddis.org> wrote:
> ·······@gmail.com" <······@gmail.com> wrote on Fri, 29 Aug 2008:
> You didn't gratuitously insult your readers (much...)
Yeah, here's him insulting all the verms below his gorgeous IQ:
"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."
OTOH, his highness himself seems positively confused and unable to
make a distinction between syntax and semantics, despite being pointed
already more than once to simple examples that dispell all of his
verbose logic based on false premises...
······@gmail.com wrote:
> First, lets note few facts:
>
> • there is no formal and universally accepted definition of what is
> meant by “semantics”.
This statement is false. Formal semantics is mathematics. Figuring
out what a statement is supposed to do is proving a theorem given the
defined axioms of the formal semantics. The semantics of a statement
are a transformation of one program state into another. Usually we
represent the program states as strings, hence the relevance of grammars
for transforming one string into another.
> 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).
Granted, actual implementations on machines with finite memory tend
to be unable to fully implement the formal semantics of a language,
in much the same way that automated theorem provers on machines with
finite memory are unable to prove some theorems.
> • 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.
In current languages, semantics is tied much more closely to the parse
tree of an expression than it is to the syntax, but whatever - there
is a connection, because the parse tree is computed from the grammar
and the syntax.
> 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).
Hm. Okay, granted, a grammar transforms strings into strings.
But if the input string is program text and the output string
is machine instructions, we call that grammar a compiler. This
is not how most actual compilers are written, but this is a
complete formal model of what a compiler is and does, and therefore
allows us to prove theorems about what is and isn't possible
for compilers.
Anyway, type-0 grammars are Turing equivalent, which means they
provide a general model of computability and can calculate any
computable function. What this means is that you can implement
the semantics of any computer language as a type-0 grammar that
transforms program source and input directly into output without
ever bothering to create instructions for a specific machine along
the way. You can also implement a grammar that transforms your
program text into another grammar, which will transform input
into output.
Even with the reduced power of a type-2 grammar (the context-free
languages, which includes nearly all modern computer languages)
you can directly solve most math problems using string manipulation
rules. I know, because I implemented exactly that as homework once.
You start by implementing incrementing, decrementing, doubling,
and halving as string transformation operations, introduce
nonterminal symbols that can prepend numbers indicating that one
of these operations is needed, and go from there.
I guess my point is that "transforming strings into strings"
*is* a pretty darn good model of what a compiler does, and a
pretty good model of semantics, and understanding the theory
*is* relevant far beyond dealing with the surface syntax of a
language.
> The other question we want to ask, related to the above, is “what
> exactly is a computer language?”. There is a popular, unconcious
true
> belief, that a computer language is made up of syntax and semantics.
...
> another reason syntax is far more important can be seen from the
> history of math notations. ... 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.)
>
This is definitely true. A good notation makes something easier to
reason about, usually by associating or "bundling" related concepts
in a more efficient or useful way.
Bear
Ray Dillinger <····@sonic.net> wrote:
+---------------
| Even with the reduced power of a type-2 grammar (the context-free
| languages, which includes nearly all modern computer languages)
| you can directly solve most math problems using string manipulation
| rules. I know, because I implemented exactly that as homework once.
| You start by implementing incrementing, decrementing, doubling,
| and halving as string transformation operations, introduce
| nonterminal symbols that can prepend numbers indicating that one
| of these operations is needed, and go from there.
|
| I guess my point is that "transforming strings into strings"
| *is* a pretty darn good model of what a compiler does, and a
| pretty good model of semantics, and understanding the theory
| *is* relevant far beyond dealing with the surface syntax of a
| language.
+---------------
Indeed. In this regard Kent Dybvig's PhD thesis[1] may be of interest
to some. It's most frequently cited for its contributions to showing
how/when one could use stack-based (versus heap-based) lexical variables
in Scheme, but also included a string-based model. From the abstract:
This dissertation presents three implementation models for the
Scheme Programming Language. The first is a heap-based model used
in some form in most Scheme implementations to date; the second is
a new stack-based model that is considerably more effcient than
the heap-based model at executing most programs; and the third is
a new string-based model intended for use in a multiple-processor
implementation of Scheme. ... The string-based model allocates
versions of these structures right in the program text, which
is represented as a string of symbols. In the string-based model,
Scheme programs are translated into an FFP language designed
specifically to support Scheme. Programs in this language are
directly executed by the FFP machine, a multiple-processor
string-reduction computer.
And from "Chapter 5: The String-Based Model":
The string-based implementation model proposed in this chapter is
intended for the FFP machine... [which] employs string reduction,
evaluating expressions in FFP by reducing the text of the FFP
program piece by piece until each evaluable expression has been
fully reduced. It would be possible to employ the techniques
described herein to design a Scheme implementation for any
processor capable of string reduction.
"Rewrite-rule" or "reduction" computers were a quite active area
of research several decades ago, though not so much these days.
-Rob
[1] http://www.cs.indiana.edu/~dyb/papers/3imp.pdf
"Three Implementation Models for Scheme",
R. Kent Dybvig,
University of North Carolina Computer Science
Technical Report 87-011 [Ph.D. Dissertation], April 1987.
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
····@rpw3.org (Rob Warnock) writes:
> "Rewrite-rule" or "reduction" computers were a quite active area
> of research several decades ago, though not so much these days.
I think Haskell is just about always implemented with graph rewriting
(reduction), though specified in lambda calculus. Clean is specified
in terms of graph rewriting which the authors claim has advantages.
On Aug 24, 1:42 am, ·······@gmail.com" <······@gmail.com> wrote:
> alright, as a consequence of the current thread “Xah on Lisp”, i took
> some time to clean up my essay.
>
> here's what i have so far on the syntax irregularity subsection:
>
> ----------------------------------------------
>
> Fundamental Problems of Lisp
>
> Xah Lee, 2008-07
>
> In this article, we discuss 2 problems that are rooted in lisp. One is
> the irregularity in its often cited regular syntax. The other is the
> language's use of “cons” for list.
>
> SYNTAX IRREGULARITIES
>
> Lisp family of languages, in particular, Common Lisp, Scheme Lisp,
> Emacs Lisp, are well know for its syntax's regularity, namely,
> “everything” is of the form “(f x1 x2 ...)”. However, it is little
> talked about that there are several irregularities in its syntax. Here
> are some examples of the syntax irregularity.
>
> * The comment syntax of semicolon to end of line “;”.
>
> * The dotted notation for cons cell “(1 . 2)”.
>
> * The single quote syntax used to hold evaluation, e.g. “'(1 2
> 3)”.
>
> * The backquote and comma syntax used to hold but evaluate parts
> of expression, e.g. “(setq x 1) (setq myVariableAndValuePair
> `(x ,x))”.
>
> * The “,@” for inserting a list as elements into another list.
> e.g. “(setq myListX (list 1 2)) (setq myListY (list 3 4)) (setq
> myListXY `(,@ myListX ,@ myListY))”
>
> In the following, we detail how these irregularities hamper the power
> of regular syntax, and some powerful features and language
> developments that lisp have missed that may be caused by it.
>
> --------------------
> Confusing
>
> Lisp's irregular syntax are practically confusing. For example, the
> difference between “(list 1 2 3)”, “'(1 2 3)”, “(quote (1 2 3))” is a
> frequently asked question. The use of “`”, “,”, “,@” etc are esoteric.
> If for all these special syntactical elements use the regular form “(f
> args)”, then much confusion will be reduced and people will understand
> and use these features better. For example, The “'(1 2 3)” might be
> changed to “(' 1 2 3)”, and
>
> (setq myListXY `(,@ myListX ,@ myListY))
>
> could have been:
>
> (setq myListXY (eval-parts (splice myListX) (splice myListY)))
>
> or with sugar syntax for typing convenience:
>
> (setq myListXY (` (,@ myListX) (,@ myListY)))”
>
> --------------------
> Syntax-Semantics Correspondence
>
> A regular nested syntax has a one-to-one correspondence to the
> language's abstract syntax tree, and to a large extent the syntax has
> some correspondence to the language's semantics. The irregularities in
> syntax breaks this correspondence.
>
> For example, programers can pretty much tell what piece of source code
> “(f args)” do by just reading the function's name. As a contrast, in
> syntax soup languages such as Java, Perl, the programmer must be
> familiar with each of its tens of syntactical forms. (e.g. “if (...)
> {...}”, “for (...; ...; ...) {...}”, “(some? this: that)”, “x++”,
> “myList = [1, 2, 3]” etc.) As one example, if lisp's “'(1 2 3)” is
> actually “(quote 1 2 3)” or shortcut form “(' 1 2 3)”, then it is much
> easier to understand.
>
> --------------------
> Source Code Transformation
>
> Lisp relies on a regular nested syntax. Because of such regularity of
> the syntax, it allows transformation of the source code by a simple
> lexical scan. This has powerful ramification. (lisp's macros is one
> example) For example, since the syntax is regular, one could easily
> have alternative, easier to read syntaxes as a layer. (the concept is
> somewhat known in early lisp as M-expression) Mathematica took this
> advantage (probably independent of lisp's influence), so that you
> really have easy to read syntax, yet fully retain the regular form
> advantages. In lisp history, such layer been done and tried here and
> there in various forms or langs ( CGOL↗, Dylan↗), but never caught on
> due to largely social happenings. Part of these reasons are political
> and lisper's sensitivity to criticism of its nested parens.
>
> --------------------
> Automatic, Uniform, Universal, Source Code Formatting
>
> One of the advantage of pure fully functional syntax is that a
> programer should never need to format his source code (i.e. pressing
> tabs, returns) in coding, and save the hundreds hours of labor,
> guides, tutorials, advices, publications, editor tools, on what's
> known as “coding style convention”, because the editor can reformat
> the source code on the fly based on a simple lexical scan.
>
> Because lisp's syntax has lots of nested parenthesis, the source code
> formatting is much more a labor intensive than syntax soup languages
> such as Perl, even with dedicated lisp editor such as emacs that
> contain large number editing commands on nested syntax.
>
> The lisp community, established a particular way of formatting lisp
> code as exhibited in emacs's lisp modes and written guides of
> conventions. The recognization of such convention further erode any
> possibility and awareness of automatic, uniform, universal,
> formatting. (e.g. the uniform and universal part of advantage is
> exhibited by Python)
>
> As a example, the Mathematica language features a pure nested syntax
> similar to lisp but without irregularities. So, in that language,
> since version 3 released in 1996, the source code in its editor are
> automatically formatted on the fly as programer types, much in the
> same way paragraphs are automatically wrapped in a word processor
> since early 1990s
>
> --------------------
> Syntax As Markup Language
>
> One of the power of such pure nested syntax is that you could build up
> layers on top of it, so that the source code can function as markup of
> conventional mathematical notations (i.e. MathML) and or as a word-
> processing-like file that can contain structures, images (e.g.
> Microsoft Office Open XML↗), yet lose practical nothing.
>
> This is done in Mathematica in 1996 with release of Mathematica
> version 3. (e.g. think of XML, its uniform nested syntax, its diverse
> use as a markup lang, then, some people are adding computational
> semantics to it now (i.e. a computer language with syntax of xml. e.g.
> O:XML↗). You can think of Mathematica going the other way, by starting
> with a computer lang with a regular nested syntax, then add new but
> inert keywords to it with markup semantics. The compiler will just
> treat these inert keywords like comment syntax when doing computation.
> When the source code is read by a editor, the editor takes the markup
> keywords for structural or stylitic representation, with title,
> chapter heading, tables, images, animations, hyperlinks, typeset math
> expression (e.g. think of MathML↗) etc. The non-marked-up keywords are
> shown as one-dimentional textual source code just like source code is
> normally shown is most languages.)
>
> ---------------------
>
> I spend about 4 hours on it today. The cleaning up is only about 20%
> done. There's probably few days full time work. Above is what i have
> so far on the part about irregularities of syntax problem. No editing
> has yet done on the cons business section (e.g. the very phrase “cons
> business” needs to be rephrased, depending on what kind of publication
> it's gonna go to). Also, the postscript and addendum sections and
> possibly the FAQ section, together currently constitute more that 50%
> of the text, needs to be incorporated into the main text. The section
> “Will Lisp ever be Popular” needs to be removed from this article.
>
> the article as it currently stands is at:http://xahlee.org/UnixResource_dir/writ/lisp_problems.html
>
> In general, editing newsgroup posts into book quality publication is
> quite a lot work... Though, having a draft to start with is perhaps
> 50% of the work.
>
> Xah
> ∑http://xahlee.org/
>
> ☄
I dont share your concerns described in your article.
'a is simply short for (quote a). For example:
(car ''a) = (car (quote (quote a))) --> quote (i.e. the car of (quote
a))
It is not clear to me why you would want to write (quote (1 2 3)) as
(quote 1 2 3).
What would in this case be the value of (quote quote 1 2 3)?
I find the quasiquote (and quasisyntax) notation very useful.
There is one nasty pitfall though:
(define *a 1)
(define *quasiquote 2)
(define *unquote 3)
`((a ,*a) (quasiquote ,*quasiquote)) ;--> ((a 1) (quasiquote (unquote
*quasiquote)))
`((a ,*a) (quasiquote ,*quasiquote) (unquote ,*unquote)); --> error:
unquote: not in quasiquote in: (unquote *unquote)
^^^^^^^^^
The correct way to introduce symbols "quasiquote" and "unquote" within
a quasiquote form is:
`((a ,*a) (,'quasiquote ,*quasiquote) (,'unquote ,*unquote)) ;--> ((a
1) (quasiquote 2) (unquote 3))
^^ ^^
Likewise for "unquote-splicing".
Jos