How Lisp's Nested Notation Limits The Language's Utility
Xah Lee
Xah Lee, 2007-05-03
There is a common complain by programers about lisp's notation, of
nested parenthesis, being unnatural or difficult to read. Long time
lisp programers, often counter, that it is a matter of conditioning,
and or blaming the use of “inferior” text editors that are not
designed to display nested notations. In the following, i describe how
lisp notation is actually a problem, in several levels.
(1) Some 99% of programers are not used to the nested parenthesis
syntax. This is a practical problem. On this aspect along, lisp's
syntax can be considered a problem.
(2) Arguably, the pure nested syntax is not natural for human to read.
Long time lispers may disagree on this point.
(3) Most importantly, a pure nested syntax discourages frequent or
advanced use of function sequencing or compositions. This aspect is
the most devastating.
The first issue, that most programers are not comfortable with nested
notation, is well known. It is not a technical issue. Whether it is
considered a problem of the lisp language is a matter of philosophical
disposition.
The second issue, about nested parenthesis not being natural for human
to read, may be debatable. I do think, that deep nesting is a problem
to the programer. Here's a example of 2 blocks of code that are
syntactically equivalent in the Mathematica language:
vectorAngle[{a1_, a2_}] := Module[{x, y},
{x, y} = {a1, a2}/Sqrt[a1^2 + a2^2] // N;
If[x == 0, If[Sign@y === 1, π/2, -π/2],
If[y == 0, If[Sign@x === 1, 0, π],
If[Sign@y === 1, ArcCos@x, 2 π - ArcCos@x]
]
]
]
SetDelayed[vectorAngle[List[Pattern[a1,Blank[]],Pattern[a2,Blank[]]]],
Module[List[x,y],
CompoundExpression[
Set[List[x,y],
N[Times[List[a1,a2],
Power[Sqrt[Plus[Power[a1,2],Power[a2,2]]],-1]]]],
If[Equal[x,0],
If[SameQ[Sign[y],1],Times[π,Power[2,-1]],
Times[Times[-1,π],Power[2,-1]]],
If[Equal[y,0],If[SameQ[Sign[x],1],0,π],
If[SameQ[Sign[y],1],ArcCos[x],
Plus[Times[2,π],Times[-1,ArcCos[x]]]]]]]]]
In the latter, it uses a full nested form (called FullForm in
Mathematica). This form is isomorphic to lisp's nested parenthesis
syntax, token for token (i.e. lisp's “(f a b)” is Mathematica's
“f[a,b]”). As you can see, this form, by the sheer number of nested
brackets, is in practice problematic to read and type. In Mathematica,
nobody really program using this syntax. (The FullForm syntax is
there, for the same reason of language design principle shared with
lisp of “consistency and simplicity”, or the commonly touted lisp
advantage of “data is program; program is data”.)
The third issue, about how nested syntax seriously discourages
frequent or advanced use of inline function sequencing on the fly, is
the most important and I'll give further explanation below.
One practical way to see how this is so, is by considering unix's
shell syntax. You all know, how convenient and powerful is the unix's
pipes. Here are some practical example: “ls -al | grep xyz”, or “cat a
b c | grep xyz | sort | uniq”.
Now suppose, we get rid of the unix's pipe notation, instead, replace
it with a pure functional notation: e.g. (uniq (sort (grep xyz (cat a
b c)))), or enrich it with a composition function and a pure function
construct (λ), so this example can be written as: ((compose (lambda
(x) (grep xyz x)) sort uniq) (cat a b c)).
You see, how this change, although syntactically equivalent to the
pipe “|” (or semantically equivalent in the example using function
compositions), but due to the cumbersome nested syntax, will force a
change in the nature of the language by the code programer produces.
Namely, the frequency of inline sequencing of functions on the fly
will probably be reduced, instead, there will be more code that define
functions with temp variables and apply it just once as with
traditonal languages.
A language's syntax or notation system, has major impact on what kind
of code or style or thinking pattern on the language's users. This is
a well-known fact for those acquainted with the history of math
notations.
The sequential notation “f@g@h@x”, or “x//h//g//f”, or unixy “x|h|g|
f”, are far more convenient and easier to decipher, than “(f (g (h
x)))” or “((compose h g f) x)”. In actual code, any of the f, g, h
might be a complex pure function (aka lambda construct, full of
parenthesis themselves).
Lisp, by sticking with almost uniform nested parenthesis notation, it
immediately reduces the pattern of sequencing functions, simply
because the syntax does not readily lend the programer to it as in the
unix's “x|h|g|f”. For programers who are aware of the coding pattern
of sequencing functions, now either need to think in terms of a
separate “composition” construct, and or subject to the much
problematic typing and deciphering of nested parenthesis.
(Note: Lisp's sexp is actually not that pure. It has ad hoc syntax
equivalents such as the “quote” construct “ '(a b c) ”, and also “`”,
“#”, “,@” constructs, precisely for the purpose of reducing
parenthesis and increasing readability. Scheme's coming standard the
R6RS ↗, even proposes the introduction of [] and {} and few other
syntax sugars to break the uniformity of nested parenthesis for
legibility. Mathematica's FullForm, is actually a pure nested notation
as can be.)
-------
The above, is part of a 3-part exposition:
“The Concepts and Confusions of Prefix, Infix, Postfix and Fully
Functional Notations”,
“Prefix, Infix, Postfix notations in Mathematica”,
“How Lisp's Nested Notation Limits The Language's Utility”,
archived at:
http://xahlee.org/UnixResource_dir/writ/notations.html
Kaz Kylheku
> How Lisp's Nested Notation Limits The Language's Utility
>
> Xah Lee, 2007-05-03
>
> There is a common complain by programers about lisp's notation, of
> nested parenthesis, being unnatural or difficult to read.
That is false. The complaint does not frequently occur among all of
the complaints occured by the entire population of complaintive
programmers.
> (1) Some 99% of programers are not used to the nested parenthesis
> syntax. This is a practical problem.
Since 99% of programmers don't use Lisp, it's not a practical problem.
> (2) Arguably, the pure nested syntax is not natural for human to read.
> Long time lispers may disagree on this point.
Programming language syntax shouldn't be natural for humans to read.
Or, rather, this shouldn't be a requirement which creates technical
compromises.
> (3) Most importantly, a pure nested syntax discourages frequent or
> advanced use of function sequencing or compositions.
That is an artifact of the way in which function composition is
rendered in nested syntax, and not an artifact of that syntax itself.
There exist macros that provide alternate syntax for function
composition, such as a left-to-right pipeline.
> This aspect is the most devastating.
Compared to issues like global warming and problems in the Middle
East, hardly.
> The first issue, that most programers are not comfortable with nested
> notation, is well known.
Many programmers are also not comfortable in social situations. So
what?
> shell syntax. You all know, how convenient and powerful is the unix's
> pipes. Here are some practical example: “ls -al | grep xyz”, or “cat a
> b c | grep xyz | sort | uniq”.
>
> Now suppose, we get rid of the unix's pipe notation, instead, replace
> it with a pure functional notation: e.g. (uniq (sort (grep xyz (cat a
> b c)))),
When you think about this more deeply (i.e. at all) you run into nasty
details. These programs pass their output to each other, but they also
have a return value (termination status) which isn't passed through
the pipeline. And they take arguments, but the arguments of a pipeline
element are not derived from the previous pipeline element.
Your call (grep xyz (cat ...)) means to pass the output of cat as the
third argument of grep.
In the POSIX shell, this would be coded using guess what, Lisp-like
syntax:
grep xyz $(cat ...)
Taking it further:
uniq $(sort $(grep xyz $(cat a b c)))
or enrich it with a composition function and a pure function
> construct (λ), so this example can be written as: ((compose (lambda
> (x) (grep xyz x)) sort uniq) (cat a b c)).
I posted a filter macro in comp.lang.lisp which expresses function
chaining into a left-to-right notation. Look for it.
In this notation, you might write:
(filter 3 (expt _ 2) (* 4))
which means, start with 3, raise it to the power of 2 to obtain 9, and
then multiply by 4 to get 36.
The underscore indicates the argument position where the output of the
previous pipeline element is to be inserted when calling the next
pipeline element. The default is to add it as a rightmost argument.
The macro has features for dealing with splitting and recombining
lists, and handling multiple values.
This is still the same ``pure nested'' syntax; it merely expresses
function chaining differently.
What was that about notation limiting language utility?
Jon Harrop
> vectorAngle[{a1_, a2_}] := Module[{x, y},
> {x, y} = {a1, a2}/Sqrt[a1^2 + a2^2] // N;
> If[y == 0, If[Sign@x === 1, 0, ?],
> If[Sign@y === 1, ArcCos@x, 2 ? - ArcCos@x]
> ]
> ]
> ]
>
> SetDelayed[vectorAngle[List[Pattern[a1,Blank[]],Pattern[a2,Blank[]]]],
> Module[List[x,y],
> CompoundExpression[
> Set[List[x,y],
> N[Times[List[a1,a2],
> Power[Sqrt[Plus[Power[a1,2],Power[a2,2]]],-1]]]],
> If[Equal[x,0],
> Times[Times[-1,?],Power[2,-1]]],
> If[Equal[y,0],If[SameQ[Sign[x],1],0,?],
> If[SameQ[Sign[y],1],ArcCos[x],
Yes. The Mathematica language really brings home the fact that non-trivial
syntax is good. In particular, it does an excellent job of mimicking
conventional mathematical notation. Arguing in favor of Lisp syntax is like
advocating the use of cave painting...
Also, note that Mathematica provides strictly more in the way of macros.
--
Dr Jon D Harrop, Flying Frog Consultancy
The F#.NET Journal
http://www.ffconsultancy.com/products/fsharp_journal/?usenet
Jon Harrop
> On May 4, 5:11 pm, Xah Lee <x...@xahlee.org> wrote:
>> (1) Some 99% of programers are not used to the nested parenthesis
>> syntax. This is a practical problem.
>
> Since 99% of programmers don't use Lisp, it's not a practical problem.
If you're being pedantic, you may mean "it is an uncommon practical
problem". However, the problem extends beyond Lisp.
Recent discussions have covered the use of pattern matching. In SML, OCaml,
Haskell (I believe) and F# you must write pattern matches over the expr
type in prefix notation. To borrow from Alan's example, the Lisp code:
(destructuring-bind (op1 (op2 n x) y) form
`(* ,n (* ,(simplify x) ,(simplify y)))))
((cons (eql *) *)
(destructuring-bind (op left right) form
(list op
(simplify left)
(simplify right))))
((cons (eql +)
(cons (eql 0)
(cons * null)))
could be written:
| n*x*y -> n*(x*y)
but in ML this must be written as a pattern match over a sum type where the
type constructors must use prefix notation:
| Mul(Mul(n, x), y) -> Mul(n, Mul(x, y))
While this is clearly much better than the Lisp, it would be preferable to
use the mathematical syntax in this case. You can address this in OCaml
using macros and there is a chance that F# will support overloaded
operators in patterns in the future.
Mathematica lets you do:
n x y -> n (x y)
but I don't know of any other languages that do, without forcing you to
reinvent the wheel via macros.
Robert D. Crawford
> How Lisp's Nested Notation Limits The Language's Utility
You know, I am all about keeping one's eyes open so as to see the
limitations of the tools one chooses or is forced to use. If more
people were open to the flaws in their OS, religion, editor, and a
myriad of other things the world would surely be a better and more
peaceful place. However, I have to say that all I ever see from you,
Mr. Lee, is complaints and how you want emacs and lisp to change. For
the love of whatever god you choose to pray to, find a frigging tool
that makes you happy. If it is emacs that makes you happy, then change
the things you don't like and be happy but I fail to see how your
whining diatribes serve any useful purpose. If you don't like lisp then
by all means use something else.
No offense but it does get old after a while.
--
Robert D. Crawford rd...@comcast.net
Marriage is learning about women the hard way.
Miles Bader
> If it is emacs that makes you happy, then change the things you don't
> like and be happy but I fail to see how your whining diatribes serve
> any useful purpose. If you don't like lisp then by all means use
> something else.
Xahlee likes to complain. That's the main factor here.
-Miles
--
Run away! Run away!
Rayiner Hashem
> syntax. This is a practical problem. On this aspect along, lisp's
> syntax can be considered a problem.
The first time I saw graph-theory notation, I thought it was
gibberish. I still think most mathematical notation is gibberish, but
I deal with it --- I don't turn in proofs written in prose.
> (2) Arguably, the pure nested syntax is not natural for human to read.
> Long time lispers may disagree on this point.
And mathematical notation is not natural for people to read, at least
not anybody who grew up learning a natural language. But people deal
with it. They're remarkably adaptable this way.
> vectorAngle[{a1_, a2_}] := Module[{x, y},
> {x, y} = {a1, a2}/Sqrt[a1^2 + a2^2] // N;
> If[x == 0, If[Sign@y === 1, π/2, -π/2],
> If[y == 0, If[Sign@x === 1, 0, π],
> If[Sign@y === 1, ArcCos@x, 2 π - ArcCos@x]
> ]
> ]
> ]
Speaking of gibberish. I can't believe anybody would hold up
Mathematica as an example of good programming. Next you'll be telling
me that 99% of Matlab code isn't really crap!
> The third issue, about how nested syntax seriously discourages
> frequent or advanced use of inline function sequencing on the fly, is
> the most important and I'll give further explanation below.
I consider this to be a Good Thing (TM). Unix shell commands read like
line noise.
Edward
> How Lisp's Nested Notation Limits The Language's Utility
>
> Xah Lee, 2007-05-03
>
> There is a common complain by programers about lisp's notation, of
> nested parenthesis, being unnatural or difficult to read. Long time
> lisp programers, often counter, that it is a matter of conditioning,
> and or blaming the use of “inferior” text editors that are not
> designed to display nested notations. In the following, i describe how
> lisp notation is actually a problem, in several levels.
As a practical matter, most LISPers don't even see the parens, but
rather interpret the code according to the indentation.
> (1) Some 99% of programers are not used to the nested parenthesis
> syntax. This is a practical problem. On this aspect along, lisp's
> syntax can be considered a problem.
It's certainly different. Whether it is a problem or not depends on
personal or subjective criteria.
> (2) Arguably, the pure nested syntax is not natural for human to read.
> Long time lispers may disagree on this point.
Harder to read for some things, easier to read for others.
E.G.
1 + 2 + 3 + 4 + 6 - 3 + 32
or
(- (+ 1 2 3 4 6 32) 3)
> (3) Most importantly, a pure nested syntax discourages frequent or
> advanced use of function sequencing or compositions. This aspect is
> the most devastating.
This is one reason LISP has macros. Don't like the syntax? Make your
own. How many languages make this as easy as LISP does?
> The third issue, about how nested syntax seriously discourages
> frequent or advanced use of inline function sequencing on the fly,
> is the most important and I'll give further explanation below.
>
> One practical way to see how this is so, is by considering unix's
> shell syntax. You all know, how convenient and powerful is the
> unix's pipes. Here are some practical example: “ls -al | grep xyz”,
> or “cat a b c | grep xyz | sort | uniq”.
>
> Now suppose, we get rid of the unix's pipe notation, instead,
> replace it with a pure functional notation: e.g. (uniq (sort (grep
> xyz (cat a b c)))), or enrich it with a composition function and a
> pure function construct (λ), so this example can be written as:
> ((compose (lambda (x) (grep xyz x)) sort uniq) (cat a b c)).
(pipe (cat a b c) (grep xyz) (sort) (uniq))
'Nuff said.
UNIX pipe `|' is not just a throw-away syntactic separator, anyone
with LISP experience would see it for what it is: a function that
operates on functions.
> Lisp, by sticking with almost uniform nested parenthesis notation,
> it immediately reduces the pattern of sequencing functions, simply
> because the syntax does not readily...<snip>
I would contend that LISP did not do this. You did.
<snip>
> (Note: Lisp's sexp is actually not that pure. It has ad hoc syntax
> equivalents such as the “quote” construct “ '(a b c) ”, and also
> “`”, “#”, “,@” constructs, precisely for the purpose of reducing
> parenthesis and increasing readability. Scheme's coming standard the
> R6RS ↗, even proposes the introduction of [] and {} and few other
> syntax sugars to break the uniformity of nested parenthesis for
> legibility. Mathematica's FullForm, is actually a pure nested
> notation as can be.)
Some functions are used so often, they have shorthand equivalents.
This is a feature in many languages. But if for some reason one
wanted the sexp to be "pure," nothing's stopping him from using the
fully-parenthesized versions.
> -------
> The above, is part of a 3-part exposition:
> “The Concepts and Confusions of Prefix, Infix, Postfix and Fully
> Functional Notations”,
> “Prefix, Infix, Postfix notations in Mathematica”,
> “How Lisp's Nested Notation Limits The Language's Utility”,
> archived at:
> http://xahlee.org/UnixResource_dir/writ/notations.html
>
> Xah
> x...@xahlee.org
> ∑ http://xahlee.org/
>
I suggest you start to acquaint yourself with LISP before getting too
far into the exposition:
--
Edward
fireblade
> (o o)
> |~~~~ooO~~(_)~~~~~~~|
> | Please |
> | don't feed the |
> | TROLL! |
> '~~~~~~~~~~~~~~Ooo~~'
> |__|__|
> || ||
> ooO Ooo
>
Xah Lee
«(1) Some 99% of programers are not used to the nested parenthesis
syntax. This is a practical problem. On this aspect along, lisp's
Ken Tilton wrote:
«Simply wrong. What would be a problem would be if they tried it and
could not quickly get used to it.»
I think what you said is part of what i said. But let me elaborate.
Lisp's nested parenthesis certainly is a problem, if you want to
attract programers to lisp and programers are not attracted by sexp in
the first place.
What you expressed, is to consider the question of whether people can
get used to sexp. If programers cannot adapt sexp and find it
comfortable as a syntax of a programing language, then, you consider
THAT, to be a problem of the lisp syntax. Otherwise no problemo.
I think you vantage point is not so goody. But if we consider the
question itself, i think yes, people can adapt and use sexp reasonable
well for programing. Actually, this has been already done i guess by
lispers for 40+ years right? But if we really focus on this point of
view, namely: whether sexp can be suitable as a syntax for computing
language. Then, that is rather not a interesting question i thinky.
Because, in general, people can adapt to all kind of wierd shits,
really depending how pressing the matter is. If it is life
threatening, or they have no other choice, human animals can adapt.
Imagine, compare, the technology today are far advanced than 40 years
ago. Computers are what? a thousand, ten thousand times faster? And
there's no Perl, Python, Java, Internet 40 years ago. But People went
to the Moon! Imagine, what kind of torturous pain these people have
to go thru in software and hardware or the computation of mathematics
to do this. BASIC with GOTO and FORTRAN? What? no structured
constructs? No code blocks? No libraries? No symbols? No macros? Not
even Eval()? No USB and DVDs but punchcards?
You know about Chinese characters right? To a European, Chinese
characters looks torturous. But in fact it is. Just consider the
number of strokes. But i think Chinese people of 13 billion are
surviving.
Sure. I certainly agree human animals can get used to sexp. Under
some conditions, human animals can get used to a lot of things, and
loving it too.
See:
• “Body and Mind Modification”
http://xahlee.org/Periodic_dosage_dir/20031129_body_mod.html
• “Difficulty Perceptions in Human Feats”
http://xahlee.org/vofli_bolci/juggling.html
The interesting question would be, to what degree of botchedness of
computer language syntax can be, until programers will not be able to
adapt it and code it fruitfully? Suppose, for each paren in lisp, we
double it. So, “(+ 3 4)” will be written as “((+ 3 4))”. And suppose
we force this to be the new syntax for lisp. I will bet you one
hundred bucks, that all lispers will find in exactly as easy to read
as before.
How many level of parens do you think we can add till all lispers
abandon ship?
How many?
----------------------------
Xah Lee wrote:
«(2) Arguably, the pure nested syntax is not natural for human to
read. Long time lispers may disagree on this point.»
Kenny wrote:
«No code is natural to read, and yes, I have written a ton of COBOL.
Neither are legal or scholarly natural language texts natural to
read.»
Huh? surely you agree that there is at least some qualification as to
some written language being more natural or easier to read?
For example, compare language A and B, where A is just lisp's sexp,
and B is sexp with every paren replaced by double parens. Now, which
is more “natural” or easy to read?
So, likewise, compare Perl and Python. Which is easier to read in
general? You can't wax philosophy on this can you?
Imagine a philosophical scenario, where a devil killed off all
pythoners on earth. Therefore perl code is easier to read, because
nobody would understand a fuck when shown a python code. So, the
question of whether Perl or Python code is easier to read, depends.
Also, i mean, it depends on the programer!! Because, if i write Perl
code versus a moron writing in Python, then my Perl code will sure be
easier to read. So, it also depends on me.
What a great tough undecidability!
----------------------------
Xah Wrote:
«(3) Most importantly, a pure nested syntax discourages frequent or
advanced use of function sequencing or compositions. This aspect is
the most devastating.»
Kenny wrote:
«The example you chose was a command line, where conciseness rules and
where one is not likely to encounter refactoring or macros. ie, the
syntax for a command-line has nothing to do with the syntax for
serious programming.»
Yes the example i gave was unix's shell. It is chosen because it is
simple to illustrate and widely known.
I could give Mathematica examples with explanations... but its not
suitable as the simple unix pipe example because then i'll have to
spend great space explaining Mathematica.
(if anyone is interested in Mathematica syntax, i explained some here
http://xahlee.org/UnixResource_dir/writ/notations.html
)
But anyway, here's a few mathematica example from my Plane Tiling
package.
Here's one line that's the most simple to understand:
Reflect2DGraphics[{a1_, a2_}, {n1_, n2_}][gra_] :=
(Translate2DGraphics[{n1, n2}])@
(Reflect2DGraphics[{a1,a2}])@
(Translate2DGraphics[-{n1, n2}][gra]);
Basically, you'll see on the right side are 3 sequence of functions.
The left side is a function applied to a function. i.e.
Reflect2DGraphics takes 2 vectors and “returns” a function that takes
one graphics argument. (it doesn't actually return a function since
it's written as pattern matching... but you can think of it as a
function generator)
Here's the lispy form some lisper believe is easier to read:
CompoundExpression[
SetDelayed[
Reflect2DGraphics[List[Pattern[a1, Blank[]], Pattern[a2,
Blank[]]],
List[Pattern[n1, Blank[]], Pattern[n2, Blank[]]]][
Pattern[gra, Blank[]]],
Translate2DGraphics[List[n1, n2]][
Reflect2DGraphics[List[a1, a2]][
Translate2DGraphics[Times[-1, List[n1, n2]]][gra]]]], Null]
The following are more code. They involve pure functions, function
application, function mapping, function generator applied to
functions... and basically all done with flat sequencing of functions
when possible. (aka function chaining sans nesting). Whenever you see
the ampersand sign &, its a pure function (aka lambda). Some pure
function has pure function as its innards.
These are written in 1997, by yours truely. I would say, if you have
not been coding lisp or Mathematica for, say, 40 hours a week for 4
years, you wouldn't understand these code when explained. (not
considering the math it is doing)
Okie, here's a good one. Lots of sequencing of pure functions on the
fly:
cycledMatrix[{m_Integer, n_Integer}, cycleLists : {_List ..}] :=
Module[{}, (Flatten[({Table[#1, {Quotient[#2, #3]}],
Take[#1, Mod[#2, #3]]} &) @@ ({#, m,
Length@#} &)@#] &) /@
Flatten[(({(Flatten[#, 1] &)@Table[#1, {Quotient[#2, #3]}],
Take[#1, Mod[#2, #3]]} &) @@ ({#, n, Length@#} &)@
cycleLists), 1]];
Btw, the “f@@g” you see is shortcut syntax for “Apply[f,g]”.
Here's the equivalent lispy form, lispers think its easier to read:
CompoundExpression[
SetDelayed[
cycledMatrix[
List[Pattern[m, Blank[Integer]], Pattern[n, Blank[Integer]]],
Pattern[cycleLists, List[Repeated[Blank[List]]]]],
Module[List[],
Map[Function[
Flatten[Apply[
Function[
List[Table[Slot[1], List[Quotient[Slot[2],
Slot[3]]]],
Take[Slot[1], Mod[Slot[2], Slot[3]]]]],
Function[List[Slot[1], m, Length[Slot[1]]]]
[Slot[1]]]]],
Flatten[Apply[
Function[
List[Function[Flatten[Slot[1], 1]][
Table[Slot[1], List[Quotient[Slot[2],
Slot[3]]]]],
Take[Slot[1], Mod[Slot[2], Slot[3]]]]],
Function[List[Slot[1], n, Length[Slot[1]]]]
[cycleLists]], 1]]]],
Null]
----------------------------------------
Okie, another one, wee!
ColoredLatticeNetwork[n:(4 | 3), m_Integer,
colors:{_List..}, s_, a_, {x_, y_}] :=
Module[{lines, gp}, lines = (Map[Line, #1, {2}] & )[
(Partition[#1, 2, 1] & ) /@
N[Table[{1, 0}*s*i + ({Cos[#1], Sin[#1]} & )[
(2*Pi)/n]*s*j, {j, -m, m}, {i, -m, m}]]];
gp = (Transpose[#1, {3, 1, 2}] & )[
{cycledMatrix[{m*2, m*2 + 1}, (RotateRight[#1, m] & )[
(RotateRight[#1, m] & ) /@ colors]], lines}];
Translate2DGraphics[{x, y}][
Table[Rotate2DGraphics[{0, 0}, ((2*Pi)*i)/n + a][
gp], {i, 0, n - 1}]]];
Here's the equivalent lispy form lisp morons insist it is easier to
read:
CompoundExpression[
SetDelayed[
ColoredLatticeNetwork[Pattern[n, Alternatives[4, 3]],
Pattern[m, Blank[Integer]],
Pattern[colors, List[Repeated[Blank[List]]]], Pattern[s,
Blank[]],
Pattern[a, Blank[]], List[Pattern[x, Blank[]], Pattern[y,
Blank[]]]],
Module[List[lines, gp],
CompoundExpression[
Set[lines,
Function[Map[Line, Slot[1], List[2]]][
Map[Function[Partition[Slot[1], 2, 1]],
N[Table[
Plus[Times[List[1, 0], s, i],
Times[Function[List[Cos[Slot[1]], Sin[Slot[1]]]]
[
Times[Times[2, Pi], Power[n, -1]]], s, j]],
List[j, Times[-1, m], m], List[i, Times[-1, m],
m]]]]]],
Set[gp, Function[Transpose[Slot[1], List[3, 1, 2]]][
List[cycledMatrix[List[Times[m, 2], Plus[Times[m, 2],
1]],
Function[RotateRight[Slot[1], m]][
Map[Function[RotateRight[Slot[1], m]], colors]]],
lines]]],
Translate2DGraphics[List[x, y]][
Table[Rotate2DGraphics[List[0, 0],
Plus[Times[Times[Times[2, Pi], i], Power[n, -1]], a]]
[gp],
List[i, 0, Plus[n, -1]]]]]]], Null]
--------------------------------
Okie, this one is a simple one.
StarMotif[n_Integer, coords_?MatrixQ, s_, α_, {x_, y_}] :=
Polygon@(Flatten[#, 1] &)@
Transpose@
Map[Table[{Cos[t + Last@#], Sin[t + Last@#]}*First[#]*s +
{x,
y}, {t, α, 2*Pi + α - 2*Pi/n/2, 2*Pi/n}] &,
coords];
Now, the easier-to-read lisp form follows:
CompoundExpression[
SetDelayed[
StarMotif[Pattern[n, Blank[Integer]],
PatternTest[Pattern[coords, Blank[]], MatrixQ], Pattern[s,
Blank[]],
Pattern[α, Blank[]],
List[Pattern[x, Blank[]], Pattern[y, Blank[]]]],
Polygon[Function[Flatten[Slot[1], 1]][
Transpose[
Map[Function[
Table[Plus[
Times[List[Cos[Plus[t, Last[Slot[1]]]],
Sin[Plus[t, Last[Slot[1]]]]], First[Slot[1]],
s],
List[x, y]],
List[t, α,
Plus[Times[2, Pi], α,
Times[-1,
Times[2,
Times[Times[Pi, Power[n, -1]], Power[2,
-1]]]]],
Times[2, Times[Pi, Power[n, -1]]]]]], coords]]]]],
Null]
--------------
This one is semantically and geometrically complex!
SlitLine[Line[pts_List /; (Length@pts > 2)], cuttingLine : {{_, _},
{_, _}}] :=
Module[{temp},
If[SameQ @@ (temp = PointOnLeftSideQ[#, cuttingLine] & /@ pts),
Return@List@Line@pts];
temp = MapThread[
And[#1, #2] &, {(UnsameQ @@ # &) /@
Partition[temp, 2,
1], (PointOnLeftSideQ[First@cuttingLine, #] =!=
PointOnLeftSideQ[Last@cuttingLine, #] &) /@
Partition[pts, 2, 1]}];
temp = Append[#, Null] &@
MapThread[
If[#2, 0@LineIntersectionPoint[#1, cuttingLine],
Null] &, {Partition[pts, 2, 1], temp}];
temp = (DeleteCases[#, Null, {1}] &)@Flatten[Transpose@{pts, temp},
1];
(Line /@
ReplaceRepeated[
List@temp, {a__, 0[pt_], b__} :> Sequence[{a, pt}, {pt,
b}]])]
Now, the spectacular lisp form:
SetDelayed[
SlitLine[Line[
Condition[Pattern[pts, Blank[List]], Greater[Length[pts],
2]]],
Pattern[cuttingLine,
List[List[Blank[], Blank[]], List[Blank[], Blank[]]]]],
Module[List[temp],
CompoundExpression[
If[Apply[SameQ,
Set[temp,
Map[Function[PointOnLeftSideQ[Slot[1], cuttingLine]],
pts]]],
Return[List[Line[pts]]]],
Set[temp,
MapThread[Function[And[Slot[1], Slot[2]]],
List[Map[Function[Apply[UnsameQ, Slot[1]]],
Partition[temp, 2, 1]],
Map[Function[
UnsameQ[PointOnLeftSideQ[First[cuttingLine],
Slot[1]],
PointOnLeftSideQ[Last[cuttingLine], Slot[1]]]],
Partition[pts, 2, 1]]]]],
Set[temp,
Function[Append[Slot[1], Null]][
MapThread[
Function[
If[Slot[2], 0[LineIntersectionPoint[Slot[1],
cuttingLine]],
Null]], List[Partition[pts, 2, 1], temp]]]],
Set[temp,
Function[DeleteCases[Slot[1], Null, List[1]]][
Flatten[Transpose[List[pts, temp]], 1]]],
Map[Line,
ReplaceRepeated[List[temp],
RuleDelayed[
List[Pattern[a, BlankSequence[]], 0[Pattern[pt,
Blank[]]],
Pattern[b, BlankSequence[]]],
Sequence[List[a, pt], List[pt, b]]]]]]]]
If you want to see more, you can download my package at
http://xahlee.org/MathGraphicsGallery_dir/PlaneTilingPackageDemo_dir/planeTilingPackageDemo.html
Free of charge.
Malcolm McLean
"Miles Bader" <mi...@gnu.org> wrote in message
news:873b2cx...@catnip.gol.com...
in both the good and the bad sense of the term, and rather eccentric.
--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm
Malcolm McLean
"Kaz Kylheku" <kkyl...@gmail.com> wrote in message
news:1178325041....@w5g2000hsg.googlegroups.com...
On May 4, 5:11 pm, Xah Lee <x...@xahlee.org> wrote:
>> How Lisp's Nested Notation Limits The Language's Utility
>> Long time lispers may disagree on this point.
>
>Programming language syntax shouldn't be natural for humans to read.
>Or, rather, this shouldn't be a requirement which creates technical
>compromises.
>
technical compromises whatsoever - pure assembly or machine code - but only
rarely. Most of the time we accept some limitations for the sake of making
things easier for the human programmer. That includes run-time efficiency,
but also restrictions in the "power" of the language.
You might be interested in the page 10 Rules of Computer Programming on my
website which deals with psychological issues in programming. Lisp breaks
the rule of three in spades.
Pascal Costanza
> How Lisp's Nested Notation Limits The Language's Utility
>
> Xah Lee, 2007-05-03
>
> There is a common complain by programers about lisp's notation, of
> nested parenthesis, being unnatural or difficult to read. Long time
> lisp programers, often counter, that it is a matter of conditioning,
> and or blaming the use of “inferior” text editors that are not
> designed to display nested notations. In the following, i describe how
> lisp notation is actually a problem, in several levels.
>
> (1) Some 99% of programers are not used to the nested parenthesis
> syntax. This is a practical problem. On this aspect along, lisp's
> syntax can be considered a problem.
Lisp doesn't have a problem here. Lisp is a programming language, an
inanimate, dispassionate, virtual concept which doesn't (cannot!) "care"
whether it is used at all.
Only people can have problems with something. For example, programmers
who want some of the cool features of Lisp but don't want to put up with
its syntax.
However, for decades, there have been programmers who have learned to
prefer Lisp's syntax over anything else. As long as they continue to
exist, Lisp dialects will continue to exist. Those people don't have a
problem - to the contrary.
Leave them alone - they are happy with their choice.
If you don't like Lisp, there are numerous attempts to copy its features
using other surface syntaxes. Just pick one.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Markus E Leypold
"Malcolm McLean" <regn...@btinternet.com> writes:
> "Miles Bader" <mi...@gnu.org> wrote in message
> news:873b2cx...@catnip.gol.com...
>> "Robert D. Crawford" <rd...@comcast.net> writes:
>>> If it is emacs that makes you happy, then change the things you don't
>>> like and be happy but I fail to see how your whining diatribes serve
>>> any useful purpose. If you don't like lisp then by all means use
>>> something else.
>>
>> Xahlee likes to complain. That's the main factor here.
>>
> There is thought and intelligence in his posts. However they are
> provocative in both the good and the bad sense of the term, and rather
Where is the good sense in there? We have (at c.l.f) people
complaining about parenthesis in lisp every 3 months and the arguments
never get any better or new. Rehashing all that once again doesn't
attest to "thought and intelligence" but rather to a trollish streak.
Regards -- Markus
Markus E Leypold
Rayiner Hashem <ray...@gmail.com> writes:
>> (1) Some 99% of programers are not used to the nested parenthesis
>> syntax. This is a practical problem. On this aspect along, lisp's
>> syntax can be considered a problem.
>
> The first time I saw graph-theory notation, I thought it was
> gibberish. I still think most mathematical notation is gibberish, but
> I deal with it --- I don't turn in proofs written in prose.
Right.
>
>> (2) Arguably, the pure nested syntax is not natural for human to read.
And BTW, it's not natural for humans to read at all.
:-)
>> Long time lispers may disagree on this point.
>
> And mathematical notation is not natural for people to read, at least
> not anybody who grew up learning a natural language. But people deal
> with it. They're remarkably adaptable this way.
Regards -- Markus
Miles Bader
<development-2006-8...@ANDTHATm-e-leypold.de> writes:
> Where is the good sense in there? We have (at c.l.f) people
> complaining about parenthesis in lisp every 3 months and the arguments
> never get any better or new. Rehashing all that once again doesn't
> attest to "thought and intelligence" but rather to a trollish streak.
Indeed, and people have been saying what Xahlee's saying since the
_1950s_! Lisp still has the parens, and there are good reasons for that.
-Miles
--
[|nurgle|] ddt- demonic? so quake will have an evil kinda setting? one that
will make every christian in the world foamm at the mouth?
[iddt] nurg, that's the goal
Miles Bader
> You might be interested in the page 10 Rules of Computer Programming on
> my website which deals with psychological issues in programming. Lisp
> breaks the rule of three in spades.
That suggests that the "rule of three" is wrong...
-Miles
--
o The existentialist, not having a pillow, goes everywhere with the book by
Sullivan, _I am going to spit on your graves_.
Markus E Leypold
"Malcolm McLean" <regn...@btinternet.com> writes:
> You might be interested in the page 10 Rules of Computer Programming
> on my website which deals with psychological issues in
> programming. Lisp breaks the rule of three in spades.
Rule three is about indirection, not about nesting. The other rules
suck also. If your "Refutation of Common Atheist Arguments" have a
similar quality, the atheists will have a field day.
Regards -- Markus
Anton van Straaten
Perhaps it's not a coincidence that these two seemingly unrelated
arguments are offered by the same person. Both religious belief and a
belief in the essential importance of syntactic sugar require abandoning
Occam's Razor.
Anton
Xah Lee
Xah Lee wrote:
« (1) Some 99% of programers are not used to the nested parenthesis
syntax. This is a practical problem. On this aspect along, lisp's
syntax can be considered a problem.»
Pascal Costanza wrote:
«Lisp doesn't have a problem here. Lisp is a programming language, an
inanimate, dispassionate, virtual concept which doesn't (cannot!)
"care" whether it is used at all. Only people can have problems with
something. For example, programmers who want some of the cool features
of Lisp but don't want to put up with its syntax. »
You are actually wrong here, because, people can't have a problem.
People are animals, made of meat. They can have a problem when, they
get sick, and their body will disfunction or function abnormally. So,
for example, even sexp has all the problems, lisp morons are still
fine.
Pascal fuckhead wrote:
«However, for decades, there have been programmers who have learned to
prefer Lisp's syntax over anything else. As long as they continue to
exist, Lisp dialects will continue to exist. Those people don't have a
problem - to the contrary.»
existence?
my god... you are quite desperate.
In this thread, a few people already started to post completely off
topic, brainless, pure personal attacks. I think you are still good.
Sometimes i have a problem telling, of those who post brainless things
to my articles, whether they are joking with wanton carelessness, or
if their critical thinking abilities is really that low.
For example, your reply is a good example. I wasn't sure, if you are
just fucking with me, or really, really meant your writing as a valid
argument to my thesis. In this thread, Ken Tilton, also wrote
something that's incredibly stupid. In fact, more or less repeating
what i said, just with antagonism and explicit denial. I take it, that
he acted that way probably because my essay is so cogent and powerful
that it hit a nerve and paralyzed his reasoning faculties and numbed
his nonchalant quip Muse.
There are some others in this thread, which are so hateful, fucking
full of the ugliness of humanity. The replies from Markus E Leypold is
a prime example. I wonder, outside of newsgroups, if he is just a
sophomoron at college.
Other posts in this thread, some sincere ones, are full utterly
fucking stupid drivels. (or i shall put the polite version: logical
fallacies) The level is so low that i'm really ashamed that they
really came out from the mouthes of a class of people in society who's
jobs are to program computers.
(in this regard, see:
The Condition of Industrial Programers
http://xahlee.org/UnixResource_dir/writ/it_programers.html
)
For example, there's this gem: «Programming language syntax shouldn't
be natural for humans to read. Or, rather, this shouldn't be a
requirement which creates technical compromises.»
I think this quote or the concept of it has been around for a while.
If you take it seriously, it's full of MOTHERFUCKING nonsensical,
meaningless, shit. It amounts to a sound bite. Behind it, it wants to
make programers, in particular the elite programers like the lisp
fuckers, to think something along the line: “my syntax is so bizarre
because i'm superior”.
I guess it's lisper's version of “The three chief virtues of a
programmer are: Laziness, Impatience and Hubris”.
Pascal Costanza moron wrote:
«Leave them alone - they are happy with their choice. »
«If you don't like Lisp, there are numerous attempts to copy its
features
using other surface syntaxes. Just pick one. »
Try, perhaps, learn to calm down yourself. You are not under attack.
Lisp the language, is not under attack by my essay. My article,
although cogently detailed why lisp syntax is a serious problem at
several levels, it does not mean that, it is “no good” in some
absolute way. Also, it is far better, then essentially all imperative
language's syntaxes. Even, one can logically agree with my article,
and remain positive, because although lisp perhaps reduce the use of
function sequencing, but that by itself is not necessarily a very bad
thing. Because, function sequencing (aka chaining), although a very
important paradigm, is not necessarily the only way to program, nor
the only way for functional programing. Consider, even today in the
light of OOP. And Common Lisp, in particular, isn't all that much
concerned about purity of functional programing anyway. So logically,
from this perspective or argument, my essay isn't a damning
certificate.
I'm really sorry i have to say the above paragraph, as if like a pat
on the back to some crying pussies. But the juvenility, sensitivity,
ignorance, and stupidity, as shown in the responses in this thread,
made me.
I was hoping, perhaps due to my clear exposition of the sexp problem
for perhaps the first time, that we could move on to other fruitful
discussions, not necessarily agree that it is a problem. For example,
LOGO, DyLan, Arc all abandoned the nested fuck. I mean, lispers may
disagree, but the people behind these LISP languages are not brainless
fuckheads, are they? Alternatively, i was hoping, perhaps there will
be fruitful discussions in the direction of technical issues of
transforming syntax. i.e. of Mathematica's f[a,b] and lisp's (f a b).
Or, perhaps some technically knowledgable people here (there are many)
can by ways of chat, impart some insight about some technical
connections between syntaxes and semantic (apart from myself). For
example, DyLan i believe once was believed to have have sexp
underneath. If so, that would be interesting because it gives us a
actual, existing, example of a lang with sexp underneath alternative
to Mathematica's ways. But also, lisp can actually relatively easily,
create a layer of syntax on top of sexp...
Really, you people need to learn. Be calm. Keep your mind open. I'm
not attacking you or attacking lisp. If there's any attacking, it is
your immature and unhealthy nerve.
PS By the way, i also responded a article recently about why Perl and
Python programers today should learn lisp.
(
“Why learn lisp when there are python and perl?”, Xah Lee, 2007-05-03.
http://xahlee.org/UnixResource_dir/writ/wl_lisp.html
)
Can a lisper write a open letter thanking me for that please?
Tim Bradshaw
> How Lisp's Nested Notation Limits The Language's Utility
Very good. Now, off you go and design and implement an alternative
syntax. It's easy, it's been done hundreds of times. I think I have
two or three limited examples on my web site and several more I never
bothered publishing. There must, as I say, be hundreds of examples
around and probably thousands when you count all the non-published
ones. So pick the best and use them, or, since you're by far the
smartest person here, why not come up with your own? Jon Harrop can
probably help you.
Mark Tarver
if you make a critical analysis of Lisp and people attack *you*. This
is called an ad hominem argument, and, sadly, they are all too common
on usenet. But calling people names like 'moron' is not the right
way to win hearts and minds. You say some interesting things but you
play into the hands of your critics by launching personal attacks.
Now you will probably get a load more posts attacking your bad manners
and so your original points are lost in the scrum and people write you
off as a troll.
Be cool and if you do think someone is using ad hominem arguments;
tersely point it out and return to the main points. Don't get
abusive.
Mark
> The Condition of Industrial Programershttp://xahlee.org/UnixResource_dir/writ/it_programers.html
Malcolm McLean
"Anton van Straaten" <an...@appsolutions.com> wrote in message
news:WI1%h.2620$RX....@newssvr11.news.prodigy.net...
reasons, without irritating a lot of Lispers.
A programming language is inherently a compromise between the needs of the
human programmer and the needs of the computer. That's why the 10 rules of
computer programming are all psychological rules. There are many other
things you need to know to program a computer, but they are documented with
the system. The difference is, if you break a psychological rule then the
program still works, but it is too difficult to maintain.
The rules are also ones which people might be tempted to break - obviously
writing code with no comments and one letter identifiers is a bad idea, but
people don't need to be told that, so it's not a rule.
The rule of three was written before I was familiar with Lisp, and so you
might say that Lisp is a counter-example. I don't think it is, because the
first thing that everyone says about Lisp is "I can't do with all those
parentheses". In fact Lisp programmers use indentation to try to impose
another hierarchy of structure on the program, something they wouldn't need
to do if humans could glance at a long expression and match up parentheses.
Malcolm McLean
"Xah Lee" <x...@xahlee.org> wrote in message
news:1178380349.8...@l77g2000hsb.googlegroups.com...
>For example, there's this gem: «Programming language syntax shouldn't
>be natural for humans to read. Or, rather, this shouldn't be a
>requirement which creates technical compromises.»
>I think this quote or the concept of it has been around for a while.
>If you take it seriously, it's full of --------- nonsensical,
>meaningless, ----. It amounts to a sound bite. Behind it, it wants to
>make programers, in particular the elite programers like the lisp
>-----, to think something along the line: “my syntax is so bizarre
>because i'm superior”.
>
Now I also disagreed with Kaz on that one. Compare my post with yours. and
consider why I had to delete some many words in quoting you. Who do you
think is more likely to convince Mr Kylheku that he is in error?
Xah Lee
«I think *you* need to cool down Xah Lee. I agree it can be annoying
if you make a critical analysis of Lisp and people attack *you*. This
is called an ad hominem argument, and, sadly, they are all too common
on usenet. ...»
«But calling people names like 'moron' is not the right way to win
hearts and minds....»
Exactly. I've been using online forums since 1990. I've been using
newsgroups since maybe 1994. If i wanted to play politics, given my IQ
and my knowledge of computing, and great skill of composition, i might
be a fucknig George Bush by now, with a massive army of morons at my
commands, not like, the likes of some computing industry leaders.
Understand, politness, is a intrinsic element of politics. (and
politics, means power-struggle) Politness arose from the existance of
hostility and aggression. Without aggression, there is no politness.
One easy way to see this, is notice how the behavior of politeness is
inversly proportional to how close are the parties involved. There
will be little politness, between your sisters, wives, or parents.
There will be a huge politeness, when big stakes are involved between
unbound human animals.
The computing newsgroups, made of males, have been brawling just about
when it begin. Your few words on politness and lecturing, is one
additional off-topic drivel in its history. (though, i appreciate your
kindness and your knowledge)
In this thread, i did not start four-letter words before NUMEROUS
fuckheads began sprouting purely unreasonable, totally off-topic,
personal attacks on me in a way more serious than name calling.
(because, it smacks of witch-hunting) (they naturally did this,
because they perceived that i “attacked” their computer language. This
is because, the computing language newsgroup tech geekers are utterly
ignorant of sociology, and combined with male power struggling
instict, have habored the thought about “trolling”, and some ethical
ideas about what one can or cannot say about other's computer
languages. Utterly bizarre.)
This doesn't happen to just me. It just a normal day in newsgroups.
Whoever, may it be professor, or eminent mathematician, professinoal
senior programers (as many are here), as long as he is a long time
newsgroup user, may have involved in verbal abuses given or taken.
(and each party are fully aware the other's social standings, but it
does'n matter. (e.g. in this very thread, a few started to gang up on
Jon Harrop, who is a author of a few functional language books)) It
is, the culture of newsgroups, so to speak. In a way, it is how people
WANT newsgroups to be the way it is. You knew it, i knew it, and we
should not deny it. If you are concerned about this state of affairs
of newsgroups, you need to rethink about it. Not the same old
instinctive good intentions. George motherfucking Bush has good
intentions and 50k to 300k Islamic civilians are dead. I'm sure you
are a kind man. Thousands of kind men existed in newsgroups before
you. They all have, at one time or another or more, given kind
advices, and contributed to what newsgroup is today.
I recommend a few articles. These articles, if tech geekrs all read
it, will help improve the state of affairs of newsgroups.
• What Desires are Politically Important? by Bertrand Russell
http://xahlee.org/Periodic_dosage_dir/_p2/russell-lecture.html
• Demonic Males. Apes and the Origins of Human Violence.
By Richard Wrangham and Dale Peterson
http://xahlee.org/p/demonic_males.html
Nice meeting you.
Jon Harrop
> Leave them alone - they are happy with their choice.
No. No, they aren't. The Lisp community are actually more interested in
other languages than almost all other programming language communities.
This is why I continue to post in c.l.l, because it garners a lot of
interest in my work from the many Lisp users who are still looking for
something better.
David Kastrup
> I think *you* need to cool down Xah Lee. I agree it can be annoying
> if you make a critical analysis of Lisp and people attack *you*.
> This is called an ad hominem argument, and, sadly, they are all too
> common on usenet. But calling people names like 'moron' is not the
> right way to win hearts and minds. You say some interesting things
> but you play into the hands of your critics by launching personal
> attacks.
"play" is actually not the four-letter word I would have used here.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
andrew...@gmail.com
> Other posts in this thread, some sincere ones, are full utterly
> fucking stupid drivels. (or i shall put the polite version: logical
> fallacies) The level is so low that i'm really ashamed that they
> really came out from the mouthes of a class of people in society who's
> jobs are to program computers.
>
> (in this regard, see:
> The Condition of Industrial Programershttp://xahlee.org/UnixResource_dir/writ/it_programers.html
> )
>
When Xah Lee cites to his website, it reminds me of Ignatius J. Reilly
citing his own work in Toole's "A Confederacy of Dunces:"
--- excerpt ---
The humble and pious peasant, Piers Plowman, went to town to sell his
children to the lords of the New Order for purposes that we may call
questionable at best. (See Reilly, Ignatius J., _Blood on Their
Hands: The Crime of It All, A study of some selected abuses in
sixteenth-century Europe_, a Monograph, 2 pages, 1950, Rare Book Room,
Left Corridor, Third Floor, Howard-Tilton Memorial Library, Tulane
University, New Orleans 18, Louisiana. Note: I mailed this singular
monograph to the library as a gift; however, I am not really certain
that it was ever accepted. It may well have been thrown out because
it was only written in pencil on tablet paper.)
--- end excerpt --
Ken, are you related to the Tilton who founded the library
mentioned?
Interestingly enough, Ignatius J. Reilly clearly was not put off by
parentheses, as he nests them throughout his writings. This is one
reason I recommend "A Confederacy of Dunces" to people learning Lisp,
though I still feel Practical Common Lisp is the best for total
newbies.
OK, sorry to distract from the main line here.
Best,
Andrew
Tim X
Actually, I think this is a very good idea for Xah. Many have been very
critical of what he posts (including myself), but I suspect a large percentage
of people totally dismiss what he writes because he doesn't provide any
constructive alternatives. He regularly posts about what is wrong with emacs,
lisp, unix, perl etc. but rarely do I see any proposed solutions or
constructive ideas that might actually improve the situation.
come on Xah, you have made frequent references to your superior IQ, your
ability to write and express ideas. Its easy to moan about whats wrong with the
world, time to put your money where your mouth is. Take some of that boundless
IQ and your superior skills in communication and post some ideas on how things
could be improved.
Tim
--
tcross (at) rapttech dot com dot au
Tim Bradshaw
> Take some of that boundless
> IQ and your superior skills in communication and post some ideas on how things
> could be improved.
Don't post ideas, post implementations. It really is very easy to
implement new syntaxes for Lisp.
Jon Harrop
The problem isn't creating a syntax (all decent PLs have good syntax). The
problem is that CL doesn't bundle a decent syntax (or pattern matching,
or ...). So there's no point in Xah implementing anything.
Arved Sandstrom
news:TNOdnQlUpMyFqqHb...@bt.com...
>
> "Kaz Kylheku" <kkyl...@gmail.com> wrote in message
> news:1178325041....@w5g2000hsg.googlegroups.com...
> On May 4, 5:11 pm, Xah Lee <x...@xahlee.org> wrote:
>>> How Lisp's Nested Notation Limits The Language's Utility
>>> (2) Arguably, the pure nested syntax is not natural for human to read.
>>> Long time lispers may disagree on this point.
>>
>>Programming language syntax shouldn't be natural for humans to read.
>>Or, rather, this shouldn't be a requirement which creates technical
>>compromises.
>>
> I couldn't disagree more. Occasionally you do need to use a language with
> no technical compromises whatsoever - pure assembly or machine code - but
> only rarely. Most of the time we accept some limitations for the sake of
> making things easier for the human programmer. That includes run-time
> efficiency, but also restrictions in the "power" of the language.
You two are not referring to the same thing. Syntax is not related to the
power of a language (or the lack thereof) in the slightest. Plenty of
languages that operate at higher levels than machine code or assembler are
just as terse and non-intelligible to the uninformed. Kaz simply made a
reference to syntax.
AHS
Malcolm McLean
"Arved Sandstrom" <asand...@accesswave.ca> wrote in message
news:z4o%h.5219$Vi6.3376@edtnps82...
nonsense, because syntax is simply the convention for noting the grammar.
For instance we could use "begin" and "end" instead of '(' and ')' to open
and close lists, without changing anything fundamental about the language,
but it wouldn't be a good idea because it would be totally unreadable. A
change in syntax inherently can't create technical compromises, unless I
suppose you demand a symbol like $ which might not be available on some
machines.
If we use it in the broader sense then we've got something to argue about.
Let's say that we agree that add(1, 2, 3) is easier to read than (add 1 2
3), and we change the underlying representation so that "function calls" are
separate from "lists". Now we've made the language less tidy at the machine
level, but we've also given an advantage to the human programmer. There is
no easy or "right" answer to these questions. My own programming language,
MiniBasic (see website) makes huge technical compromises, such as having
only one numerical type, to make the language easier to learn, because that
is the priority.
Joe Marshall
> How Lisp's Nested Notation Limits The Language's Utility
>
>
> There is a common complain by programers about lisp's notation, of
> nested parenthesis, being unnatural or difficult to read. Long time
> lisp programers, often counter, that it is a matter of conditioning,
> and or blaming the use of "inferior" text editors that are not
> designed to display nested notations. In the following, i describe how
> lisp notation is actually a problem, in several levels.
I think you're wrong, Xah. If the syntax is a problem, why haven't
any alternative syntaxes taken over for s-expressions? I point to
these examples:
M-Expressions (c. 1962)
maplist[x;fn]=[null[x]->NIL;
T->cons [fn[x];maplist [cdr [x];fn]]]
CGOL (c. 1977)
define "CGMAP"(x, inon, disp, typ);
if atom car x or caar x not isin !'(quote function)
or if atom cadar x then typ ne "mapcar" else caadar x ne "LAMBDA"
then (princ typ; let lbd=0, rbd=0; cglist(x, ", ", 0, 0))
else if atom cadar x and typ = "mapcar" then
(cgolprin2(cadar x, lbd, rbd, depth);
princ "["; let lbd=-1, rbd=0;
cglist(cdr x, ", ", 0, 0);
princ "]")
else (printeol;
princ "for ";
for vars on cadr cadar x, argts on cdr x do
(lcprinc car vars;
princ inon;
cgolprin2(car argts, 2, 0, depth+1);
if cdr vars then princ ", ");
princ disp;
let depth = depth+1; printeol;
cglist(cddr cadar x, "; ", 1, 0)) $
Dylan (c. 1990)
define function find-position-and-velocity
(rock :: <rock>, time :: <float>)
=> (position :: <float>, velocity :: <float>)
values(-4.9 * time * time
+ rock.initial-velocity * time
+ rock.initial-position,
-9.8 * time
+ rock.initial-velocity);
end function;
Curl (late 1990s)
{method public {set-size layout:LayoutContext, rect:GRect}:void
{super.set-size layout, rect}
|| match pixmap size with display
let width:int = ((rect.lextent + rect.rextent) / pixel-length) asa
int
let height:int = ((rect.ascent + rect.descent) / pixel-length) asa
int
set self.current-pixmap = {Pixmap width, height, ignore-alpha?
=true}
{self.on-resample}
}
Every year someone comes on comp.lang.lisp and informs us
that it is the parenthesis that are the problem. But in more than
forty years no one has come up with a better alternative, and
it hasn't been for want of trying or lack of imagination.
Jon Harrop
> I think you're wrong, Xah. If the syntax is a problem, why haven't
> any alternative syntaxes taken over for s-expressions?
They have.
Mathematica uses more conventional syntax to handle expressions:
map[{}, _] := {}
map[{h_, t___}, f_] := Prepend[map[{t}, f], f[h]]
or using the built-in map:
f /@ x
For example, squaring the terms of a sum:
In:= #^2& /@ (1 + 3 x + x y)
Out= 1 + 9 x^2 + x^2 y^2
As Xah explained, Mathematica gives you the choice between prefix format
(same properties as Lisp's s-exprs) or more sophisticated syntax. The
latter is far more popular.
OCaml allows you to define infix operators and these can be used to compose
expressions. From the symbolic simplifier example I gave:
let rec ( +: ) f g = match f, g with
| `Q n, `Q m -> `Q (n +/ m)
| `Q (Int 0), e | e, `Q (Int 0) -> e
| f, `Add(g, h) -> f +: g +: h
| f, g -> `Add(f, g)
let rec ( *: ) f g = match f, g with
| `Q n, `Q m -> `Q (n */ m)
| `Q (Int 0), e | e, `Q (Int 0) -> `Q (Int 0)
| `Q (Int 1), e | e, `Q (Int 1) -> e
| f, `Mul(g, h) -> f *: g *: h
| f, g -> `Mul(f, g)
Note that I chose to use infix operators +: and *: to compose expressions. I
could have used prefix syntax but conventional syntax is clearer.
One of the advances made by the F# language (derived from OCaml) is that it
allows operator overloading, so you can use + rather than +: to compose
expressions.
OCaml, MetaOCaml and F# provide quotations, allowing you to generate
expressions from quoted source code.
However, you cannot decompose expressions using a nice syntax:
let rec d f x = match f with
| f + g -> d f x + d g x
| f * g -> f * d g x + g * d f x
| ...
so you must write a macro to extend the pattern matcher in OCaml.
In the future, F# may support overloading infix active patterns (views)
which will provide this functionality from the language itself.
So I think it is fair to say that s-exprs in Lisp have been superceded by
more efficient representations of expressions in most modern FPLs.
Kaz Kylheku
> Free games and programming goodies.http://www.personal.leeds.ac.uk/~bgy1mm
Nutjob.
Malcolm McLean
>
> Every year someone comes on comp.lang.lisp and informs us
> that it is the parenthesis that are the problem. But in more than
> forty years no one has come up with a better alternative, and
> it hasn't been for want of trying or lack of imagination.
>
parentheses are a minor matter used to disambiguate short expressions. So
the first thing you say on seeing a Lisp program is "eek".
The second thing I said was "why not write a graphical editor for this, to
show the lists as trees?".
However I haven't written enough Lisp to comment on how best to work with
it.
Tim Bradshaw
> The problem isn't creating a syntax (all decent PLs have good syntax). The
> problem is that CL doesn't bundle a decent syntax (or pattern matching,
> or ...). So there's no point in Xah implementing anything.
As I mentioned in another article, I really think you do need to learn
about this internet thing. One of the nice features it offers is
something called "downloading" - people can write code which you can
then "download" onto your own computer and run there. It's just
amazingly better than the whole shipping magtapes around thing.
Xah Lee
«I think you're wrong, Xah. If the syntax is a problem, why haven't
any alternative syntaxes taken over for s-expressions? I point to
these examples:»
Do you know how fanatics are blind?
For example, there are Christians, and there are Islamics. Doesn't
matter what you say, what logic, what rationality, what patience, what
evidence, for vast majority of these people, God of their variety will
exist, and will be the only type.
Fanatics are fanatics because they lost their rationality on the
subject. They simply have the need to believe. (other examples in the
computing industry include: Mac fanatics, unix fuckheads (and now
Linux), OpenSource fuckheads.)
My article, is not titled “The stupidity of Lisp Syntax”. Nor “Lisp's
got syntax problems”. Nor, “The moronicity of Common Lisp fuckheads”.
The title is “How Lisp's Nested Notation Limits The Language's
Utility”.
Note that it says “How”, meaning, the article is a exposition. Then,
it says “Nested Notation”. And, it “limits”. Limit what? “Limits the
language's utility”.
In the article, 3 itemized issues are mentioned. I don't think i
should hold each lisper's hand to go thru the article sentence by
sentence. You can eye the article with built-in Common Lisp prejudice
and come off not reading anything, like basically all lispers who
cried in pain here. These lispers, basically, saw the article, skimmed
it, felt the wound, panics, reactionarily thinking to themselves “O!
Another Imperative Moron who can't get used to parens!”, and then like
a gaggle of ducks, all quack about how sexp is just fine and i'm a
“troll”.
Joe, i know you are seasoned lisper, and you love lisp. Me too. (But
i'm getting stronger sense everyday that Common Lispers, at least as
so exhibited in comp.lang.lisp are all motherfuckers, the saboteurs of
the lisp's health.)
In the article, i gave 3 issues. I do not think any lisper can
honestly disagree with any one of them. Note that, let me emphasize
and repeat again here, the conclusion is not: “lisp's syntax is fucked
and needs change”.
(see also my reply to Pascal Costanza, i quote here:
(Try, perhaps, learn to calm down yourself. You are not under attack.
Lisp the language, is not under attack by my essay. My article,
although cogently detailed why lisp syntax is a serious problem at
several levels, it does not mean that, it is “no good” in some
absolute way. Also, it is far better, then essentially all imperative
language's syntaxes. Even, one can logically agree with my article,
and remain positive, because although lisp perhaps reduce the use of
function sequencing, but that by itself is not necessarily a very bad
thing. Because, function sequencing (aka chaining), although a very
important paradigm, is not necessarily the only way to program, nor
the only way for functional programing. Consider, even today in the
light of OOP. And Common Lisp, in particular, isn't all that much
concerned about purity of functional programing anyway. So logically,
from this perspective or argument, my essay isn't a damning
certificate.)
(I'm really sorry i have to say the above paragraph, as if like a pat
on the back to some crying pussies. But the juvenility, sensitivity,
ignorance, and stupidity, as shown in the responses in this thread,
made me. ) )
Joe wrote:
«Every year someone comes on comp.lang.lisp and informs us that it is
the parenthesis that are the problem.»
Huh? What you wrote above, has nothing to do with my essay. It has to
do with Common Lisping fuckhead's nagging toothache.
«But in more than forty years no one has come up with a better
alternative, and it hasn't been for want of trying or lack of
imagination. »
What about Logo? Dylan? Arc? Mathematica? And the Scheme Lisp's coming
standard, the R6RS, introducing [] {} and other syntaxes that breaks
the nested paren. (note: this is mentioned in the article)
Also, in the article, i mentioned, that lisp syntax itself, contains
several _ad hoc_ syntax sugars for the purpose of reducing nested
parenthesis. This, for anyone not prejudiced, who put thought into
reading the article, might suggest a argument that too many nested
parens is considered a problem by the grand daddies of lisp founder
themselves. When you code lisp tonight, why don't you aways use
“(quote ...)” instead of “'”, hum?
As to why, Common Lisp, didn't change its syntax away from parens...
well... with all the Common Lisp fuckheads in hostile denial as
exhibited in this thread, and the stale air hold by these old lispers
new fanatical recruits, how's any change, if necessary, ever gonna
begin?
A prosperous society needs open mind and open discussion. The lisper
fuckheads, as exhibited in this thread, have been unreasonable and
persecuting to criticism. I believe, many lisp's problems,
(specifically, problems of Common Lisp today), its stagnation, is due
to these fuckheads.
Jeremi...@gmail.com
> 2007-05-06
>
>
> A prosperous society needs open mind and open discussion. The lisper
> fuckheads, as exhibited in this thread, have been unreasonable and
> persecuting to criticism. I believe, many lisp's problems,
> (specifically, problems of Common Lisp today), its stagnation, is due
> to these fuckheads.
>
> Xah
> x...@xahlee.org
> ∑http://xahlee.org/
A prosperous society needs open mind and open discussion , not an
insults and miles of empty words from people who don't know anything
about the subject. Learn some Lisp before posting more thrash for
something you don't know anything about.
JT
Lisp rules Xah Lee and Jon Harrop suck
java...@gmail.com
Xah Lee wrote:
> For example, there are Christians, and there are Islamics. Doesn't
> matter what you say, what logic, what rationality, what patience, what
> evidence, for vast majority of these people, God of their variety will
> exist, and will be the only type.
[OFF TOPIC]
Religion is a good example to compare with programming languages:
In fact, religion (in its real sense) is never in opposite to reason,
but it is far beyond it! So far, that only a God is able to enlighten
you, where your intelligence is not able to reach.
Now, with programming languages, there seems to be a kind of humans
not able to get the enlightening from something beyond their
capabilities (sorry, intelligence alone is not enough; one very
important ingredient is simplicity, in its profound sense...).
-JO
Xah Lee
i don't know who you are. But i vaguely recall, you are one of the
moronic respondents to one of my criticisms on how Emacs needs to be
modernized. (and i hated you very much)
(See
Modernization Emacs
http://xahlee.org/emacs/modernization.html
)
One of the criticism of my numerous criticism in the computing
industry, is that i am not “constructive” in some way. This is fuzzy
and silly.
For example, poeple don't respond to professional critics, by
retorting “What have you done?”
(
See
Criticism versus Constructive Criticism
UnixResource_dir/writ/criticism.html
)
A good criticism, in itself, is a contribution to the community.
Philosophers, for example, are examplary in this regard.
But as to what i have actually done for the computing communities of
which i've criticized besides criticism, i think there's a few.
Mostly, i have several tutorials on my website:
Perl and Python tutorial (~80 HTML pages)
• http://xahlee.org/perl-python/python.html
Emacs and Emacs Lisp tutorial (~80 HTML pages)
• http://xahlee.org/emacs/emacs.html
A complete, mirror of the official HTML documentation of Emacs Lisp,
with HTML code modified (corrected) so that they are W3C valid HTML
document, and CSS added for easier reading. (~850 HTML pages)
• http://xahlee.org/elisp/index.html
A Java tutorial
• http://xahlee.org/java-a-day/java.html (~40 HTML pages)
A Javascript and HTML and CSS tutorial (~70 HTML pages)
• http://xahlee.org/js/js.html
These are informal tutorials. Sure, they are not as rigorous as
published books in print. Sure, perhaps 20% of the content of my
tutorials are filled with technical criticisms.
You, as a tech geeker, may argue that my writings or teachings are in
bad quality or taste in your eyes. But they are there, and unarguably
took years to create. In all fairness, i think society would judge
them, to be positive, or “constructive” contributions. (and i do
receive regular emails from professional programers, educators,
professors, mathematicians (including a Nobel Prize laureate, to thank
me on my articles in diverse areas)
There was a Python fuckhead, who's name is Steve Holden ( http://www.holdenweb.com/
), in 2005-04-12, in response to criticisms i made of the
motherfucking garbage of the Python documentation, challenged me to
rewrite it, with the offer of $100 USD.
I responded, and the result is a full-rewrite of the Python's RE doc.
(
Pyhton Regex Documentation: String Pattern Matching
http://xahlee.org/perl-python/python_re-write/lib/module-re.html
)
He, reneged his promise to pay, citing that i missed the deadline
(that he missed my announcement), and that i failed the qualifications
of which he made the $100 offer.
Regardless of the situation, my rewrite of the entire Python
documentation of its RE module, is a contribution.
So, yeah, i made contributions, and arguably, quite a lot in the
computing industry. By my mere criticism, and by actual tutorials and
codes. (not counting, areas in Math, or Mathematica programing)
But really, the newsgroup fuckheads, their accusation of my “negative”
criticism, or my “lack of contribution”, really are due to their lack
of general education in the area of humanities (in particular: their
lack of understanding of the role of criticism), and as a execuse to
attack me in the political struggle, and or simply careless farts to
posts they don't like in newsgroups.
Xah
x...@xahlee.org
∑ http://xahlee.org/
Xah Lee wrote:
« How Lisp's Nested Notation Limits The Language's Utility
http://xahlee.org/UnixResource_dir/writ/notations.html
»
Tim Bradshaw wrote:
« Very good. Now, off you go and design and implement an alternative
syntax. It's easy, it's been done hundreds of times. I think I have
two or three limited examples on my web site and several more I never
bothered publishing. There must, as I say, be hundreds of examples
around and probably thousands when you count all the non-published
ones. So pick the best and use them, or, since you're by far the
smartest person here, why not come up with your own? Jon Harrop can
probably help you. »
Tim X wrote:
«
Actually, I think this is a very good idea forXah. Many have been very
critical of what he posts (including myself), but I suspect a large
percentage of people totally dismiss what he writes because he doesn't
provide any constructive alternatives. He regularly posts about what
is wrong with emacs, lisp, unix, perl etc. but rarely do I see any
proposed solutions or constructive ideas that might actually improve
the situation.
come onXah, you have made frequent references to your superior IQ,
»
Joe Marshall
> «I think you're wrong, Xah. If the syntax is a problem, why haven't
> any alternative syntaxes taken over for s-expressions? I point to
> these examples:»
>
>
> got syntax problems". Nor, "The moronicity of Common Lisp fuckheads".
>
> The title is "How Lisp's Nested Notation Limits The Language's
> Utility".
Point taken. I got distracted.
Pascal Costanza
> But also, lisp can actually relatively easily,
> create a layer of syntax on top of sexp...
It was hard to find out that there is actually a question somewhere deep
down in your posting.
Here is one possible answer:
(defmacro pipe (&body forms)
(let ((var (gensym)))
`(macrolet ((=> (&body forms)
`(let ((,',var (funcall #',(car forms) ,',var)))
,(if (cdr forms) (cdr forms) ',var))))
(let ((,var ,(car forms)))
,(if (cdr forms) (cdr forms) var)))))
> (defun square (x) (* x x))
SQUARE
> (pipe 5 => 1+ => square => print)
36
This is just a sketch. A full version would probably require some more
work. But there you go...
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Dan Bensen
> Xah Lee wrote:
>> But also, lisp can actually relatively easily,
>> create a layer of syntax on top of sexp...
Just to make this slightly shorter, most nonLispers
seem to like concise syntax, so they might prefer
5 => 1+ => square => print
which in Lisp can (and sort of has to) be written even
more concisely as
(=> 5 1+ square print)
(defmacro => (&rest forms)
(let ((expr (car forms)))
(dolist (func (cdr forms) expr)
(setf expr `(funcall #',func ,expr)))))
(defun echo-sqrt ()
(write-string "Enter number to be sqrt'd: ")
(finish-output)
(=> (read-line)
parse-integer
sqrt
write-to-string
write-line))
> Enter number to be sqrt'd: 34
> 5.8309517
--
Dan
www.prairienet.org/~dsb/
Markus E Leypold
Joe Marshall <eval....@gmail.com> writes:
Bah! How's utility defined anyway? And if "limitation of utility" (by
syntax) is not a problem (in the syntax) for a language, I don't
know. No, no -- I think xou got that right: Xah is riding on the old(1)
crank train "Lisp has too many parenthesis" and the answer "this has
never been a problem as evidenced by the non-success of alternative
syntaxes" is exactly the right one.
Regards -- Markus
(1) 50 years. Imagine.
Tim Bradshaw
>
> (defmacro => (&rest forms)
> (let ((expr (car forms)))
> (dolist (func (cdr forms) expr)
> (setf expr `(funcall #',func ,expr)))))
Just to be clear, this is precisely *not* what a pipe operator should
do, and it's not what it does in scsh. This is just a notation for
function composition, and that' s not what pipes are (or it's not what
they are without significant changes to what function call means).
The reason this isn't what pipes are is this (in sh)
(while wget http://some/site/blah; do sleep 30; done) | awk '...'
for instance. This perfectly reasonable fragment may fail to
terminate, yet it does (or may) result in a stream of output which
output may be useful. And that's the thing about pipelines: they
operate on potentially infinite streams. Function call in CL is not
like that.
I think you can *make* function call like that with languages which do
lazy evaluation, but CL is not natively such a language. Neither is
scsh as far as I know, and pipes etc are different things than
function calls in it.
Pascal Costanza
OK, but Xah's complaint was about syntax, not about semantics.
Tim Bradshaw
>
> OK, but Xah's complaint was about syntax, not about semantics.
Agreed. I was just trying to add somethign substantive since I think
we both agree his complaing is without merit :-)
Tamas Papp
> Just to make this slightly shorter, most nonLispers
> seem to like concise syntax, so they might prefer
> 5 => 1+ => square => print
> which in Lisp can (and sort of has to) be written even
> more concisely as
> (=> 5 1+ square print)
>
> (defmacro => (&rest forms)
> (let ((expr (car forms)))
> (dolist (func (cdr forms) expr)
> (setf expr `(funcall #',func ,expr)))))
>
> (defun echo-sqrt ()
> (write-string "Enter number to be sqrt'd: ")
> (finish-output)
> (=> (read-line)
> parse-integer
> sqrt
> write-to-string
> write-line))
I am still learning macros, so I wanted to make sure I understand this
one. I have a question: could one write it as
(defmacro my-=> (&rest forms)
(let ((expr (car forms)))
(dolist (func (cdr forms) expr)
(setf expr `(,func ,expr)))))
ie without the funcall? I tried and it seems to work, eg
(=> 5 1+ (lambda (x) (* 2 x)))
(my-=> 5 1+ (lambda (x) (* 2 x)))
both give 12. But I am wondering if there is a difference I haven't
noticed, or if it is simply a matter of style.
Thanks,
Tamas
--
Posted via a free Usenet account from http://www.teranews.com
Mike
Interesting debate.
I cannot hold myself up as anything other than someone
developing my skills - learning.
I've read most of the posts on this topic and, with respect,
perhaps your views might be a tad out of touch with the
human / IT interface. A person ultimately has to code. I
know some products roll out cookie code but behind these,
someone still had to do the work.
I program in Delphi and can all but make coffee with SQL but
they, like all languages it have their quirks. Now that I'm
learning Scheme I'm horrified to discover how precious
little I understood and how badly crafted my code was ...
ouch. But that's a very very good thing (from my
perspective). I did not know what I didn't know - and could
not ask if I didn't know what to ask. I made things 'work'
so it had to be ok. Moved past that thanks to the help of
the parentheses in Scheme. It adds order and imposes
structure: all good to a newbie.
Taking your argument (as far as I am able to understand it -
not a criticism of you BTW) on face value, all programs that
are not machine code are problematic. And I don't fancy
doing any machine code in this lifetime.
Each language builds on several interacting and to a large
part, symbiotic issues. Technology changes. People are
generally becoming more educated. What is considered
laborious today will be mundane in 20 years time just as it
is now in comparison to 20 years ago.
Scheme (parentheses or not) is from a learning perspective
ideal because it is well structured and it is very easy to
read. Unless a person is able to understand what is
happening in the code (read: any code someone else writes)
then they can't tell if it is doing what it claims to do -
further, they can't tell if there is anything wrong or
anything they might do to improve it. At least, not without
an exorcist.
Isn't is more practical to choose the right tool for the
right task to be used in the right context by the right
person?
And don't you think that the advantages of being able to
easily understand what a program is doing makes it a lot
easier to attract talent to the field and to develop better
tools.
Performance is king - or perhaps not so much. With each
iteration of increase in processor performance, the drive
towards code stability (predictability) and maintainability
outweigh yet to be proved advantages of arcane cryptic code?
If maths is a universal language, then so too is programming
(various languages) by extension?
I'm uncertain if there is merit in returning to a period
where social power was exercised by only those people who
could read. It just sounds like a revisionist form of
techno-mage (the magic lies in the ability to read / write
things that few can read and even less, understand.
Like I said, interesting discussion.
Kindest regards,
Mike
"Xah Lee" <x...@xahlee.org> wrote in message
news:1178323877....@o5g2000hsb.googlegroups.com...
How Lisp's Nested Notation Limits The Language's Utility
Xah Lee, 2007-05-03
There is a common complain by programers about lisp's
notation, of
nested parenthesis, being unnatural or difficult to read.
Long time
lisp programers, often counter, that it is a matter of
conditioning,
and or blaming the use of "inferior" text editors that are
not
designed to display nested notations. In the following, i
describe how
lisp notation is actually a problem, in several levels.
(1) Some 99% of programers are not used to the nested
parenthesis
syntax. This is a practical problem. On this aspect along,
lisp's
syntax can be considered a problem.
(2) Arguably, the pure nested syntax is not natural for
human to read.
Long time lispers may disagree on this point.
(3) Most importantly, a pure nested syntax discourages
frequent or
advanced use of function sequencing or compositions. This
aspect is
the most devastating.
The first issue, that most programers are not comfortable
with nested
notation, is well known. It is not a technical issue.
Whether it is
considered a problem of the lisp language is a matter of
philosophical
disposition.
The second issue, about nested parenthesis not being natural
for human
to read, may be debatable. I do think, that deep nesting is
a problem
to the programer. Here's a example of 2 blocks of code that
are
syntactically equivalent in the Mathematica language:
vectorAngle[{a1_, a2_}] := Module[{x, y},
{x, y} = {a1, a2}/Sqrt[a1^2 + a2^2] // N;
If[x == 0, If[Sign@y === 1, ?/2, -?/2],
If[y == 0, If[Sign@x === 1, 0, ?],
If[Sign@y === 1, ArcCos@x, 2 ? - ArcCos@x]
]
]
]
SetDelayed[vectorAngle[List[Pattern[a1,Blank[]],Pattern[a2,Blank[]]]],
Module[List[x,y],
CompoundExpression[
Set[List[x,y],
N[Times[List[a1,a2],
Power[Sqrt[Plus[Power[a1,2],Power[a2,2]]],-1]]]],
If[Equal[x,0],
If[SameQ[Sign[y],1],Times[?,Power[2,-1]],
Times[Times[-1,?],Power[2,-1]]],
If[Equal[y,0],If[SameQ[Sign[x],1],0,?],
If[SameQ[Sign[y],1],ArcCos[x],
Plus[Times[2,?],Times[-1,ArcCos[x]]]]]]]]]
In the latter, it uses a full nested form (called FullForm
in
Mathematica). This form is isomorphic to lisp's nested
parenthesis
syntax, token for token (i.e. lisp's "(f a b)" is
Mathematica's
"f[a,b]"). As you can see, this form, by the sheer number of
nested
brackets, is in practice problematic to read and type. In
Mathematica,
nobody really program using this syntax. (The FullForm
syntax is
there, for the same reason of language design principle
shared with
lisp of "consistency and simplicity", or the commonly touted
lisp
advantage of "data is program; program is data".)
The third issue, about how nested syntax seriously
discourages
frequent or advanced use of inline function sequencing on
the fly, is
the most important and I'll give further explanation below.
One practical way to see how this is so, is by considering
unix's
shell syntax. You all know, how convenient and powerful is
the unix's
pipes. Here are some practical example: "ls -al | grep xyz",
or "cat a
b c | grep xyz | sort | uniq".
Now suppose, we get rid of the unix's pipe notation,
instead, replace
it with a pure functional notation: e.g. (uniq (sort (grep
xyz (cat a
b c)))), or enrich it with a composition function and a pure
function
construct (?), so this example can be written as: ((compose
(lambda
(x) (grep xyz x)) sort uniq) (cat a b c)).
You see, how this change, although syntactically equivalent
to the
pipe "|" (or semantically equivalent in the example using
function
compositions), but due to the cumbersome nested syntax, will
force a
change in the nature of the language by the code programer
produces.
Namely, the frequency of inline sequencing of functions on
the fly
will probably be reduced, instead, there will be more code
that define
functions with temp variables and apply it just once as with
traditonal languages.
A language's syntax or notation system, has major impact on
what kind
of code or style or thinking pattern on the language's
users. This is
a well-known fact for those acquainted with the history of
math
notations.
The sequential notation "f@g@h@x", or "x//h//g//f", or unixy
"x|h|g|
f", are far more convenient and easier to decipher, than "(f
(g (h
x)))" or "((compose h g f) x)". In actual code, any of the
f, g, h
might be a complex pure function (aka lambda construct, full
of
parenthesis themselves).
Lisp, by sticking with almost uniform nested parenthesis
notation, it
immediately reduces the pattern of sequencing functions,
simply
because the syntax does not readily lend the programer to it
as in the
unix's "x|h|g|f". For programers who are aware of the coding
pattern
of sequencing functions, now either need to think in terms
of a
separate "composition" construct, and or subject to the much
problematic typing and deciphering of nested parenthesis.
(Note: Lisp's sexp is actually not that pure. It has ad hoc
syntax
equivalents such as the "quote" construct " '(a b c) ", and
also "`",
"#", ",@" constructs, precisely for the purpose of reducing
parenthesis and increasing readability. Scheme's coming
standard the
R6RS ?, even proposes the introduction of [] and {} and few
other
syntax sugars to break the uniformity of nested parenthesis
for
legibility. Mathematica's FullForm, is actually a pure
nested notation
as can be.)
-------
The above, is part of a 3-part exposition:
"The Concepts and Confusions of Prefix, Infix, Postfix and
Fully
Functional Notations",
"Prefix, Infix, Postfix notations in Mathematica",
"How Lisp's Nested Notation Limits The Language's Utility",
archived at:
http://xahlee.org/UnixResource_dir/writ/notations.html
Xah
x...@xahlee.org
? http://xahlee.org/
Jay Belanger
Miles Bader <mi...@gnu.org> writes:
> "Malcolm McLean" <regn...@btinternet.com> writes:
>> You might be interested in the page 10 Rules of Computer Programming on
>> my website which deals with psychological issues in programming. Lisp
>> breaks the rule of three in spades.
>
> That suggests that the "rule of three" is wrong...
Multiplication is vexation,
Division is as bad;
The Rule of Three doth puzzle me,
And Practice drives me mad.
Pascal Costanza
Dan modified my code, so I am to blame for the original one. The code
was a first throw at adding infix notation for pipes to Lisp, I haven't
iterated carefully over the code. Yes, the funcall is superfluous here.
Good catch.
I wouldn't be surprised if there weren't other issues with the code. Tim
hinted at a valid semantic issue, for example.
Dan Bensen
>> (let ((expr (car forms)))
>> (dolist (func (cdr forms) expr)
>> (setf expr `(funcall #',func ,expr)))))
> I have a question: could one write it as
> (defmacro my-=> (&rest forms)
> (let ((expr (car forms)))
> (dolist (func (cdr forms) expr)
> (setf expr `(,func ,expr)))))
> ie without the funcall? I tried and it seems to work
Oops.
> I am wondering if there is a difference I haven't
> noticed, or if it is simply a matter of style.
No, I just had other things on my mind at the time.
For one thing, I was surprised that the macro didn't
need any gensyms, and also, I was having trouble with
another example that wasn't working right. Thanks for
pointing that out.
--
Dan
www.prairienet.org/~dsb/
Tamas Papp
Dear Pascal and Dan,
Thank you for your answers -- I wasn't trying to split hairs, I just
try to understand people's code so that I can improve mine.
Malcolm McLean
"Markus E Leypold"
<development-2006-8...@ANDTHATm-e-leypold.de> wrote in
message news:4f3b28t...@hod.lan.m-e-leypold.de...
yet.
Jon Harrop
> Taking your argument (as far as I am able to understand it -
> not a criticism of you BTW) on face value, all programs that
> are not machine code are problematic. And I don't fancy
> doing any machine code in this lifetime.
I don't think Xah's comments were specific to machine code in any way.
Essentially he is saying: is it not better to be able to write code like:
o + # d &
easily, rather than:
(lambda (x) `(+ ,o (* ,x ,d)))
> Each language builds on several interacting and to a large
> part, symbiotic issues. Technology changes. People are
> generally becoming more educated. What is considered
> laborious today will be mundane in 20 years time just as it
> is now in comparison to 20 years ago.
Ironically, half of this discussion has been about the relative benefits of
approaches that are all decades old. There is nothing new here.
> Scheme (parentheses or not) is from a learning perspective
> ideal because it is well structured and it is very easy to
> read. Unless a person is able to understand what is
> happening in the code (read: any code someone else writes)
> then they can't tell if it is doing what it claims to do -
> further, they can't tell if there is anything wrong or
> anything they might do to improve it. At least, not without
> an exorcist.
This is one of the arguments in favor of static verification: you can have
machine-verified documentation generated by the compiler provided the
language is carefully designed.
> Isn't is more practical to choose the right tool for the
> right task to be used in the right context by the right
> person?
Absolutely. The question is then: what is Lisp syntax good for? I think the
answer is "not a lot", which is why the vast majority of programmers moved
on to something better over the past 50 years.
> And don't you think that the advantages of being able to
> easily understand what a program is doing makes it a lot
> easier to attract talent to the field and to develop better
> tools.
Absolutely. But don't you think most people will find it easier to
understand:
a + b*c
rather than:
(+ a (* b c))
?
java...@gmail.com
> Absolutely. But don't you think most people will find it easier to
> understand:
>
> a + b*c
>
> rather than:
>
> (+ a (* b c))
>
> ?
And why is that? Because we learned that in school. So we recognize it
instantly.
(Easier to understand for someone who never saw some written maths
would in fact be the S-expression, because it doesn't contain any
implicit knowledge about precedence.)
But the power of S-expressions was discovered only some decade ago,
and only with the help of computers.
So it would in fact be possible to find a better way to express maths,
and only computers are able to help us here.
What you are stating is simply that programmers should stick with
something discovered centuries ago, when no-one was able to think of
fully automated speedy machines to help us doing maths...
Computers are able to do their low-level computing only transforming
our language expressions into S-expressions first; now if you start
doing so right from the beginning of your programming, there is simply
a perfect harmony programmer/machine, with all the advantages
included: you, the programmer, can optimize anything just from the
beginning, with the huge advantage of the ability of recognizing any
kind of pattern, and abstracting it away right from the beginning.
That is one reason why Lisp can be faster than C. The only language
which Lisp still is not able to beat is in fact assembler...
-JO
Kjetil S. Matheussen
On Wed, 9 May 2007, java...@gmail.com wrote:
> Jon Harrop wrote:
>> Absolutely. But don't you think most people will find it easier to
>> understand:
>>
>> a + b*c
>>
>> rather than:
>>
>> (+ a (* b c))
>>
>> ?
>
> And why is that? Because we learned that in school. So we recognize it
> instantly.
>
There is another reason, "a + b*c" is shorter than "(+ a (* b c))".
Therefore I think the first one is quicker to grasp. And I don't think so
because I learned "a + b*c" in school, I program lisp every day, and is
more customed to the lisp style.
However, this is a minor issue. There might be good reasons why
s-expressions aren't ideal, but to quicker get the grip of short (because
it only counts for short examples) mathematical expressions is not one of
them.
For larger mathematical expressions, I think s-expressions are much better
because you can use more lines and indentations to make things clearer.
This is of course my own subjective view. :-)
Craig A. Finseth
Kjetil S. Matheussen <k.s.mat...@notam02.no> wrote:
>On Wed, 9 May 2007, java...@gmail.com wrote:
>> Jon Harrop wrote:
>>> Absolutely. But don't you think most people will find it easier to
>>> understand:
>>> a + b*c
>>> rather than:
>>> (+ a (* b c))
>> And why is that? Because we learned that in school. So we recognize it
>> instantly.
>There is another reason, "a + b*c" is shorter than "(+ a (* b c))".
>Therefore I think the first one is quicker to grasp. And I don't think so
>because I learned "a + b*c" in school, I program lisp every day, and is
>more customed to the lisp style.
...
An S-expression's[*] strength is also its weakness. It uses one
notation for everything, so syntax is uniform and trivial. This
property is very important when you are trying to unify program and
data structure (and blur their distinction). It makes it easy to
create new conceptual structures because you don't have to fit it into
complex syntactic rules.
The weakness is that the syntax gives you no clue as to the semantics:
you have to read and understand each operator in order to know how to
interpret its semantics.
The algebraic notation -- and things like different uses of braces,
parentheses, and other syntactic elements in programming languages --
means that, once learned, you can apply syntactic information to aid
in and speed understanding of the semantic content. This is something
that we do all the time in written (and verbal) language use and so we
find it natural and easy. Losing the syntactic clues makes us have to
go to more effort to understand the semantics. This effect is
especially important if you are doing a cursory overview or just want
to get the gist of something: in many cases, the syntax is the
important thing.
For example, if I'm scanning a journal looking for a particular
article, I might glance at the equations and see a summation. That in
itself may tell me whether the article is the one I'm after.
So, I don't see us switching all languages to use S-expressions. But
that doesn't mean that Lisp should change.
Craig
[*] The same argument applies to RPN, Polish notation, XML, and many
others.
David Hansen
> For larger mathematical expressions, I think s-expressions are much
> better because you can use more lines and indentations to make
> things clearer.
Show me one person that uses sexps to scribble large equations by hand.
David
Kjetil Svalastog Matheussen
I don't think this has got anything to do with what I wrote. What are you
trying to say?
Rainer Joswig
David Hansen <david....@gmx.net> wrote:
Check out Gerald Jay Sussman:
http://video.google.com/videoplay?docid=5571878527594356342&q=sussman+sicp&hl=en
;-)
Kjetil Svalastog Matheussen
Okay, I get it. You didn't read the whole thread? The thread is about
code written on a computer. However, in case you actually knew that; No,
you can't make the comparison of scribbling an equation and writing
an equations that is supposed to be easy to grasp the meaning of.
David Hopwood
> On Wed, 9 May 2007, java...@gmail.com wrote:
>> Jon Harrop wrote:
>>
>>> Absolutely. But don't you think most people will find it easier to
>>> understand:
>>>
>>> a + b*c
>>>
>>> rather than:
>>>
>>> (+ a (* b c))
>>>
>>> ?
>>
>> And why is that? Because we learned that in school. So we recognize it
>> instantly.
>
> There is another reason, "a + b*c" is shorter than "(+ a (* b c))".
... and conciseness is important to the extent that mathematicians actually
write "a + bc", just to make it one symbol shorter.
(I'm not saying that programming languages should go that far; the
interpretation of mathematical notation is context-dependent, and
programming languages shouldn't be.)
--
David Hopwood <david....@industrial-designers.co.uk>
Pillsy
Show me one person that uses Fortran-style infix notation to scribble
large equations by hand.
Cheers,
Pillsy
Garry Hodgson
> The problem isn't creating a syntax (all decent PLs have good syntax). The
> problem is that CL doesn't bundle a decent syntax (or pattern matching,
> or ...). So there's no point in Xah implementing anything.
it might distract him from diatribing for a while.
----
Garry Hodgson, Senior Software Geek, AT&T CSO
nobody can do everything, but everybody can do something.
do something.
David Hansen
Not the whole thread but enough to understand the context. What i
wanted to say is that especially large equations benefit a lot from
special notations (∫, ∑, ∇, ∂, □, …). They might be harder to parse by
a computer program but are far more easy to parse for a human than
sexps.
David
Aaron Hsu
> But the power of S-expressions was discovered only some decade ago,
> and only with the help of computers.
> So it would in fact be possible to find a better way to express maths,
> and only computers are able to help us here.
I don't think this is strictly true. S-expressions, to my understanding,
are a simply an extension of Polish Notation (possibly called Cambridge
Polish Notation). [1] I believe Polish Notation was introduced in 1920 and
some of the benefits of prefix based notations were already demonstrated
there when applied to things like Logic and Mathematics. [2] Not to
mention, if we consider only Lisp, I believe the first incantations of
Lisp appeared around 1958, which is a little more than "some decade." [3]
So, in general I believe much of the power of prefix notations, and
subsequently, much of s-expression power was already seeing the light of
day 80 plus years ago.
[1] http://en.wikipedia.org/wiki/S-expression
[2] http://en.wikipedia.org/wiki/Polish_notation
[3] http://en.wikipedia.org/wiki/Lisp_programming_language
--
Aaron Hsu <aaro...@sacrificumdeo.net>
"No one could make a greater mistake than he who did nothing because he
could do only a little." - Edmund Burke
Garry Hodgson
> As I mentioned in another article, I really think you do need to learn
> about this internet thing. One of the nice features it offers is
> something called "downloading" - people can write code which you can
> then "download" onto your own computer and run there. It's just
> amazingly better than the whole shipping magtapes around thing.
i wonder how the traditional "kid on a bicycle with a tape" back of the
envelope calculation holds up these days.
John Thingstad
wrote:
>>
>> Okay, I get it. You didn't read the whole thread? The thread is about
>> code written on a computer. However, in case you actually knew that; No,
>> you can't make the comparison of scribbling an equation and writing
>> an equations that is supposed to be easy to grasp the meaning of.
>
> Not the whole thread but enough to understand the context. What i
> wanted to say is that especially large equations benefit a lot from
> special notations (∫, ∑, ∇, ∂, □, …). They might be harder to parse by
> a computer program but are far more easy to parse for a human than
> sexps.
>
> David
Ever considered using a Mathematica kernel and mathlink?
Do the math in mathematica and the lispy stuff in Lisp.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Jon Harrop
> Show me one person that uses Fortran-style infix notation to scribble
> large equations by hand.
Many computational scientists. Not that I'd recommend it.
Jon Harrop
> An S-expression's[*] strength is also its weakness. It uses one
> notation for everything, so syntax is uniform and trivial. This
> property is very important when you are trying to unify program and
> data structure (and blur their distinction). It makes it easy to
> create new conceptual structures because you don't have to fit it into
> complex syntactic rules.
Xah already provided the perfect counterexample: Mathematica.
As a rewrite language it completely removes the distinction between program
and data structure (everything is an expression) whilst simultaneously
adopting a sophisticated syntax and providing fallback to prefix notation.
As Xah said, prefix notation is rare in real Mathematica code.
So the common claim that s-exprs are necessary for rewriting clearly does
not hold water.
Jon Harrop
> The only language which Lisp still is not able to beat is in fact
> assembler...
and most other languages:
http://www.ffconsultancy.com/languages/ray_tracer/index.html
Note that Lisp is both the slowest and the verbose. The latter is thanks to
s-exprs and a bare-bones language.
Tim Bradshaw
> i wonder how the traditional "kid on a bicycle with a tape" back of the
> envelope calculation holds up these days.
Still the same - tape or disk can achieve fantastic bandwidth.
Dreadful latency though.
Xah Lee
Functional Notations
Xah Lee, 2006-03-15
In LISP languages, they use a notation like “(+ 1 2)” to mean “1+2”.
Likewise, they write “(if test this that)” to mean “if (test) {this}
else {that}”. LISP codes are all of the form “(a b c ...)”, where the
a b c themselves may also be of that form. There is a wide
misunderstanding that this notation being “prefix notation”. In this
article, i'll give some general overview of the meanings of Algebraic
Notation and prefix, infix, postfix notations, and explain how LISP
notation is a Functional Notation and is not a so-called prefix
notation or algebraic notation.
The math notation we encounter in school, such as “1+2”, is called
Infix Algebraic Notation. Algebraic notations have the concept of
operators, meaning, symbols placed around arguments. In algebraic
infix notation, different symbols have different stickiness levels
defined for them. e.g. “3+2*5>7” means “(3+(2*5))>7”. The stickiness
of operator symbols are normally called “Operator Precedence”. It is
done by giving a order specification for the symbols, or equivalently,
give each symbol a integer index, so that for example if we have
“a⊗b⊙c”, we can unambiguously understand it to mean one of “(a⊗b)⊙c”
or “a⊗(b⊙c)”.
In a algebraic postfix notation known as Polish Notation, there needs
not to have the concept of Operator Precedence. For example, the infix
notation “(3+(2*5))>7” is written as “3 2 5 * + 7 >”, where the
operation simply evaluates from left to right. Similarly, for a prefix
notation syntax, the evaluation goes from right to left, as in “> 7 +
* 5 2 3”.
While functional notations, do not employ the concept of Operators,
because there is no operators. Everything is a syntactically a
“function”, written as f(a,b,c...). For example, the same expression
above is written as “>( +(3, *(2,5)), 7)” or “greaterThan( plus(3,
times(2,5)), 7)”.
For lisps in particular, their fully functional notation is
historically termed sexp (short for S-Expression, where S stands for
Symbolic). It is sometimes known as Fully Parenthesized Notation. For
example, in lisp it would be (f a b c ...). In the above example it
is: “(> (+ 3 (* 2 5)) 7)”.
The common concepts of “prefix, postfix, infix” are notions in
algebraic notations only. Because in Full Functional Notation, there
are no operators, therefore no positioning to talk about. A Function's
arguments are simply explicitly written out inside a pair of enclosing
delimiters.
Another way to see that lisp notation are not “pre” anything, is by
realizing that the “head” f in (f a b c) can be defined to be placed
anywhere. e.g. (a b c f) or even (a f b c), and its syntax analysis
remains the same. In the language Mathematica, f(a b c) would be
written as f[a,b,c] where the argument enclosure symbols is the square
bracket instead of parenthesis, and argument separator is comma
instead of space, and the function symbol (or head) is placed in
outside and in front of the argument enclosure symbols.
The reason for the misconception that lisp notations are “prefix” is
because the head appears before the enclosed arguments. Such use of
the term “prefix” is a confusion engenderer because the significance
of the term lies in algebraic notation systems.
A side note: the terminology “Algebraic” Notation is a misnomer. It
seems to imply that such notations have something to do with the
branch of math called algebra while other notation systems do not. The
reason the name Algebraic Notation is used because when the science of
algebra was young, around 1700s mathematicians are dealing with
equations using symbols like “+ × =” written out similar to the way we
use them today. This is before the activities of systematic
investigation into notation systems as necessitated in the studies of
logic in 1800s or computer languages in 1900s. So, when notation
systems are actually invented, the conventional way of infixing “+ ×
=” became known as algebraic because that's what people think of when
seeing them.
----
This post is archived at:
http://xahlee.org/UnixResource_dir/writ/notations.html
Kjetil S. Matheussen
On Wed, 9 May 2007, David Hansen wrote:
>>>>
>>>> Show me one person that uses sexps to scribble large equations by hand.
>>>>
>>>
>>> I don't think this has got anything to do with what I wrote. What are you
>>> trying to say?
>>>
>>
>> Okay, I get it. You didn't read the whole thread? The thread is about
>> code written on a computer. However, in case you actually knew that; No,
>> you can't make the comparison of scribbling an equation and writing
>> an equations that is supposed to be easy to grasp the meaning of.
>
> Not the whole thread but enough to understand the context. What i
> wanted to say is that especially large equations benefit a lot from
> special notations (ÿÿ, ÿÿ, ÿÿ, ÿÿ, ÿÿ, ÿÿ). They might be harder to parse by
> a computer program but are far more easy to parse for a human than
> sexps.
Not really... There is no right or wrong here so you must add something
like "I think", "in my opinion", "from my experience based on ...", etc.
to make the above statement correct.
Pascal Bourguignon
> Not the whole thread but enough to understand the context. What i
> wanted to say is that especially large equations benefit a lot from
> special notations (∫, ∑, ∇, ∂, □, …). They might be harder to parse by
> a computer program but are far more easy to parse for a human than
> sexps.
All these special notations are prefix.
--
__Pascal Bourguignon__ http://www.informatimago.com/
"Specifications are for the weak and timid!"
Dan Bensen
> The common concepts of “prefix, postfix, infix” are notions in
> algebraic notations only.
The common concepts of computer programming are defined by computer
programmers, not by mathematicians. The term "prefix notation" when
used in the programming world does not indicate "algebraic prefix
notation" as defined by mathematicians. The word "prefix" is a generic
English word meaning roughly that the thing being referred to occurs
before something else. This accurately describes the position of
the operator in a Lisp s-expression.
> Another way to see that lisp notation are not “pre” anything, is by
> realizing that the “head” f in (f a b c) can be defined to be placed
> anywhere. e.g. (a b c f) or even (a f b c), and its syntax analysis
> remains the same.
Is this consistent with the CL spec or any standard Lisp spec?
I've never heard of such a thing.
--
Dan
www.prairienet.org/~dsb/
Kjetil S. Matheussen
On Thu, 10 May 2007, Pascal Bourguignon wrote:
> David Hansen <david....@gmx.net> writes:
>> Not the whole thread but enough to understand the context. What i
>> wanted to say is that especially large equations benefit a lot from
>> special notations (ÿÿ, ÿÿ, ÿÿ, ÿÿ, ÿÿ, ÿÿ). They might be harder to parse by
>> a computer program but are far more easy to parse for a human than
>> sexps.
>
> All these special notations are prefix.
>
Oh, I didn't see the special notations. (Pine just shows ( , , , ,).) In
that case, then I guess there was less reason to add "I think" etc.,
although it definitely wouldn't hurt.
But I still wonder what his point was, as this is unrelated to the
discussion. The way he quoted me on his first posting, I got the
impression that he disagreed with something I said, but I'm not sure what
that might have been?
Miles Bader
> The algebraic notation -- and things like different uses of braces,
> parentheses, and other syntactic elements in programming languages --
> means that, once learned, you can apply syntactic information to aid
> in and speed understanding of the semantic content.
However this happens in sexpr based languages too -- people use the
"shape" of code (e.g., notice how quickly you can recognize a "cond" in
lisp) , and things like naming conventions ("with-..." "do...") to
quickly establish the general meaning of a statement. This is exactly
the sort of "vague semantic hint" that you get from braces and other
more exotic syntaxes.
-Miles
--
A zen-buddhist walked into a pizza shop and
said, "Make me one with everything."
Pascal Bourguignon
> On Thu, 10 May 2007, Pascal Bourguignon wrote:
>
>> David Hansen <david....@gmx.net> writes:
>>> Not the whole thread but enough to understand the context. What i
>>> wanted to say is that especially large equations benefit a lot from
>>> special notations (ÿÿ, ÿÿ, ÿÿ, ÿÿ, ÿÿ, ÿÿ). They might be harder to parse by
>>> a computer program but are far more easy to parse for a human than
>>> sexps.
>>
>> All these special notations are prefix.
>>
>
> Oh, I didn't see the special notations. (Pine just shows ( , , , ,).)
> In that case, then I guess there was less reason to add "I think"
> etc., although it definitely wouldn't hurt.
That's why, while we can use Unicode in most lisp implementations, we
usually prefer to "spell out" the symbols in ASCII, and write:
(integral sum nabla delta square etc)
This is something that seems to be bothering lisp detractors, but it's
also a liberating aspect of lisp, that a lot of what is encoded in
characters with special syntactic roles in other programming languages
can be written in lisp as normal symbols.
--
__Pascal Bourguignon__ http://www.informatimago.com/
"Debugging? Klingons do not debug! Our software does not coddle the
weak."
Markus E Leypold
"Malcolm McLean" <regn...@btinternet.com> writes:
> "Markus E Leypold"
> <development-2006-8...@ANDTHATm-e-leypold.de> wrote in
> message news:4f3b28t...@hod.lan.m-e-leypold.de...
>>
>> Joe Marshall <eval....@gmail.com> writes:
>>
>>> On May 7, 5:21 am, Xah Lee <x...@xahlee.org> wrote:
>>>> 2007-05-06
>>>>
>>>> jrm wrote:
>>>> «I think you're wrong, Xah. If the syntax is a problem, why haven't
>>>> any alternative syntaxes taken over for s-expressions? I point to
>>>> these examples:»
>>>>
>>>>
>>>> My article, is not titled "The stupidity of Lisp Syntax". Nor "Lisp's
>>>> got syntax problems". Nor, "The moronicity of Common Lisp fuckheads".
>>>>
>>>> The title is "How Lisp's Nested Notation Limits The Language's
>>>> Utility".
>>>
>>> Point taken. I got distracted.
>>
>>
>> Bah! How's utility defined anyway? And if "limitation of utility" (by
>> syntax) is not a problem (in the syntax) for a language, I don't
>> know. No, no -- I think xou got that right: Xah is riding on the old(1)
>> crank train "Lisp has too many parenthesis" and the answer "this has
>> never been a problem as evidenced by the non-success of alternative
>> syntaxes" is exactly the right one.
>>
> Or rather it is problem but no one has been able to find the right
> answer yet.
There are many problems in "IT" and CS. The parenthises in Lisp aren't
among them. I also wonder that there are regularly more people
complaining about Lisp syntax than about Perl syntax. Shows to me that
syntax must be an acquired taste anyway.
Regards -- Markus
Markus E Leypold
Craig A. Finseth <ne...@finseth.com> writes:
>
> The weakness is that the syntax gives you no clue as to the semantics:
> you have to read and understand each operator in order to know how to
> interpret its semantics.
It also doesn't mislead you about semantics: It doesn't pretend that a
lambda definition is really something different from any other
expression, from control structures etc. It has been argued that
therefore Scheme is the ideal language for beginners. I don't agree
with that completely, but still: Syntax can also be misleading because
it introduces distinction where there are none.
Regards -- Markus
Markus E Leypold
David Hansen <david....@gmx.net> writes:
I have done so from time to time, when I still practiced physics and
mathematics. It has advantages.
Regards -- Markus
Markus E Leypold
Xah Lee <x...@xahlee.org> writes:
> There are some others in this thread, which are so hateful, fucking
> full of the ugliness of humanity. The replies from Markus E Leypold is
> a prime example. I wonder, outside of newsgroups, if he is just a
> sophomoron at college.
Ohoh! Look -- I just found that embedded in so much rubbish that I
actually missed it the first time. Actually thank you for the
feedback, Xah: I must really hurt you some to earn a personal
mentioning, and that, admittedly was the purpose, albeit only an
intermediate one. The primary purpose was to achieve a change in you
incontinent posting behaviour (more a disorder), but that has
failed. Animals learn from pain, you're resistant. I wonder ...
Regards -- Markus
Markus E Leypold
In another thread you wrote:
> In this thread, a few people already started to post completely off
> topic, brainless, pure personal attacks. I think you are still good.
The first off topic post in most Xah Lee thread, unfortunately, is the
first thread of the post -- yours.
> I wasn't sure, if you are just fucking with me, or really, really
> meant your writing as a valid argument to my thesis.
Basically these days we're are just trying to fuck with you, though
only in the metaphoric, sense, not really --
http://xahlee.org/PageTwo_dir/Personal_dir/mi_pixra/mi_lunbe_las_vegas_2003-10.jpg
[WARNING TO READERS: adult rated + rather dependend on your taste too]
is rather off putting in this respect.
BTW, this:
> Exactly. I've been using online forums since 1990. I've been using
> newsgroups since maybe 1994. If i wanted to play politics, given my IQ
> and my knowledge of computing, and great skill of composition, i might
> be a fucknig George Bush by now, with a massive army of morons at my
> commands, not like, the likes of some computing industry leaders.
(and the rest of that post) does sound pretty borderline to me. I
suggest that you look for some professional help.
On the other side ...
> Ken Tilton, also wrote something that's incredibly stupid.
you seem to be completely surrounded by morons, as also evidenced by
various entries in your blogs, at your Wikipedia page etc., which have
no understanding for your outstanding genius.
This indicates a real mismatch between your superior intelligence and
the rest of this poor moronic planet.
Perhaps it is time to transcendend now (to divinity) instead of
bombarding the world at large (well, a tiny corner of the usenet)
> comp.lang.lisp,comp.emacs,comp.lang.scheme,comp.lang.functional
with
> The Concepts and Confusions of Prefix, Infix, Postfix and Fully
> Functional Notations
your (offtopic)
> Xah Lee, 2006-03-15
stale essays.
Regards -- Markus
Malcolm McLean
"Markus E Leypold"
<development-2006-8...@ANDTHATm-e-leypold.de> wrote in
website, 10 rules). If we used a graphical editor to display lists as trees
we have the rule of five, and thus a better visual fix on the grammar, but
many lists would still be too big.
The solution of putting some extra structure using lines and indents seems
to be workable
Here's the first non-trivial bit of code I found rooting at random in recent
posts
(defgeneric to-string (item)
(:documentation "Returns item as a string.")
(:method ((item string))
item)
(:method ((item character))
(string item))
(:method ((item symbol))
(string item))
(:method ((item number))
(write-to-string item))
(:method ((item sequence))
(if (every #'characterp item)
(coerce item 'string)
(error "Sequence item contains non-characters."))))
You see that the author is in fact imposing a rule of three, except in the
last inevitable closing cascade. However it is maybe untypical - he's only
got one condition.
--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm
Malcolm McLean
"Dan Bensen" <rando...@cyberspace.net> wrote in message
news:f1tnlf$m6u$1...@wildfire.prairienet.org...
first in the list. It could equally well be last, or second.
fireblade
wrote:
> On Wed, 9 May 2007, java....@gmail.com wrote:
> > Jon Harrop wrote:
> >> Absolutely. But don't you think most people will find it easier to
> >> understand:
>
> >> a + b*c
>
> >> rather than:
>
> >> (+ a (* b c))
>
> >> ?
>
> > And why is that? Because we learned that in school. So we recognize it
> > instantly.
>
> There is another reason, "a + b*c" is shorter than "(+ a (* b c))".
> because I learned "a + b*c" in school, I program lisp every day, and is
> more customed to the lisp style.
>
> However, this is a minor issue. There might be good reasons why
> s-expressions aren't ideal, but to quicker get the grip of short (because
> it only counts for short examples) mathematical expressions is not one of
> them.
>
> For larger mathematical expressions, I think s-expressions are much better
> because you can use more lines and indentations to make things clearer.
>
>
> - Show quoted text -
s-exp gives you orthogonality so you could learn lisp syntax in a half
of hour .How long does it takes to get all the precedence rules? I'm
not saying that s-exp are good thing for inserting complex math
expressions, though in some ways it helps like a + b + c + d + e <=>
(+ a b c d e), but if you prefer inserting math infix use a macro for
it. There's a full thread explaining this => Any macro for inserting
math "normally:
http://groups.google.com/group/comp.lang.lisp/browse_thread/thread/38c67e7a2511eeb6/dc827f5650e54d49lnk=gst&q=&rnum=15#dc827f5650e54d49
Lisp gives you a power of choice, in other languages you have to live
with whatever language designers thought it's right.
cheers
bobi
Andrew Reilly
> What he is saying is that it is pure convention that the operator comes
> first in the list. It could equally well be last, or second.
Well sure, but how was the dialog helped by saying it? It's one of the
conventions that makes lisp lisp. Putting the operator last makes it
forth, (more or less). Putting it in any other fixed location puts a
probably-inconvenient lower bound on function arity. Making the location
dependent on the operator means that you need some other information to
avoid ambiguities, like precedence. So lisp functions go first in the
list. That makes 'em prefixes in my book.
Cheers,
--
Andrew
Jon Harrop
> Lisp gives you a power of choice, in other languages you have to live
> with whatever language designers thought it's right.
As Xah pointed out, that is not true. Other languages do give you the
choice, people made the choice and most of them didn't choose s-exprs.
Jon Harrop
> David Hansen <david....@gmx.net> writes:
>> Not the whole thread but enough to understand the context. What i
>> wanted to say is that especially large equations benefit a lot from
>> a computer program but are far more easy to parse for a human than
>> sexps.
>
> All these special notations are prefix.
No they aren't. The German S and Sigma are typeset, with limits above and
below. Square root symbol is typeset, not prefix. Many syntaxes uses
superscript, subscript, overbar, strikethrough etc.
Jon Harrop
> However this happens in sexpr based languages too -- people use the
> "shape" of code (e.g., notice how quickly you can recognize a "cond" in
> lisp) , and things like naming conventions ("with-..." "do...") to
> quickly establish the general meaning of a statement. This is exactly
> the sort of "vague semantic hint" that you get from braces and other
> more exotic syntaxes.
Exactly. Indentation is the poor man's typesetting.
Tim Bradshaw
>
> What he is saying is that it is pure convention that the operator comes
> first in the list. It could equally well be last, or second.
And of course what he's conveniently ignoring is that the position of
the operator is actually what matters. Like a lot of novices he's got
massively hung up on the parens and the other little punctuation
characters which programming languages need in order for the parser to
do a fast predictable job, but which experienced humans ignore.
Once you ignore the parens (or the other punctuation if you're reading
Java, say) you see a sequence of words, generally with line breaks and
indentation indicating what they are doing. And the difference
between languages then comes down largely to word order:
Lisp is verb first, or prefix:
do-this-operation thing other-thing ...
so is C. Natural languages like this would be called VSO in general.
Java is, in many cases, verb-second, or SVO:
thing operation other-thing ...
So is English in many cases.
Forth is verb-last, so is PS etc (possibly SOV).
Of course most programming languages have a mass of special cases for
arithmetic and logical operations. Lisp doesn't (but such a syntax
can easily be added of course). Some small number of languages allow
you to extend this special syntax: I think Prolog does this. Some
others do this horrible thing of not allowing that but allowing you to
overload the fixed set of special operators (not in the Lisp sense)
with other meanings: C++ is a notorious example. Java notably has
avoided this.
Obviously if you don't like Lisp being verb-first, you can make it be
anything else, see for instance http://www.tfeb.org/lisp/toys.html#SLIP.
Lots of syntax loonies get absurdly hung up on the maths stuff,
because that's typically one of the first things you learn in any
language, and since they never get beyond that stage they assume that
programs are mostly maths. Even mathematical monographs are not
mostly maths!
--tim
Jon Harrop
> Some
> others do this horrible thing of not allowing that but allowing you to
> overload the fixed set of special operators (not in the Lisp sense)
> with other meanings: C++ is a notorious example.
F# also lets you do this and I see it as an advantage.
Markus E Leypold
"Malcolm McLean" <regn...@btinternet.com> writes:
Rule(s) of ten: Never make up ten rules, esp. if badly conceived. Thou
shalt not have nine rules besides me for the obvious reason.
I don't know how to break it to you gently: Your rules are more
pretentious than wise or insightful. They are hardly an authority to
which you can refer for argument. And your rule 3 is not about
parenthesis, but about indirection and a pair of parenthesis has in
Lisp has nothing to do with indirection.
Regards -- Markus
Frederic Beal
> Are you using the compile line that is given on the site?
Oh, I see you use recursive types. What is the rationale for that ?
--
Frederic Beal
Arved Sandstrom
news:aMWdnSMZKdAJv6Pb...@bt.com...
>
> "Arved Sandstrom" <asand...@accesswave.ca> wrote in message
> news:z4o%h.5219$Vi6.3376@edtnps82...
>> "Malcolm McLean" <regn...@btinternet.com> wrote in message
>> news:TNOdnQlUpMyFqqHb...@bt.com...
>>>
>>> "Kaz Kylheku" <kkyl...@gmail.com> wrote in message
>>> news:1178325041....@w5g2000hsg.googlegroups.com...
>>> On May 4, 5:11 pm, Xah Lee <x...@xahlee.org> wrote:
>>>>> How Lisp's Nested Notation Limits The Language's Utility
>>>>> Long time lispers may disagree on this point.
>>>>
>>>>Programming language syntax shouldn't be natural for humans to read.
>>>>Or, rather, this shouldn't be a requirement which creates technical
>>>>compromises.
>>>>
>>> I couldn't disagree more. Occasionally you do need to use a language
>>> with no technical compromises whatsoever - pure assembly or machine
>>> code - but only rarely. Most of the time we accept some limitations for
>>> the sake of making things easier for the human programmer. That includes
>>> run-time efficiency, but also restrictions in the "power" of the
>>> language.
>> [ SNIP ]
>>
>> You two are not referring to the same thing. Syntax is not related to the
>> power of a language (or the lack thereof) in the slightest. Plenty of
>> languages that operate at higher levels than machine code or assembler
>> are just as terse and non-intelligible to the uninformed. Kaz simply made
>> a reference to syntax.
>>
> If we use the term "syntax" in the narrow sense then Kaz's statement is
> nonsense, because syntax is simply the convention for noting the grammar.
> For instance we could use "begin" and "end" instead of '(' and ')' to open
> and close lists, without changing anything fundamental about the language,
> but it wouldn't be a good idea because it would be totally unreadable. A
> change in syntax inherently can't create technical compromises, unless I
> suppose you demand a symbol like $ which might not be available on some
> machines.
I suspect that he was talking about this interpretation of syntax.
> If we use it in the broader sense then we've got something to argue about.
> Let's say that we agree that add(1, 2, 3) is easier to read than (add 1 2
> 3), and we change the underlying representation so that "function calls"
> are separate from "lists". Now we've made the language less tidy at the
> machine level, but we've also given an advantage to the human programmer.
> There is no easy or "right" answer to these questions. My own programming
> language, MiniBasic (see website) makes huge technical compromises, such
> as having only one numerical type, to make the language easier to learn,
> because that is the priority.
In this broad sense you are then talking about grammar, really, because as
you've said, syntax is the notation for the grammar.
Deciding that a variable 'a' can be of any datatype available in the
language, depending on what is assigned to it, is not a syntactical issue -
it's grammatical. Which you know...I'm not trying to tell my grandmother how
to suck eggs.
I think Kaz's point might be best understood by looking at the difference
between J and C and Haskell and Java (or comparable languages). J is pure
line noise - much worse than Perl - but also very powerful. C can be line
noise too (and if you look at Numerical Recipes in C you'll see some
examples), but is much less powerful than J. Perl is C-ish, but has its
forays into line noise, and is intermediate in programming power. Haskell
seems to be very readable (when well written), and is powerful, but some
people just won't like the FP-paradigm...so no Haskell for them. Java -
again when well written - is also very readable, but it's a low to mid-level
language in terms of power...one has to write too much code to get stuff
done in comparison to high-level languages.
Is Prolog easy to read? No. Yet you can do stuff with that which is not
going to happen with a bunch of other languages.
I think that was Kaz' point. Some of the languages I just mentioned make no
particular (or any) attempt to cater to ease of learning, and have syntaxes
that are quite difficult to pick up. Yet they are amongst the most powerful
languages. And the chosen syntax actually promotes the chosen grammar. For
example, people choose J because they want a really concise and powerful
chainsaw, where two lines of J replaces a page of Java...the syntax has to
reflect that. They choose Perl or UNIX shell because they can slap together
a quick and dirty script in 5 minutes, where writing it in C++ would take
hours. Conversely, they may choose C when they want to write an SQL UDF or a
UNIX tool. In the case of Perl, UNIX shell, and C, the ugliness (or
prettiness) of the syntax is roughly comparable - the grammars are highly
different.
AHS
Garry Hodgson
> Tim Bradshaw wrote:
> > Some
> > others do this horrible thing of not allowing that but allowing you to
> > overload the fixed set of special operators (not in the Lisp sense)
> > with other meanings: C++ is a notorious example.
>
> F# also lets you do this and I see it as an advantage.
my experience during many years of c++ is that operator overloading
is a Really Bad Idea. nice in theory, a mess in practice. you'd be
astonished (i was) at the bizarre notions people come up with for
overloading "+", for example ( apple + streetcar yields kangaroo,
while burning a cd as a side effect ).
yes, that's a made up example, but not far off the mark.
overloading would be fine if only sensible people used it,
but compiler technology is insufficiently advanced to
enforce that.
----
Garry Hodgson, Senior Software Geek, AT&T CSO
nobody can do everything, but everybody can do something.
do something.