Hi,
I read on
[http://www.strout.net/python/pythonvslisp.html]
that LISP syntax is superior to algebraic syntax. I have searched some
formal information in this and find some thoughts in the CL FAQ
[http://www.lispniks.com/faq/faq.html]
Whereas i see the point of advantages of something as
(+ (* 1 2) (/ 3 4))
over algebraic
1 * 2 + 3 / 4
-specially when managing dozens of operators- i am unable to see
realistic advantages over infix notation
((1 * 2) + (3 / 4))
Any advice?
Juan R.
Center for CANONICAL |SCIENCE)
Juan R. wrote:
> Whereas i see the point of advantages of something as
>
> (+ (* 1 2) (/ 3 4))
>
> over algebraic
>
> 1 * 2 + 3 / 4
>
> -specially when managing dozens of operators- i am unable to see
> realistic advantages over infix notation
>
> ((1 * 2) + (3 / 4))
>
> Any advice?
Firstly, as others have pointed out, Lisp operators are not all binary.
The familiar arithmetic operators can be called with zero, one, two, or
more arguments.
(+) -> 0
(+ 1) -> 1
(+ 1 1) -> 2
(+ 1 1 1) -> 3
(*) -> 1
(* 2) -> 2
(* 2 2) -> 4
(* 2 2 2) -> 8
Secondly, I would ask: what advantage does ((1 * 2) + (3 / 4)) have if
the operators have to be fully parenthesized? The advantage of infix
notation is brevity, which is made possible by defining associativity
and precedence rules among the operators. This advantage is lost.
There are code formatting problems with a notation like ((1 * 2) + (3 /
4)). You see, Lisp expressions can be very long. For instance a DEFUN
form that defines a function is all one expression. The Lisp syntax
allows a straightforward way to break up long expressions into multiple
lines. Suppose you had to fit the above infix into a space that is,
say, ten character columns wide, how would that look like? Perhaps like
this:
((1 *
2) +
(3 /
4))
But that doesn't read very well. The operators are way out on the right
side, and it's hard to tell at a glance what the primary constituent
is, namely the + operator. Hmm, let's try something else:
((1
* 2)
+ (3
/ 4))
I can't decide whether this is better. Now the notation which factors
out the operator to the left allows for straightforward formatting
rules:
(+ (* 1
2)
(/ 3
4))
Aha! You can read this as a sideways tree! The main constituent, the +
operator, is nicely by itself on the left. You can immediately tell
what its two chilren are a * node and a / node. All of the parallel
constituents line up vertically.
In actual Lisp formatting, there are a few additional stylistic rules
driven by syntax. Given (A B C D E), it can be formatted like this:
(A B
C
D
E)
If B plays a special role in the syntax of the A operator, whereas C, D
... are ordinary expressions. It can be formatted like this:
(A B
C D E)
if A is not an operator at all, but rather (A B C D) is just a list
representing data. Or like this:
(A B C
D E)
if A is an ordinary function and B through E are argument expressions.
Concrete examples:
;; ((x 3)) follows let, then expressions indented over
(let ((x 3))
expr
expr ...)
;; 3 lines up with 1, not list; additional elements
;; indented to line up with that 3.
(list 1 2
3 4)
;; 4 lines up with 1, not 2
(setf x '(1 2 3
4 5 6))
Notice that I haven't even gone into the more substantial advantages,
like how the notation corresponds to convenient abstract syntax tree
structures which make it easy to operate on source code as data.
Kaz Kylheku wrote:
>
> Firstly, as others have pointed out, Lisp operators are not all binary.
> The familiar arithmetic operators can be called with zero, one, two, or
> more arguments.
>
> (+) -> 0
> (+ 1) -> 1
> (+ 1 1) -> 2
> (+ 1 1 1) -> 3
>
> (*) -> 1
> (* 2) -> 2
> (* 2 2) -> 4
> (* 2 2 2) -> 8
Yes i see, but i see not a significant advantage in the 1000 MHz era,
e.g.
(+) = (0 + 0) -> 0
(+ 1) = (0 + 1) -> 1
(+ 1 1) = (1 + 1) -> 2
(+ 1 1 1) = ((1 + 1) + 1)-> 3
Others also differentiate between binary + and unary +.
> Secondly, I would ask: what advantage does ((1 * 2) + (3 / 4)) have if
> the operators have to be fully parenthesized? The advantage of infix
> notation is brevity, which is made possible by defining associativity
> and precedence rules among the operators. This advantage is lost.
I would say so-called algebraic notation is more breve.
Advantage of infix notation is readability. Most people i have asked,
consider more readable and easy to understand
(E = (m * (c ^ 2)))
than
(= E (* m (^ c 2)))
> There are code formatting problems with a notation like ((1 * 2) + (3 /
> 4)). You see, Lisp expressions can be very long.
Mathematicians and scientists work with very long expressions without
problems.
> For instance a DEFUN
> form that defines a function is all one expression. The Lisp syntax
> allows a straightforward way to break up long expressions into multiple
> lines. Suppose you had to fit the above infix into a space that is,
> say, ten character columns wide, how would that look like? Perhaps like
> this:
>
> ((1 *
> 2) +
> (3 /
> 4))
>
> But that doesn't read very well. The operators are way out on the right
> side, and it's hard to tell at a glance what the primary constituent
> is, namely the + operator. Hmm, let's try something else:
>
> ((1
> * 2)
> + (3
> / 4))
>
> I can't decide whether this is better. Now the notation which factors
> out the operator to the left allows for straightforward formatting
> rules:
>
> (+ (* 1
> 2)
> (/ 3
> 4))
( (1
*
2)
+
(3
/
4))
> Aha! You can read this as a sideways tree! The main constituent, the +
> operator, is nicely by itself on the left. You can immediately tell
> what its two chilren are a * node and a / node. All of the parallel
> constituents line up vertically.
Yes, i can see your point here.
> In actual Lisp formatting, there are a few additional stylistic rules
> driven by syntax. Given (A B C D E), it can be formatted like this:
>
> (A B
> C
> D
> E)
>
> If B plays a special role in the syntax of the A operator, whereas C, D
> ... are ordinary expressions. It can be formatted like this:
>
> (A B
> C D E)
>
> if A is not an operator at all, but rather (A B C D) is just a list
> representing data. Or like this:
>
> (A B C
> D E)
>
> if A is an ordinary function and B through E are argument expressions.
>
> Concrete examples:
>
> ;; ((x 3)) follows let, then expressions indented over
>
> (let ((x 3))
> expr
> expr ...)
>
> ;; 3 lines up with 1, not list; additional elements
> ;; indented to line up with that 3.
> (list 1 2
> 3 4)
>
> ;; 4 lines up with 1, not 2
> (setf x '(1 2 3
> 4 5 6))
>
> Notice that I haven't even gone into the more substantial advantages,
> like how the notation corresponds to convenient abstract syntax tree
> structures which make it easy to operate on source code as data.
Thanks by these interesting data and thoughts!
Juan R.
Center for CANONICAL |SCIENCE)
Juan R. wrote:
> Kaz Kylheku wrote:
> >
> > Firstly, as others have pointed out, Lisp operators are not all binary.
> > The familiar arithmetic operators can be called with zero, one, two, or
> > more arguments.
> >
> > (+) -> 0
> > (+ 1) -> 1
> > (+ 1 1) -> 2
> > (+ 1 1 1) -> 3
> >
> > (*) -> 1
> > (* 2) -> 2
> > (* 2 2) -> 4
> > (* 2 2 2) -> 8
>
> Yes i see, but i see not a significant advantage in the 1000 MHz era,
I don't follow this. I typed as fast on a 10 Mhz workstation as I do
today, and could flip already flip through pages of ASCII text without
much of a perceptible delay.
> e.g.
>
> (+) = (0 + 0) -> 0
> (+ 1) = (0 + 1) -> 1
> (+ 1 1) = (1 + 1) -> 2
> (+ 1 1 1) = ((1 + 1) + 1)-> 3
One advantage is that if you have many terms to add which are all long,
it nicely looks like this:
(+ (term1 ... )
(term2 ...)
(term3 ...)
...)
At a glance, you know that all of the constituents are being added.
But of course, the real point is not that variadic + is some kind of
advantage. I was just underscoring that the parentheses in Lisp are not
exactly the same thing as parentheses in infix. You cannot remove these
Lisp parentheses without constraining the number of arguments that
operators can take.
Writing the operators in between can be a disadvantage. That is perhaps
why we have vector and matrix notations. Instead of
a + 2b + 3c + 4d
you can just write a dot product:
T
[a b c d] [1 2 3 4]
But of course the real point is not that a multiplication with 20
arguments is some huge advantage; we just bring that up to illustrates
that the notation isn't just a trivial rearrangement of parenthesized
infix. There are operators where it is an overwhelming advantage to
have variable arguments; namely, in the implementation of
statement-like syntax:
(cond pair1 pair2 ... pairN)
(case expr clause1 clause2 ... clauseN)
(when condition expr1 expr2 ... exprN)
(progn expr1 expr2 ... exprN)
Almost without exception, most of the popular programming languages
have some kind of prefix-based syntax for handling declarations,
statements, control structures and the like. Infix expressions may
appear in specific places in the syntax that is generated by this main
skeleton.
Using Cambridge prefix notation, the expressions can use the same
syntax as the other material, which is an advantage in situations where
the division between expressions and everything else is artificial. If
the syntax of the language is programmable by the user, then it's a
meaningless division, because it's tied to hard-wired semantics. A
statement is syntax which represents the sequencing and control of
evaluation, whereas an expression is syntax which denotes the
production of a value. Under the hood, so to speak, these just produce
nodes in an abstract syntax tree.
> Others also differentiate between binary + and unary +.
Binary arithmetic operators indeed make it easier to do polymorphism:
defining different kinds of addtion under the same operator, based on
type or other attributes of the operands. The type dispatch has to only
take care of pairs of operand types.
In Lisp, if you want to introduce a new kind of number, there is a
difficulty in that + isn't a generic function. Moreover, generic
functions can only have a fixed number of class-specializable
parameters.
What you can do is define your own package in which there is a binary
operator that is a generic function. And then, also define a regular
function + which implements the variable-argument fold over that
generic function, perhaps by means of REDUCE.
But sometimes binary functions have disadvantages. Suppose you are
multiplying chains of matrices: A1 * A2 ... * AN. If the
multiplication operator is strictly binary, with left-to-right
associativity, that could lead to a poor running time. On the other
hand, automatic optimizations with respect to operation order are
foolish and dangerous when you're dealing with floating point. A
multi-argument * could, in principle, handle both requirements:
(* A1 A2 ... AN) ;; multiply in efficient order
(* ... (* (* A1 A2) A3) ... AN) ;; multiply in this order
The thing is, once you have a language defined entirely by this prefix
notation, there is no reason /not/ to have a + operator that takes
zero, one, two or many arguments. It's not the justification for having
that notation, but only a side-effect.
Why make people write (+ (+ (+ x y) z) w) when your notation supports
an easy way for designing an operator which avoids that.
> Advantage of infix notation is readability. Most people i have asked,
> consider more readable and easy to understand
... unsurprisingly, whatever notation has been drilled into their heads
since kindergarten, such as:
> (E = (m * (c ^ 2)))
>
> than
>
> (= E (* m (^ c 2)))
... and moreover, the above example is biased toward infix, because
it's tiny and fits onto one line.
So there are two serious biases in this survey; and just one is needed
to dismiss it as invalid congnitive research.
> > There are code formatting problems with a notation like ((1 * 2) + (3 /
> > 4)). You see, Lisp expressions can be very long.
>
> Mathematicians and scientists work with very long expressions without
> problems.
That is only the popular image of the mathematician and scientist. They
have plenty of problems, and those expressions are not nearly as large
as what we grapple with in software. Moreover, those problems that
mathematicians grapple with would be entirely unacceptable if they
carried over into software development.
Think about it for a second. How do mathematicians work with
expressions? Using what tools? For what purpose? And how does that
differ from how software developers work with expressions?
The notations of mathematics are two dimensional. Elements are related
together not just by left and right position, but in vertical and
diagonal directions. The sigma notation for summation has a syntax
which places a constituent expression above the symbol, below the
symbol and to the right. The structure of an expression is shown by
recursively subdividing the space. The size of some of the elements can
be adjusted; a more major element takes up more of the space and is
larger. For instance, parentheses can grow vertically to enclose an
arbitrarily tall vertical expression.
The expression notations used in computer programming languages do not
have these these features. That is because the medium in which they are
written is simply ASCII characters which are read left to right, and
then top to bottom. The only typesetting features are line breaks and
horizontal space. Moreover, for the sake of alignment, there is usually
the requirement that all characters, including spaces, must render with
equal width. Most source code depends on this fixed width to some
extent: any alignment after the first non-whitespace character in a
line of code relies on fixed-with kerning. For instance, this
expression relies on it:
(list 1 2
3 4)
In a proportional font, the 1 and 3 will not reliably line up.
In this thread, we are /hopefully/ discussing the Lisp prefix notation
(a.ka. "Cambridge prefix") strictly in the context of computer
programming, where notations are rendered using the above writing
system. Nobody is insinuating that Cambridge prefix should replace the
rich, two-dimensional notation that is used for publishing mathematics.
Mathematicians these days do their own typesetting, which means they
typically struggle with multiple representations of the same formulas.
Neither the markup languages for quality math typesetting, nor the
representations used by WYSIWYG math editors are suitable for actually
manipulating those formulas symbolically. So what the mathematician
might do is do the symbolic computing in a different representation
entirely. The symbolic computing software package will then output the
near typeset-quality math using the markup as a write-only target
language.
Needless to say, in software we are concerned with the primary product
being easy to read and manipulate, even if it is large and complex, and
the source code is the primary product. It's where you make changes if
the requirements change or if defects are found. The source code is
what is put into a version control system and subject to diff-ing and
merging. It's what we use to communicate with the machine and with
each other; there is no other notation. When a computer program does
happen to be published in a formal paper, it's usually put into a
fixed-width typewriter font, shown exactly as it appears on the screen:
the actual program, identical to what is fed to the computer. The
formal publication of a program among computer scientists and
programmers is essentially the same as the informal communication among
the same people. This is not true among mathematicians, who these days
e-mail each other TeX snippets, or the source input language to their
favorite mathematics software, or some informal mixture of the two.
It's nothing like what they actually publish.
Kaz Kylheku wrote:
First i would repeat again that
1) I misinterpreted the claim done in the link that i cited initially,
which was a bit ambiguous suggesting prefix notation was better than
mathematical notation, when it is really related to the own LISP
structure. Now i understand why attempts to introduce Algol-like or
infix notation into LISP were not popular.
2) My posting here was not an attack to LISP even if some people
believed it. I have defended LISP and Scheme in many places (e.g.
suggested usage of Scheme and SXML in a recent xml-dev). I am basing my
own work in SXML, but am not adopting a full LISP or Scheme by reasons
are of no interest here.
Now i will reply
> One advantage is that if you have many terms to add which are all long,
> it nicely looks like this:
>
> (+ (term1 ... )
> (term2 ...)
> (term3 ...)
> ...)
This is not against infix.
> Writing the operators in between can be a disadvantage. That is perhaps
> why we have vector and matrix notations. Instead of
>
> a + 2b + 3c + 4d
>
> you can just write a dot product:
>
> T
> [a b c d] [1 2 3 4]
Former is the result and latter the operation, somewhat as 4 is not a
notation for (+ 2 2)
> But of course the real point is not that a multiplication with 20
> arguments is some huge advantage; we just bring that up to illustrates
> that the notation isn't just a trivial rearrangement of parenthesized
> infix. There are operators where it is an overwhelming advantage to
> have variable arguments; namely, in the implementation of
> statement-like syntax:
>
> (cond pair1 pair2 ... pairN)
>
> (case expr clause1 clause2 ... clauseN)
>
> (when condition expr1 expr2 ... exprN)
>
> (progn expr1 expr2 ... exprN)
>
> Almost without exception, most of the popular programming languages
> have some kind of prefix-based syntax for handling declarations,
> statements, control structures and the like. Infix expressions may
> appear in specific places in the syntax that is generated by this main
> skeleton.
Yes i see but i already explained my formal approach.
> But sometimes binary functions have disadvantages. Suppose you are
> multiplying chains of matrices: A1 * A2 ... * AN. If the
> multiplication operator is strictly binary, with left-to-right
> associativity, that could lead to a poor running time.
Maybe
> On the other
> hand, automatic optimizations with respect to operation order are
> foolish and dangerous when you're dealing with floating point. A
> multi-argument * could, in principle, handle both requirements:
>
> (* A1 A2 ... AN) ;; multiply in efficient order
>
> (* ... (* (* A1 A2) A3) ... AN) ;; multiply in this order
>
> The thing is, once you have a language defined entirely by this prefix
> notation, there is no reason /not/ to have a + operator that takes
> zero, one, two or many arguments.
Yes, i agree. I already explained my point about operations. somehat as
prefix is firmly based in binary trees, my emphasis in binary
FUNDAMENTAL operations is mainly based in the link with Keizer vectors
and the fact that a+b --> c is fundamental in Nature but a+b+c --> d is
not and one use special notation a+b+c ==> d. I could talk about
ternary and n-ary operations in the same way that i talk about ternary
and n-ary operations in theoretical chemistry.
> Why make people write (+ (+ (+ x y) z) w) when your notation supports
> an easy way for designing an operator which avoids that.
Distinction micro-macro is not applicable to LISP but to CanonML. LISP
works at macroscopic (classical) level. There is other requirements
applicable to i am working. In some sense i am working in a
computerized version of Keizer formalism
LISP is great for (+ x y z w) as (+ (+ (+ x y) z) w). But there x y z
and w have got certain concrete mathematical meaning and result is
equivalent. In chemistry,
(+ x y z w)
(+ (+ (+ x y) z) w)
and
(+ (+ x y) (+ z w)
are not necesarily the same operation when x, y, z, and w are points in
the chemical phase space.
> > Advantage of infix notation is readability. Most people i have asked,
> > consider more readable and easy to understand
>
> ... unsurprisingly, whatever notation has been drilled into their heads
> since kindergarten, such as:
I never found a serious study on this, just beliefs on pro or contra. I
personally believe that there is perception rules favouring infix
notation.
> > (E = (m * (c ^ 2)))
> >
> > than
> >
> > (= E (* m (^ c 2)))
>
> ... and moreover, the above example is biased toward infix, because
> it's tiny and fits onto one line.
Read above.
> That is only the popular image of the mathematician and scientist. They
> have plenty of problems, and those expressions are not nearly as large
> as what we grapple with in software. Moreover, those problems that
> mathematicians grapple with would be entirely unacceptable if they
> carried over into software development.
Mathematicians, enginneers, and scientists know prefix notation for
decades. If was so good, it would be used elsewhere.
> Think about it for a second. How do mathematicians work with
> expressions? Using what tools? For what purpose? And how does that
> differ from how software developers work with expressions?
For each prefix oriented software i see a guy trying to implement an
infix version.
> In this thread, we are /hopefully/ discussing the Lisp prefix notation
> (a.ka. "Cambridge prefix") strictly in the context of computer
> programming, where notations are rendered using the above writing
> system. Nobody is insinuating that Cambridge prefix should replace the
> rich, two-dimensional notation that is used for publishing mathematics.
Yes, i already recognized my error in the interpretation of the link i
cited in my first message, which read ambiguous,
<blockquote>
One could argue that LISP syntax, despite being unconventional and
therefore difficult for beginners to learn and use, is somehow superior
to algebraic syntax. (Indeed, LISP programmers often argue exactly
this.)
</blockquote>
which could be interpreted as LISP syntax is somehow superior to
algebraic syntax of mathematics.
Please note also that i am working with a system may be good enough for
*both* typpeseting of documents and computer programming.
For example, i already recognized that something as (+ 2 3) is a bit
easier to parse by as computer, but that easiness ir lost when your
system may be able to typeset full mathematical articles instead just
returing 4 when evaluating the code.
> Mathematicians these days do their own typesetting, which means they
> typically struggle with multiple representations of the same formulas.
> Neither the markup languages for quality math typesetting, nor the
> representations used by WYSIWYG math editors are suitable for actually
> manipulating those formulas symbolically.
Therein i rejected TeX or ASCIIMath from the very beggining.
TeX is very good for typesseting. LISP is very good for symbolic
computation. i am trying to unitte both worlds and if i fail in the
end, at least people can learn from my errors.
For example, initially i copied some points from the SGML/XML world but
recently it turned into a bad choice and CanonML became more
"funtional-oriented" copying more features from TeX and S(cheme)XML.
I think that this thread can be closed since my initial emphasis was on
advantages of LISP prefix syntax, and now i see that most of advantages
apply only on a LISP environment: editing, CAR and CDRs, eval, macros,
parsing, and all that stuff.
Thanks again!
Juan R.
Center for CANONICAL |SCIENCE)
"Juan R." <··············@canonicalscience.com> writes:
> Yes i see, but i see not a significant advantage in the 1000 MHz era,
I don't see how that is relevant
> e.g.
>
> (+) = (0 + 0) -> 0
Are you seriously arguing that having to write (0 + 0) is superior to
(+)? On what grounds?
> (+ 1) = (0 + 1) -> 1
Why is (0 + 1) superior to (+ 1)?
More to the point, would you consider having to write (0 - 1) better
than (- 1)?
> Others also differentiate between binary + and unary +.
How? What is the basis for figuring this out?
> > Secondly, I would ask: what advantage does ((1 * 2) + (3 / 4)) have if
> > the operators have to be fully parenthesized? The advantage of infix
> > notation is brevity, which is made possible by defining associativity
> > and precedence rules among the operators. This advantage is lost.
>
> I would say so-called algebraic notation is more breve.
Well
> Advantage of infix notation is readability.
^^^^^^^^^^^
familiarity
Don't confuse familiarity with readability.
> Most people i have asked,
> consider more readable and easy to understand
>
> (E = (m * (c ^ 2)))
>
> than
>
> (= E (* m (^ c 2)))
How many people that you asked are able to tell you what E, m and c
stand for?
And what happens when you have longer, more descriptive variables?
What about comparing
(energy = (mass-of-some-particle * (the-speed-of-light-in-a-vacuum ^ 2)))
(= energy (* mass-of-some-particle (^ the-speed-of-light-in-a-vacuum 2)))
Once you start getting into longer names for variables, the infix
advantage of familiarity begins to disappear, until you really start
losing sight of things. In particular, in the last part of the
expression, you have to look over quite a ways before you actually
discover the really tiny exponentiation symbol. Without parentheses,
the structure would be a lot harder to figure out.
>
> > There are code formatting problems with a notation like ((1 * 2) + (3 /
> > 4)). You see, Lisp expressions can be very long.
>
> Mathematicians and scientists work with very long expressions without
> problems.
They tend not to work with very long variable names, though.
--
Thomas A. Russ, USC/Information Sciences Institute
Thomas A. Russ wrote:
> "Juan R." <··············@canonicalscience.com> writes:
>
> > Yes i see, but i see not a significant advantage in the 1000 MHz era,
>
> I don't see how that is relevant
>
> > e.g.
> >
> > (+) = (0 + 0) -> 0
>
> Are you seriously arguing that having to write (0 + 0) is superior to
> (+)? On what grounds?
No! i do not said that.
> > (+ 1) = (0 + 1) -> 1
>
> Why is (0 + 1) superior to (+ 1)?
I do not said that.
> More to the point, would you consider having to write (0 - 1) better
> than (- 1)?
No!
> > Others also differentiate between binary + and unary +.
>
> How? What is the basis for figuring this out?
Sorry i mean unary and binary -.
In LISP you write (-1) or (- 3 1) and the "-" symbol is the same. In
OpenMath, you find
<OMS cd="arith1" name="unary_minus"/>
for the first symbol (OMS means OpenMathSymbol) and
<OMS cd="arith1" name="minus"/>
for the other. I do not know the rationale for it.
> > Advantage of infix notation is readability.
> ^^^^^^^^^^^
> familiarity
>
> Don't confuse familiarity with readability.
I am not convinced about this.
> > Most people i have asked,
> > consider more readable and easy to understand
> >
> > (E = (m * (c ^ 2)))
> >
> > than
> >
> > (= E (* m (^ c 2)))
>
> How many people that you asked are able to tell you what E, m and c
> stand for?
()
> And what happens when you have longer, more descriptive variables?
>
> What about comparing
>
> (energy = (mass-of-some-particle * (the-speed-of-light-in-a-vacuum ^ 2)))
>
> (= energy (* mass-of-some-particle (^ the-speed-of-light-in-a-vacuum 2)))
>
> Once you start getting into longer names for variables, the infix
> advantage of familiarity begins to disappear, until you really start
> losing sight of things. In particular, in the last part of the
> expression, you have to look over quite a ways before you actually
> discover the really tiny exponentiation symbol. Without parentheses,
> the structure would be a lot harder to figure out.
I asked with the whole expressions
[::energy = [::mass ::* [::light-speed ::^ 2] ]]
[= ::energy [::* ::mass [::^ ::light-speed 2] ]]
as contained in canonical science today.
>
> >
> > > There are code formatting problems with a notation like ((1 * 2) + (3 /
> > > 4)). You see, Lisp expressions can be very long.
> >
> > Mathematicians and scientists work with very long expressions without
> > problems.
>
> They tend not to work with very long variable names, though.
But is not due to infix notation but commodity.
Also old LISP (PLUS (TIMES A B) C)
is now written as (+ (* A B) C)
See also this link
[http://www.paulgraham.com/arclessons.html]
Juan R.
Center for CANONICAL |SCIENCE)
Juan R. wrote:
very bad!
> No! i do not said that.
"I did not say that."
> > > (+ 1) = (0 + 1) -> 1
> >
> > Why is (0 + 1) superior to (+ 1)?
>
> I do not said that.
Same error "I did not say that."
> In LISP you write (-1) or (- 3 1) and the "-" symbol is the same. In
> OpenMath, you find
It is (- 1).
Juan R.
Center for CANONICAL |SCIENCE)
From: Marco Baringer
Subject: Re: Why is LISP syntax superior?
Date:
Message-ID: <m2fyhw9bsc.fsf@bese.it>
"Juan R." <··············@canonicalscience.com> writes:
> -specially when managing dozens of operators- i am unable to see
> realistic advantages over infix notation
>
> ((1 * 2) + (3 / 4))
(+ (* 1 2 3) (/ 4 5 6) (- 7 8 9))
ok, this isn't the best thing since sliced bread, but it's still
pretty nice, espcially when used with comparision functions:
(<= min x max)
as opposed to
((min <= x) and (x <= max)).
of course, if you want infix it's easy enough to get it:
http://www-cgi.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/lisp/code/syntax/infix/0.html
> Any advice?
it's all about uniformity and what comes from that. lisp's syntax is
extremly simple to explain and extend. since functions, operators and
macros are all treated the same it's easy to write code which
manipulates other code (there is a reason this is done so often in
lisp and not in python, even though both have, on paper at least, the
same possibilities).
--
-Marco
Ring the bells that still can ring.
Forget your perfect offering.
There is a crack in everything.
That's how the light gets in.
-Leonard Cohen
Marco Baringer wrote:
> "Juan R." <··············@canonicalscience.com> writes:
>
> > -specially when managing dozens of operators- i am unable to see
> > realistic advantages over infix notation
> >
> > ((1 * 2) + (3 / 4))
>
> (+ (* 1 2 3) (/ 4 5 6) (- 7 8 9))
>
> ok, this isn't the best thing since sliced bread, but it's still
> pretty nice, espcially when used with comparision functions:
>
> (<= min x max)
>
> as opposed to
>
> ((min <= x) and (x <= max)).
>
> of course, if you want infix it's easy enough to get it:
Yes, i see your point but i am not claiming that all-infix was better.
Just asking for more data on why in LISP all-prefix matters.
> http://www-cgi.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/lisp/code/syntax/infix/0.html
>
> > Any advice?
>
> it's all about uniformity and what comes from that. lisp's syntax is
> extremly simple to explain and extend. since functions, operators and
> macros are all treated the same it's easy to write code which
> manipulates other code (there is a reason this is done so often in
> lisp and not in python, even though both have, on paper at least, the
> same possibilities).
I have heard this point before, for example that in prefix notation,
parser is able to find operator in a simple way. I understand that in
(+ 2 3), parser find + and apply it to arguments 2 and 3. But the
parse still may be able to analize things as (8 4) and 8 there is not
an operator. Therefore, i think that to write a code is able to
understand (2 + 3) may be not different from code for understand (8 4)
simply analize each list until find a command.
Yes, all-prefix could be more uniform, but also more difficult to read
and is suspect reason for infix macros and special editors.
Juan R.
Center for CANONICAL |SCIENCE)
In article <························@p79g2000cwp.googlegroups.com>,
"Juan R." <··············@canonicalscience.com> wrote:
> Marco Baringer wrote:
> > "Juan R." <··············@canonicalscience.com> writes:
> >
> > > -specially when managing dozens of operators- i am unable to see
> > > realistic advantages over infix notation
> > >
> > > ((1 * 2) + (3 / 4))
> >
> > (+ (* 1 2 3) (/ 4 5 6) (- 7 8 9))
> >
> > ok, this isn't the best thing since sliced bread, but it's still
> > pretty nice, espcially when used with comparision functions:
> >
> > (<= min x max)
> >
> > as opposed to
> >
> > ((min <= x) and (x <= max)).
> >
> > of course, if you want infix it's easy enough to get it:
>
> Yes, i see your point but i am not claiming that all-infix was better.
> Just asking for more data on why in LISP all-prefix matters.
It's easier to parse. For any call, the function name is always the CAR
for the form and the arguments are always the CDR of the form. This is
true regardless of the arity of the function. So:
(SIN X)
(SUM X Y)
(SUM X Y Z Q R S)
can all be treated uniformly.
If you have infix your parsing job is much harder, and in some cases
flatly ambiguous. Consider:
(X Y Z)
Is that the operator Y being applied to arguments X and Z, or the
two-argument function X being called on arguments Y and Z?
Then consider these two cases:
(X * Y)
(MAPCAR * Y)
rg
Ron Garret wrote:
> It's easier to parse. For any call, the function name is always the CAR
> for the form and the arguments are always the CDR of the form. This is
> true regardless of the arity of the function. So:
>
> (SIN X)
> (SUM X Y)
> (SUM X Y Z Q R S)
>
> can all be treated uniformly.
Yes. I am working in a meta language for documentation (beyond XML) and
three examples would be treated equal. I do not use binary trees.
> If you have infix your parsing job is much harder, and in some cases
> flatly ambiguous. Consider:
>
> (X Y Z)
>
> Is that the operator Y being applied to arguments X and Z, or the
> two-argument function X being called on arguments Y and Z?
Yes, i was trained this was one of advantages of LISP in symbolic
computation. However, i am based in p-MathML and unknown
operators/functions are explicitely marked
(X ::Y Z)
vs
(::X Y Z)
:: play the role of <mo> in p-MathML
A similar approach is used in TeX but with other notation
{X \Y Z}
vs
{\X Y Z}
e.g.
{a \over 2}
and
{\displaystyle A B}
Juan R.
Center for CANONICAL |SCIENCE)
Juan R. wrote:
> Yes, all-prefix could be more uniform, but also more difficult to read
> and is suspect reason for infix macros and special editors.
That suspect reason is wrong. The reason we have an infix macro in Lisp
is simply because someone decided to hack one up. In reality, hardly
anyone uses it. Once newbies know that it's there if they want it, they
stop wanting it.
You would have a valid point there if there was actually a wide-spread
use of the infix macro in Lisp programming, which there isn't, in spite
of its high portability and ease of installation.
About those special editors, they are /enabled/ by that syntax to do
things which are difficult or impossible with other syntaxes.
Kaz Kylheku wrote:
> Juan R. wrote:
> > Yes, all-prefix could be more uniform, but also more difficult to read
> > and is suspect reason for infix macros and special editors.
>
> That suspect reason is wrong. The reason we have an infix macro in Lisp
> is simply because someone decided to hack one up. In reality, hardly
> anyone uses it. Once newbies know that it's there if they want it, they
> stop wanting it.
>
> You would have a valid point there if there was actually a wide-spread
> use of the infix macro in Lisp programming, which there isn't, in spite
> of its high portability and ease of installation.
>
> About those special editors, they are /enabled/ by that syntax to do
> things which are difficult or impossible with other syntaxes.
Thanks by correction. However i do not think that my point was
correctly wrong. Initial reason for the introduction of infix macros
was because some people dislike all-prefix. That was also part of
rationale for Algol-syntax versions of LISP that people generated but
never were accepted.
Currently, i am collaborating in discussion of next HTML5 and several
mathematicians blamed me that either one provides TeX quality rendering
for online mathematics in HTML5 or most of them will continue to use
GIFs. They exprressed that math was hard enough and readability was a
point -that is reason for popularity of TeX in mathematician
community-.
Similar thoutghs apply to infix notation and reason that mathematicians
continue writting (2 + 3) instead (+ 2 3) and developing new concepts
as recent star product of non-commutative geometry; again they write (f
star g) and not (star f g).
If prefix notation was so clearly superior all mathemtics would be done
in prefix way and all calculators would be as that from HP.
Similar thouths apply to science. Chemists write (Reactants =>
Products) instead (=> Reactants Products)
Juan R.
Center for CANONICAL |SCIENCE)
Juan R. wrote:
> Kaz Kylheku wrote:
> If prefix notation was so clearly superior all mathemtics would be done
> in prefix way and all calculators would be as that from HP.
Not really. Humans tend to do things they are used to. There is not a
clear relation between what a better thing is and what a thing used by
many people is.
For example, in year 1200, everybody believed that earth was plannar.
Was that correct? Why not, if everybody believed that?
Just read what others said to you, and you'll understand why prefix
notation is better. Another thing is if you don't like it!
Javier wrote:
> Juan R. wrote:
> > Kaz Kylheku wrote:
> > If prefix notation was so clearly superior all mathemtics would be done
> > in prefix way and all calculators would be as that from HP.
>
> Not really. Humans tend to do things they are used to. There is not a
> clear relation between what a better thing is and what a thing used by
> many people is.
> For example, in year 1200, everybody believed that earth was plannar.
> Was that correct? Why not, if everybody believed that?
Today physicists and chemists know that (a + b + c) is a approximation
and only binary matters, what mean that Nature dislike unary and
ternary "LISP" operators?
There are other disavantages to the usage of prefix notation in my
work. For example in publishing.
Another example of why all-prefix is not always good is in LISTS
(a b c d) is notation for (a , b , c, d) is notation for
(a.(b.(c.(d.nil))))
spaces, "," or "." are all infix.
> Just read what others said to you, and you'll understand why prefix
> notation is better. Another thing is if you don't like it!
Well i read and replied with some thougths from mine.
Juan R.
Center for CANONICAL |SCIENCE)
Stop trolling. If you like infix notation, just use it.
If before entering into this discussión, you knew that you don't agree
with prefix notation, what are you pretending? Entering comp.alt.lisp
and force everybody to agree with your affirmations?
Javier wrote:
> Stop trolling. If you like infix notation, just use it.
> If before entering into this discussión, you knew that you don't agree
> with prefix notation, what are you pretending? Entering comp.alt.lisp
> and force everybody to agree with your affirmations?
This is an educated debate. I do not like debate just ignore this
thread.
I personally do not like all-prefix notation, but that is just a matter
of taste.
I clearly asked for formal proof on why prefix notation is better and i
asked because in the links i cited in my first message had some stuff
about that.
I have heard arguments and proposed some informal answers. Nobody would
call that "trolling".
Juan R.
Center for CANONICAL |SCIENCE)
Juan R. wrote:
> Javier wrote:
> > Stop trolling. If you like infix notation, just use it.
> > If before entering into this discussión, you knew that you don't agree
> > with prefix notation, what are you pretending? Entering comp.alt.lisp
> > and force everybody to agree with your affirmations?
>
> This is an educated debate. I do not like debate just ignore this
> thread.
>
Would read
If you do not like debate just ignore this thread.
Juan R.
Center for CANONICAL |SCIENCE)
From: Christian Haselbach
Subject: Re: Why is LISP syntax superior?
Date:
Message-ID: <e7k148$tsd$1@online.de>
Juan R. schrieb:
> I clearly asked for formal proof on why prefix notation is better and i
> asked because in the links i cited in my first message had some stuff
> about that.
If you want a formal prove/answer, you need to provide a formal
problem/question. In this case this would require a formal definition of
the comparison "better" and the set of elements it has to be the best
of. This set would probably contain prefix, infix, and postfix notations.
There is no such thing as an infix-only notation, because an infix
function has always exactly two arguments. Hence, if you use infix
notation, you alway have to use prefix or postfix notation, too. Or you
have to restrict the signature of your functions to take exactly two
arguments and return exactly one value. While one can argue that this is
the case for the typical ML language, I know of no language that has a
strict infix notation. Prefix and postfix notation on the other hand are
complete. Note: I am still not arguing if a certain notation is better.
Infix notation does not reduce the number of parentheses: (+ 2 (* 5 8))
has the same number of parentheses as (2 + (5 * 8)). Conventions to
reduce parentheses do reduce the number of parentheses. However, these
conventions can be established for infix, postfix, and prefix notation
alike. However, these rules have to be formulated carefully to avoid
ambiguity.
Another property of a notation is whether the arity of a function has to
be fix (e.g., C) or not (e.g., CL).
Hence, the set of possible notations is pretty large.
The question whether a notation is better than another certainly depends
on these properties (i.e., the properties above and many others) but
also on external properties (e.g., what is the notation used for).
However, on can argue that CL's notation has certain advantages. For
example the fact that ambiguity is absolutely no issue (even though
function arity does not have to be fix). In a related note: the compiler
has to know the parentheses reduction conventions. This is often hard
coded. In this case the programmer cannot add to these conventions. As a
consequence, most languages that have an infix notation do not allow the
programmer to add infix functions. In Haskell there is a formalism to
add functions to these conventions. This is neat, but also is a further
source of errors. Furthermore, the programmer has to know the
conventions and needs to apply them correctly.
Regards,
Christian
Christian Haselbach wrote:
> Juan R. schrieb:
> > I clearly asked for formal proof on why prefix notation is better and i
> > asked because in the links i cited in my first message had some stuff
> > about that.
>
> If you want a formal prove/answer, you need to provide a formal
> problem/question. In this case this would require a formal definition of
> the comparison "better" and the set of elements it has to be the best
> of. This set would probably contain prefix, infix, and postfix notations.
Simply i read a link and asked for more information. Information of a
formal nature rather than i like/dislike prefix. Several answers in
formal properties of prefix notation were introduced and now i
understand better.
Initially i thought that link is claiming that LISP syntax was better
than mathematical one (always; this was my misunderstanding). Now i
think that LISPers really claim that LISP syntax is better for LISP.
For example (+ 2 3) is better than (2 + 3) because formal properties of
SEXPR. + is the head and 2 3 the arguments. However, this is not
applicable to my own approach (is not LISP).
Thanks!
> There is no such thing as an infix-only notation, because an infix
> function has always exactly two arguments. Hence, if you use infix
> notation, you alway have to use prefix or postfix notation, too. Or you
> have to restrict the signature of your functions to take exactly two
> arguments and return exactly one value. While one can argue that this is
> the case for the typical ML language, I know of no language that has a
> strict infix notation. Prefix and postfix notation on the other hand are
> complete. Note: I am still not arguing if a certain notation is better.
I already explained as prefix and postif are special cases of parser
searching infix construct in my case.
> Infix notation does not reduce the number of parentheses: (+ 2 (* 5 8))
> has the same number of parentheses as (2 + (5 * 8)). Conventions to
> reduce parentheses do reduce the number of parentheses. However, these
> conventions can be established for infix, postfix, and prefix notation
> alike. However, these rules have to be formulated carefully to avoid
> ambiguity.
>
> Another property of a notation is whether the arity of a function has to
> be fix (e.g., C) or not (e.g., CL).
>
> Hence, the set of possible notations is pretty large.
>
> The question whether a notation is better than another certainly depends
> on these properties (i.e., the properties above and many others) but
> also on external properties (e.g., what is the notation used for).
>
> However, on can argue that CL's notation has certain advantages. For
> example the fact that ambiguity is absolutely no issue (even though
> function arity does not have to be fix). In a related note: the compiler
> has to know the parentheses reduction conventions. This is often hard
> coded. In this case the programmer cannot add to these conventions. As a
> consequence, most languages that have an infix notation do not allow the
> programmer to add infix functions. In Haskell there is a formalism to
> add functions to these conventions. This is neat, but also is a further
> source of errors. Furthermore, the programmer has to know the
> conventions and needs to apply them correctly.
Juan R.
Center for CANONICAL |SCIENCE)
Juan R. wrote:
>
> I clearly asked for formal proof on why prefix notation is better and i
> asked because in the links i cited in my first message had some stuff
> about that.
A proof is nothing more than a persuasive argument. What criteria are
you using to judge whether prefix notation is `better'? If we knew
that, then perhaps we would be able to persuade you. Or perhaps not.
Joe Marshall wrote:
> Juan R. wrote:
> >
> > I clearly asked for formal proof on why prefix notation is better and i
> > asked because in the links i cited in my first message had some stuff
> > about that.
>
> A proof is nothing more than a persuasive argument. What criteria are
> you using to judge whether prefix notation is `better'? If we knew
> that, then perhaps we would be able to persuade you. Or perhaps not.
Thanks to the comments here posted I already understood that prefix
notation is an advantage for LISP, due to own formal properties of the
language (e.g. binary trees, macros). Now, I understand better why any
sistematic approach to change LISP syntax by an Algol-like or infix one
has failed to obtain popularity in your community.
Together, I am able to see that advantages of prefix notation are
absent in others approaches and reason I do not need to follow LISP at
this point.
Juan R.
Center for CANONICAL |SCIENCE)
On Mon, 26 Jun 2006 18:45:14 +0200, Joe Marshall <··········@gmail.com>
wrote:
>
> Juan R. wrote:
>>
>> I clearly asked for formal proof on why prefix notation is better and i
>> asked because in the links i cited in my first message had some stuff
>> about that.
>
> A proof is nothing more than a persuasive argument. What criteria are
> you using to judge whether prefix notation is `better'? If we knew
> that, then perhaps we would be able to persuade you. Or perhaps not.
>
A proof is a lot more than a persuasive argument.
For one thing it has to be verified by three independent mathematicians.
Then it has to stand the test of time.
I am not saying that mathematical proof is absolute.
Just that we try to set the bar higher than, say, in politics.
The minute you hear a word like 'better' it relates to taste.
No one has ever proven one language is 'better' than another.
John
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
John Thingstad wrote:
> On Mon, 26 Jun 2006 18:45:14 +0200, Joe Marshall <··········@gmail.com>
> wrote:
>
> >
> > Juan R. wrote:
> >>
> >> I clearly asked for formal proof on why prefix notation is better and i
> >> asked because in the links i cited in my first message had some stuff
> >> about that.
> >
> > A proof is nothing more than a persuasive argument. What criteria are
> > you using to judge whether prefix notation is `better'? If we knew
> > that, then perhaps we would be able to persuade you. Or perhaps not.
> >
>
> A proof is a lot more than a persuasive argument.
> For one thing it has to be verified by three independent mathematicians.
> Then it has to stand the test of time.
> I am not saying that mathematical proof is absolute.
> Just that we try to set the bar higher than, say, in politics.
>
> The minute you hear a word like 'better' it relates to taste.
> No one has ever proven one language is 'better' than another.
>
> John
A proof is a logically perfect argument. An argument is a proof when
it is perfect, not when it is approved by so-and-sos who are
such-and-such, nor when time has given it the semblance of verity.
Why do we think that something is not, when we cannot know it
perfectly? O tempora! O mores! Why is the reflex of our age to assume
that, because we have fallen short, we have reached our goal, or worse,
that there is no goal? Where are the eyes that see the Ideal? Must we
slink now back into the cave, and the adoration of shadows? Plato: why
do you sleep?
TMMS
John Thingstad wrote:
> On Mon, 26 Jun 2006 18:45:14 +0200, Joe Marshall <··········@gmail.com>
> wrote:
> >
> > A proof is nothing more than a persuasive argument.
> >
>
> A proof is a lot more than a persuasive argument.
> For one thing it has to be verified by three independent mathematicians.
> Then it has to stand the test of time.
> I am not saying that mathematical proof is absolute.
> Just that we try to set the bar higher than, say, in politics.
Apparently you require a lot to persuade you.
+ "Juan R." <··············@canonicalscience.com>:
| If prefix notation was so clearly superior all mathemtics would be
| done in prefix way and all calculators would be as that from HP.
- which is actually using postfix notation.
I am a mathematician. I use standard algebraic notation when I do
mathematics by hand, or when I write it up for others to read. It is
a superior syntax for these uses in part because I and everybody else
are used to it. When communicating with others or a future self (as
when making notes) this is a huge plus.
I also write Lisp programs on occassion. Here I find prefix notation
better suited most of the time, because it fits better in with the
overall structure of the language. Even numerical programs usually
contain much more program structure and logic than mathematical
formulas, so the trade-off seems good. If I had to write a page long
equation in Lisp one day, I'd probably use an infix parser for the
job. I could pick one off the 'net, or I might write my own Pratt
parser. (I have an old one lying around, written in Scheme, that
should be easy to convert to common lisp.)
I even use HP calculators once in a while. For this use, postfix
notation is better because the stack model of HP calculators is so
very intuitive, as is the notion of working the formulas from the
inside out - just as when you do the same calculation by hand. You
also get to see intermediate results, which gives you a good chance at
spotting gross errors in data entry because the results are way off.
In summery, three uses, three different syntaxes, each suited to its
particular task. I cannot for the life of me see the point in
insisting on using the same tool for every job.
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- It is undesirable to believe a proposition
when there is no ground whatsoever for supposing it is true.
-- Bertrand Russell
Harald Hanche-Olsen <······@math.ntnu.no> writes:
> I even use HP calculators once in a while. For this use, postfix
> notation is better because the stack model of HP calculators is so
> very intuitive, as is the notion of working the formulas from the
> inside out - just as when you do the same calculation by hand. You
> also get to see intermediate results, which gives you a good chance at
> spotting gross errors in data entry because the results are way off.
>
> In summery, three uses, three different syntaxes, each suited to its
> particular task. I cannot for the life of me see the point in
> insisting on using the same tool for every job.
What is the advantage of postfix over prefix for calculators?
'as
Alexander Schmolck <··········@gmail.com> writes:
> Harald Hanche-Olsen <······@math.ntnu.no> writes:
>
>> I even use HP calculators once in a while. For this use, postfix
>> notation is better because the stack model of HP calculators is so
>> very intuitive, as is the notion of working the formulas from the
>> inside out - just as when you do the same calculation by hand. You
>> also get to see intermediate results, which gives you a good chance at
>> spotting gross errors in data entry because the results are way off.
>>
>> In summery, three uses, three different syntaxes, each suited to its
>> particular task. I cannot for the life of me see the point in
>> insisting on using the same tool for every job.
>
> What is the advantage of postfix over prefix for calculators?
That should be pretty obvious if you ever used a RPN calculator.
You can add additional values (numbers or calculations) to a
intermediate result and then specify the operator to use on the
values on the stack. If you were to use prefix notation you would
have to somehow push an operator in front of intermediate results
to achieve prefix notation, which would be silly...
Anyway values on the stack on RPN calculators like HP's threat
artithmetic operators as taking two operands, such that e.g.
adding three operands on the stack requires pushing the + key
twice - unlike the prefix notation in lisp.
If on the other hand the question is advantages of postfix vs
infix for calculators the answer would be simply that it requires
fewer keystrokes.
--
Eirik Mikkelsen <········@gmail.com>
http://bsdbox.org/
Harald Hanche-Olsen wrote:
> + "Juan R." <··············@canonicalscience.com>:
>
> | If prefix notation was so clearly superior all mathemtics would be
> | done in prefix way and all calculators would be as that from HP.
>
> - which is actually using postfix notation.
>
> I am a mathematician. I use standard algebraic notation when I do
> mathematics by hand, or when I write it up for others to read. It is
> a superior syntax for these uses in part because I and everybody else
> are used to it. When communicating with others or a future self (as
> when making notes) this is a huge plus.
I think that infix notation is more natural because i) i suspect that
perception rules do it easier; ii) it is more close to way nature work.
That is reason that elementary process are written as (a + b) instead
(+ a b).
> I also write Lisp programs on occassion. Here I find prefix notation
> better suited most of the time, because it fits better in with the
> overall structure of the language.
I understood. When i read
<blockquote>
One could argue that LISP syntax, despite being unconventional and
therefore difficult for beginners to learn and use, is somehow superior
to algebraic syntax. (Indeed, LISP programmers often argue exactly
this.)
</blockquote>
I thought that LISPers claimed that prefix notation was better anytime.
Now i understand that quote means that prefix notation is better FOR
LISP and reason that any proposal to change syntax (e.g. MLISP) failed.
Now i think that i can continue using infix notation in my own approach
because advantages vanish, but yes if i was to program on LISP i would
use the prefix way. Somewhat as I would use the postfix one in
Postscript or Forth.
Thanks by clarification!
> Even numerical programs usually
> contain much more program structure and logic than mathematical
> formulas, so the trade-off seems good. If I had to write a page long
> equation in Lisp one day, I'd probably use an infix parser for the
> job. I could pick one off the 'net, or I might write my own Pratt
> parser. (I have an old one lying around, written in Scheme, that
> should be easy to convert to common lisp.)
>
> I even use HP calculators once in a while. For this use, postfix
> notation is better because the stack model of HP calculators is so
> very intuitive, as is the notion of working the formulas from the
> inside out - just as when you do the same calculation by hand. You
> also get to see intermediate results, which gives you a good chance at
> spotting gross errors in data entry because the results are way off.
>
> In summery, three uses, three different syntaxes, each suited to its
> particular task. I cannot for the life of me see the point in
> insisting on using the same tool for every job.
>
Juan R.
Center for CANONICAL |SCIENCE)
Juan R. wrote:
> I think that infix notation is more natural because i) i suspect that
> perception rules do it easier;
I suspect it's what you're used to.
> ii) it is more close to way nature work.
Actually, nature uses postfix, as does every other calculation process
when it's *actually* calculating. It's pretty difficult to calculate (a
+ b) without already having calculated A and B. Indeed, in LISP, in
spite of prefix *notation*, the calculations are done with the first
element of the form being applied last.
--
Darren New / San Diego, CA, USA (PST)
Native Americans used every part
of the buffalo, including the wings.
Darren New wrote:
> Juan R. wrote:
> > I think that infix notation is more natural because i) i suspect that
> > perception rules do it easier;
>
> I suspect it's what you're used to.
I said perception rules not familiarity.
> Actually, nature uses postfix, as does every other calculation process
> when it's *actually* calculating.
I was all the time speaking about topological properties of natural
processes and why chemists or physicists or biologists write (a + b)
instead (+ a b), i said nothing about temporal sequences. But also in
time Nature likes infix.
(A+B) --> AB
is a shorthand for the time ordered sequence
(A+B), [AB]*, AB
It would look strange the LISP notation (--> (+ A B) AB)
when both spatial and temporal diagrams are [[A+B] --> AB]
A
\ AB
\ /
\ /
)===(
/
/
/
B
x
|
|
+---t
Juan R.
Center for CANONICAL |SCIENCE)
"Juan R." <··············@canonicalscience.com> writes:
> If prefix notation was so clearly superior all mathemtics would be done
> in prefix way and all calculators would be as that from HP.
Actually, maths is mostly done with prefix notations.
f x
__
\ x
/_ i
___
| | x
| | i
/
| f x dx
|
/
______
/
\/ x
etc...
Infix notation is only used in special cases for historical reasons.
--
__Pascal Bourguignon__ http://www.informatimago.com/
ATTENTION: Despite any other listing of product contents found
herein, the consumer is advised that, in actuality, this product
consists of 99.9999999999% empty space.
Pascal Bourguignon wrote:
> "Juan R." <··············@canonicalscience.com> writes:
> > If prefix notation was so clearly superior all mathemtics would be done
> > in prefix way and all calculators would be as that from HP.
>
> Actually, maths is mostly done with prefix notations.
Not true.
> f x
>
> __
> \ x
> /_ i
>
> ___
> | | x
> | | i
>
>
> /
> | f x dx
> |
> /
> ______
> /
> \/ x
>
> etc...
>
> Infix notation is only used in special cases for historical reasons.
Not true. The arrow notation (infix) is traced to last 40s when f x was
already known.
Modern mathematicians continue using infix for new concepts such as
star products.
In chemistry and physics, a+b is not prefered by historical motives but
topological.
Juan R.
Center for CANONICAL |SCIENCE)
Juan R. wrote:
> Yes, all-prefix could be more uniform, but also more difficult to read
> and is suspect reason for infix macros and special editors.
Which language is easier to communicate in: English or Spanish? Of
course it depends on what you are used to. Lisp's prefix is not
inherently "harder" you simply are not used to it.
If you give lisp a serious chance and follow the standard formatting
conventions you will find it is very easy to read once you get use to
it.
As for "why", originally it was that way because the inventor was a
mathematician and he wanted it to be as simple as possible. The reason
people have chosen to stick with prefix rather changing to infix
notation can be summed up in one word: macros.
Read 'Practical Common Lisp' for a gentle introduction to Lisp. PCL's
chapter on developing a unit test framework nicely demonstrates some of
the power of macros. Paul Graham's 'On Lisp' goes into more depth
about macros. It is easier to write powerful macros when the
underlying code is s-expressions (i.e. prefix notation). Powerful
macros are the one feature of Lisp no other popular language has
managed to incorporate.
--fj
Just as a personal anecdote: I've found myself occassionally writing
complex math expressions in half-prefix notation because once you use
appropriate indentation it has become faster for me to comprehend.
It's very atypical, but very simple and practical once you've learned
it.
And as a side note, the (+ a b c d ...) binary overloading bit reminds
me a bit of vertical notation
a
b
c
d
+
----
?
I've personally found that once I jumped into prefix notation, I've
never looked back.
funkyj wrote:
> Juan R. wrote:
>
> > Yes, all-prefix could be more uniform, but also more difficult to read
> > and is suspect reason for infix macros and special editors.
>
> Which language is easier to communicate in: English or Spanish? Of
> course it depends on what you are used to. Lisp's prefix is not
> inherently "harder" you simply are not used to it.
I think many people would agree on that Spanish is more difficult.
Mastering in English is cheap, but real mastering in Spanish is
difficult even being native.
> If you give lisp a serious chance and follow the standard formatting
> conventions you will find it is very easy to read once you get use to
> it.
>
I find disturbing that math and science do not use an all-prefix.
Moreover, my client/users clearly dislike all-prefix and want follow
math and chemistry closely.
In particle physics, one writes e1 + e2 = e1' + e2'
for two electron scattering. Nobody does = + e1 e2 + e1' e2'
> As for "why", originally it was that way because the inventor was a
> mathematician and he wanted it to be as simple as possible. The reason
> people have chosen to stick with prefix rather changing to infix
> notation can be summed up in one word: macros.
>
> Read 'Practical Common Lisp' for a gentle introduction to Lisp. PCL's
> chapter on developing a unit test framework nicely demonstrates some of
> the power of macros. Paul Graham's 'On Lisp' goes into more depth
> about macros. It is easier to write powerful macros when the
> underlying code is s-expressions (i.e. prefix notation). Powerful
> macros are the one feature of Lisp no other popular language has
> managed to incorporate.
Thanks, let me explain a bit about my and my projects.
My current objective is to develop a simple transformation language for
datuments in CanonML approach (similar to XSLT).
I also would explain that my i like most of LISP (i dislike C, Java,
OOP and all that). Simply, i am searching more information about
formalities of LISP because i consider it a very good system and would
copy it always as was possible. In fact, CanonML is based in SXML that
is s-expr version of XML for Scheme.
Note: In my approach prefix notation is a special case of infix one
(preargument ::operator postargument)
If preargument = empty
(::operator postargument)
if postargument = empty
(preargument ::operator)
Therefore the parser always deal with basic structure
(preargument ::operator postargument)
Juan R.
Center for CANONICAL |SCIENCE)
funkyj wrote:
> Juan R. wrote:
>
> > Yes, all-prefix could be more uniform, but also more difficult to read
> > and is suspect reason for infix macros and special editors.
>
> Which language is easier to communicate in: English or Spanish? Of
> course it depends on what you are used to. Lisp's prefix is not
> inherently "harder" you simply are not used to it.
>
> If you give lisp a serious chance and follow the standard formatting
> conventions you will find it is very easy to read once you get use to
> it.
>
> As for "why", originally it was that way because the inventor was a
> mathematician and he wanted it to be as simple as possible. The reason
> people have chosen to stick with prefix rather changing to infix
> notation can be summed up in one word:
Consistency. Macros could be done with infix notation, but infix
notation in mathematics is only used for standard operators. Analyzing
mathematical notation, even if you could represent the various special
symbols and graphical constructs (e.g. those of combinations, floor and
ceiling functions), would require a lot os special cases. Macros
benefit not from the prefix notation itself, but from the consistency
is provides. Mathematical notation, like that of any human language, is
ad hoc, and very context-sensitive, which allows it to be much more
abbreviated at times than a consistent syntax, but impossible to
understand and generate without a large store of knowledge of special
cases. So it is with computer languages. Lisp is a little like the
Esperanto of computer languages, and about as popular.
"numeromancer" <·······@sbcglobal.net> writes:
> Lisp is a little like the Esperanto of computer languages, and about
> as popular.
Ĝis la fina venko!
--
Luís Oliveira
luismbo (@) gmail (.) com
http://student.dei.uc.pt/~lmoliv/
numeromancer wrote:
> Consistency. Macros could be done with infix notation, but infix
> notation in mathematics is only used for standard operators.
What standard? this [a /\ b]? this [a \star b]? or this [a # b]?
Juan R.
Center for CANONICAL |SCIENCE)
Marco Baringer wrote:
> "Juan R." <··············@canonicalscience.com> writes:
>
>> -specially when managing dozens of operators- i am unable to see
>> realistic advantages over infix notation
>>
>> ((1 * 2) + (3 / 4))
>
> (+ (* 1 2 3) (/ 4 5 6) (- 7 8 9))
>
> ok, this isn't the best thing since sliced bread, but it's still
> pretty nice, espcially when used with comparision functions:
>
> (<= min x max)
>
> as opposed to
>
> ((min <= x) and (x <= max)).
This isn't a criticism of infix notation, but I've actually never liked
that you can write (+ 1 2 3 ...) or equivalent operations. +,*,etc. are
defined normally as binary operations and so the + used in CL is
actually a fold involving the binary operation of addition.
A *very* minor nitpick, but something that's always bothered me
aesthetically, probably because the other language I use in my spare
time is Haskell.
From: Marco Baringer
Subject: Re: Why is LISP syntax superior?
Date:
Message-ID: <m2odwizbgs.fsf@bese.it>
Marco Baringer <··@bese.it> writes:
> it's all about uniformity and what comes from that. lisp's syntax is
> extremly simple to explain and extend. since functions, operators and
> macros are all treated the same it's easy to write code which
> manipulates other code (there is a reason this is done so often in
> lisp and not in python, even though both have, on paper at least, the
> same possibilities).
please pardon me, i forgot the _real_ reason lisp's syntax is nice:
paredit (http://mumble.net/~campbell/darcs/paredit)
with a few keypresses i can take any code snippet and:
1) wrap a variable binding around it
2) unwrap a variable binding around it
3) swap it with another code snippet
4) grab it, and the following three forms, and wrap them all an unless
(or any other macro/function i need).
unfortunetly, there's absolutly no way you can understand this, you
have to experience it to see how much faster it is compared to editing
syntax-full languages (java and perl in my
case). http://www.cliki.net/Editing%20Lisp%20Code%20with%20Emacs and
the slime movie (http://common-lisp.net/movies/slime.mov) might
provide some insight into what i'm talking about without making you
learn emaccs [nb: i'm the author of both of those]
hth.
--
-Marco
Ring the bells that still can ring.
Forget your perfect offering.
There is a crack in everything.
That's how the light gets in.
-Leonard Cohen
Marco Baringer wrote:
> Marco Baringer <··@bese.it> writes:
>
> > it's all about uniformity and what comes from that. lisp's syntax is
> > extremly simple to explain and extend. since functions, operators and
> > macros are all treated the same it's easy to write code which
> > manipulates other code (there is a reason this is done so often in
> > lisp and not in python, even though both have, on paper at least, the
> > same possibilities).
>
> please pardon me, i forgot the _real_ reason lisp's syntax is nice:
>
> paredit (http://mumble.net/~campbell/darcs/paredit)
>
> with a few keypresses i can take any code snippet and:
>
> 1) wrap a variable binding around it
>
> 2) unwrap a variable binding around it
>
> 3) swap it with another code snippet
>
> 4) grab it, and the following three forms, and wrap them all an unless
> (or any other macro/function i need).
>
> unfortunetly, there's absolutly no way you can understand this, you
> have to experience it to see how much faster it is compared to editing
> syntax-full languages (java and perl in my
> case).
I understand you, as said i dislike C, Java and all that. I like
grouping by parentheses or braces or any others. I also like the formal
simple syntax.
Simply i am designing a language using
[E = [m * [c ^2]]]
instead
[= E [* m [^ c 2]]]
and would know posible errors (or inconveniences) in this phase of
design.
So far as i can see prefix notation offers advantages when working in
LISP,
Now, i think that i understand why MLISP failed to attract audience.
Prefix Syntax and rest of LISP are one!
but advantages are lost in another system (my own).
> http://www.cliki.net/Editing%20Lisp%20Code%20with%20Emacs and
> the slime movie (http://common-lisp.net/movies/slime.mov) might
> provide some insight into what i'm talking about without making you
> learn emaccs [nb: i'm the author of both of those]
Juan R.
Center for CANONICAL |SCIENCE)
The advantage of Lisp syntax becomes obvious once you start playing
with macros. Since the relation between a Lisp expression and the
corresponding parse tree is more or less trivial, and macros work on
the parse tree level, complex macros are orders of magnitude easier to
write and understand than they otherwise would. (And they need to be,
since macros can quickly become quite hard to understand anyhow.)
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- It is undesirable to believe a proposition
when there is no ground whatsoever for supposing it is true.
-- Bertrand Russell
Another advantage to sexpr syntax is that there is no concept of
precedence. This makes extending the language much simpler as you can
keep the syntax uniform without having to worry about how new operators
will bind implicitly.
"Tel A." wrote:
>Another advantage to sexpr syntax is that there is no concept of
>precedence. This makes extending the language much simpler as you can
>keep the syntax uniform without having to worry about how new operators
>will bind implicitly.
No precedence, and no left-to-right or right-to-left associativity
ambiguities.
Quickly, what is a*b/c ? - If ** is the exponentiation operator: Is
a**b**c equal to ((a**b)**c) or is it (a**(b**c))?
Harald Hanche-Olsen wrote:
> The advantage of Lisp syntax becomes obvious once you start playing
> with macros. Since the relation between a Lisp expression and the
> corresponding parse tree is more or less trivial, and macros work on
> the parse tree level, complex macros are orders of magnitude easier to
> write and understand than they otherwise would. (And they need to be,
> since macros can quickly become quite hard to understand anyhow.)
>
I see not further difficulties with something like
(A -> B)
instead
(-> A B)
Do you know some reference where this was explained to a formal level?
Juan R.
Center for CANONICAL |SCIENCE)
Juan R. wrote:
> Harald Hanche-Olsen wrote:
> > The advantage of Lisp syntax becomes obvious once you start playing
> > with macros. Since the relation between a Lisp expression and the
> > corresponding parse tree is more or less trivial, and macros work on
> > the parse tree level, complex macros are orders of magnitude easier to
> > write and understand than they otherwise would. (And they need to be,
> > since macros can quickly become quite hard to understand anyhow.)
>
> I see not further difficulties with something like
>
> (A -> B)
>
> instead
>
> (-> A B)
>
> Do you know some reference where this was explained to a formal level?
I vaguely recall Joe Marshall mentioning something like this, but all I
could find was:
http://groups.google.com/group/comp.lang.lisp/msg/7129968305720773b
(I'm fairly sure it was something else though, something more directly
answering your question...)
We probably should note that there are things in Lisp which use infix
syntax... for example, you can type numbers like 235/14 or 392.29 .
Loop uses it heavily too, in for..= and for...in clauses. Nothing stops
you from making your own either; infix parsers were once a common
homework question. In your example of
(A -> B)
I sometimes use that particular syntax when I wish to be fancy. (Though
it's when -> isn't a serious operator but rather a visual aid.)
Tayssir
Tayssir John Gabbour wrote:
>
> I vaguely recall Joe Marshall mentioning something like this, but all I
> could find was:
> http://groups.google.com/group/comp.lang.lisp/msg/7129968305720773b
Thanks but link is broken.
> (I'm fairly sure it was something else though, something more directly
> answering your question...)
>
> We probably should note that there are things in Lisp which use infix
> syntax... for example, you can type numbers like 235/14 or 392.29 .
> Loop uses it heavily too, in for..= and for...in clauses.
Also the own SEXPR is infix.
(a . b)
because "." can be thought of like a kind of operator: the pairs one.
Juan R.
Center for CANONICAL |SCIENCE)
Juan R. wrote:
> Tayssir John Gabbour wrote:
> >
> > I vaguely recall Joe Marshall mentioning something like this, but all I
> > could find was:
> > http://groups.google.com/group/comp.lang.lisp/msg/7129968305720773b
>
> Thanks but link is broken.
Odd. Let's try again (keeping in mind this is a common topic, and
searching this newsgroup should be fruitful):
Message-ID: <············@ccs.neu.edu>
http://groups.google.com/group/comp.lang.lisp/msg/7129968305720773
You mention mathematicians often (I personally like cooks; we must all
have our pet comparison to other domain experts), and my understanding
is that mathematics gains its applicability from massive abstractions
of things, like infinitely straight and thin lines; this impossible
abstraction is what makes math apply to many other fields, even though
ironically we never encounter such lines in nature.
In a vaguely similar way, Lisp gains some of its power from syntactic
abstractions. Those abstractions may not thrill those who love
notations from other domains, but that enables us to write powerful
tools that will thrill them.
If you want to experiment with infix notation, you might search around
for packages like the following, which offers infix-within-Lisp:
http://www.cliki.net/infix
But you may not find "formal proofs", as you requested earlier. That's
a level of evidence not found in even the hardest sciences, as they
rely on evidence rather than proof. And this is a UI issue; I can
intellectually find situations where I'd consider infix "better." But
that doesn't mean I'd want to absolutely pervade Lisp with it.
Tayssir
Tayssir John Gabbour <···········@yahoo.com> wrote:
+---------------
| If you want to experiment with infix notation, you might search around
| for packages like the following, which offers infix-within-Lisp: ...
| But you may not find "formal proofs", as you requested earlier. That's
| a level of evidence not found in even the hardest sciences, as they
| rely on evidence rather than proof. And this is a UI issue; I can
| intellectually find situations where I'd consider infix "better." But
| that doesn't mean I'd want to absolutely pervade Lisp with it.
+---------------
Well said! IMHO, it is indeed mostly "a UI issue". Google for past
articles I've posted here [and in c.l.scheme, before that] -- keywords
"OPFR", "P'Lite", "Parentheses-Light Scheme", "parenthephobia" --
for some of my experiences with trying to make {Scheme,Lisp}-based
programs with command-line interfaces more accessible to parenthephobes.
Even though I *wrote* "P'Lite Scheme" [an infix reader/preprocessor,
with syntax a cross between Tcl & ML(!)], and for several years
supported a user community of about a dozen engineers who used it
for user-mode debugging of various new hardware devices, in the end
I personally found myself always reverting to native {Scheme,Lisp}
sexpr-based REPLs. [This was quite easy to do in P'Lite, since a
"\(" was the "escape into Scheme" marker.]
Well, there *is* one exception to that: While I mostly use standard
REPLs for most of my current CL hacking (mainly CMUCL), I *do* find
that the "OPFR" ["Outer-Parentheses-Free REPL"] interface feels more
"natural" when doing user-mode hardware debugging, and it's *MUCH*
better tolerated by my co-workers than a fully-parenthesized REPL
would be, even though *only* the outer/top-level pair of parens are
suppressed. Go figure.
-Rob
p.s. Oh, and for the curious-but-Google-lazy, here's how a standard
REPL compares with OPFR. First, normal CMUCL [with some hardware-
support libararies loaded, for functions like D32, and the "0x"
readmacro (to make cut/paste from C easier)]:
cmu> (+ 1 2)
3
cmu> (expt 2 100)
1267650600228229401496703205376
cmu> (loop for i below 5 collect (cons i (expt 2 i)))
((0 . 1) (1 . 2) (2 . 4) (3 . 8) (4 . 16))
cmu> (d32 (+ adc 0x80) 0x80 0x80)
0x80: 0x00040625 0x000000fc 0x00000000 0x00000000
0x90: 0x00000000 0x00000000 0x00000000 0x00000000
0xa0: 0x00000000 0x00000000 0x00000000 0x00000000
0xb0: 0x00000000 0x00000000 0x00000000 0xf0000530
0xc0: 0x00000625 0x7426a0c1 0x00000000 0x00000000
0xd0: 0x00000000 0x00000000 0x00000000 0x00000000
0xe0: 0x00000000 0x00000000 0x00000000 0x00000000
0xf0: 0x00000000 0x00000000 0x00000000 0x7543e014
cmu>
And now exactly the same thing, but using the OPFR REPL:
hwtool> + 1 2
3
hwtool> expt 2 100
1267650600228229401496703205376
hwtool> loop for i below 5 collect (cons i (expt 2 i))
((0 . 1) (1 . 2) (2 . 4) (3 . 8) (4 . 16))
hwtool> d32 (+ adc 0x80) 0x80 0x80
0x80: 0x00040625 0x000000fc 0x00000000 0x00000000
0x90: 0x00000000 0x00000000 0x00000000 0x00000000
0xa0: 0x00000000 0x00000000 0x00000000 0x00000000
0xb0: 0x00000000 0x00000000 0x00000000 0xf0000530
0xc0: 0x00000625 0x7426a0c1 0x00000000 0x00000000
0xd0: 0x00000000 0x00000000 0x00000000 0x00000000
0xe0: 0x00000000 0x00000000 0x00000000 0x00000000
0xf0: 0x00000000 0x00000000 0x00000000 0x7543e014
hwtool>
Not much difference you say? True, but it makes a surprising
amount of difference in usability, nevertheless. Since the
vast majority of the "commands" in the HWTOOL app normally
take only atomic args [the first arg of D32 above is an exception],
most of the time users never need to see/use prefix notation.
p.p.s. Oh, and because I sometimes forget which REPL I'm using,
OPFR allows normal prefix notation, too: ;-} ;-}
hwtool> * 2 (1+ 4)
10
hwtool> (* 2 (1+ 4))
10
hwtool>
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Tayssir John Gabbour wrote:
> Juan R. wrote:
> > Tayssir John Gabbour wrote:
> > >
> > > I vaguely recall Joe Marshall mentioning something like this, but all I
> > > could find was:
> > > http://groups.google.com/group/comp.lang.lisp/msg/7129968305720773b
> >
> > Thanks but link is broken.
>
> Odd. Let's try again (keeping in mind this is a common topic, and
> searching this newsgroup should be fruitful):
> Message-ID: <············@ccs.neu.edu>
> http://groups.google.com/group/comp.lang.lisp/msg/7129968305720773
>
> You mention mathematicians often (I personally like cooks; we must all
> have our pet comparison to other domain experts), and my understanding
> is that mathematics gains its applicability from massive abstractions
> of things, like infinitely straight and thin lines; this impossible
> abstraction is what makes math apply to many other fields, even though
> ironically we never encounter such lines in nature.
>
> In a vaguely similar way, Lisp gains some of its power from syntactic
> abstractions. Those abstractions may not thrill those who love
> notations from other domains, but that enables us to write powerful
> tools that will thrill them.
>
> If you want to experiment with infix notation, you might search around
> for packages like the following, which offers infix-within-Lisp:
> http://www.cliki.net/infix
>
> But you may not find "formal proofs", as you requested earlier. That's
> a level of evidence not found in even the hardest sciences, as they
> rely on evidence rather than proof. And this is a UI issue; I can
> intellectually find situations where I'd consider infix "better." But
> that doesn't mean I'd want to absolutely pervade Lisp with it.
>
>
> Tayssir
Thanks by the link. Now i understand that prefix notation is closely
related to data model in LISP and that several of advantages are lost
outside it. Probably reason that math, science and others languages
prefer infix.
By formal i mean debate beyond like/dislike. For example in chemistry
one prefers a + b
over + a b because topological reasons, the + may be infix because
after generates the bond a-b which is infix. However one write OH- (no
infix) because by energetic reason the negative charge is outside. That
is, those conventions are not because chemists like or dislike one
notation or other, there is formal reasons.
Juan R.
Center for CANONICAL |SCIENCE)
"Juan R." <··············@canonicalscience.com> writes:
> Harald Hanche-Olsen wrote:
> > The advantage of Lisp syntax becomes obvious once you start playing
> > with macros. Since the relation between a Lisp expression and the
> > corresponding parse tree is more or less trivial, and macros work on
> > the parse tree level, complex macros are orders of magnitude easier to
> > write and understand than they otherwise would. (And they need to be,
> > since macros can quickly become quite hard to understand anyhow.)
> >
>
> I see not further difficulties with something like
>
> (A -> B)
>
> instead
>
> (-> A B)
>
> Do you know some reference where this was explained to a formal level?
Well, not at a formal level, but consider the following bit of lisp
code:
(defun a (x y) (+ x y))
(defun -> (x y) (- x y))
(let ((a 1)
(b 2)
(-> 10))
(list (a -> b)
(-> a b)))
So what is this supposed to return?
One of the points about the uniform syntax of lisp is that functions and
variables and many other things in the lisp system are named by symbols.
Any symbols. There are no special characters which name only
operators. In Java, for example, you can't name an operator "+", so if
you see the plus sign, you don't have to worry about whether it names a
variable, or if it is even part of a variable. That is why "a+b" is
unambiguously an arithmetic expression in Java. In Lisp it is a
symbol. [Digression: In Dylan, it is a symbol, but "a + b" is an
arithmetic expression].
So the real reason for always using prefix notation is because one
really wants to know, without any clues from the symbol name, which
symbol names the operator of the s-expression. Having the operator
always be the first element works great. No other convention would work
as well, at least not if you wanted to also support unary operators.
Except for the degenerate case of (), there is always a first element.
I suppose that one could come up with a more complicated system in which
the operator is the first element, unless there are three subforms, in
which case the operator is the second element. If there are more than
three subforms, the operator is the first element again? Some other
choice? And even for the unary case, I bet if you get binary operators,
you would also like to get postfix operators like ! for factorial.
Now this is beginning to get muchly more complicated, and doesn't even
help you with everything because you also can, I'm sure, come up with
binary operators that you would prefer not be in-fix.
>
> Juan R.
>
> Center for CANONICAL |SCIENCE)
>
--
Thomas A. Russ, USC/Information Sciences Institute
Thomas A. Russ wrote:
>
> One of the points about the uniform syntax of lisp is that functions and
> variables and many other things in the lisp system are named by symbols.
> Any symbols. There are no special characters which name only
> operators. In Java, for example, you can't name an operator "+", so if
> you see the plus sign, you don't have to worry about whether it names a
> variable, or if it is even part of a variable. That is why "a+b" is
> unambiguously an arithmetic expression in Java. In Lisp it is a
> symbol. [Digression: In Dylan, it is a symbol, but "a + b" is an
> arithmetic expression].
>
> So the real reason for always using prefix notation is because one
> really wants to know, without any clues from the symbol name, which
> symbol names the operator of the s-expression. Having the operator
> always be the first element works great.
Yes, this point was discussed here. An option for infix operators
(outside LISP) is explicit markup, such as TeX {a \over b}, that would
be encoded as (over a b) in s-expr because there is not explicit
notation for the over command in pure LISP.
> No other convention would work
> as well, at least not if you wanted to also support unary operators.
> Except for the degenerate case of (), there is always a first element.
>
> I suppose that one could come up with a more complicated system in which
> the operator is the first element, unless there are three subforms, in
> which case the operator is the second element. If there are more than
> three subforms, the operator is the first element again? Some other
> choice? And even for the unary case, I bet if you get binary operators,
> you would also like to get postfix operators like ! for factorial.
>
> Now this is beginning to get muchly more complicated, and doesn't even
> help you with everything because you also can, I'm sure, come up with
> binary operators that you would prefer not be in-fix.
I find this part of debate very interesting and if you agree i would
discuss more about posibilities for [a over b] without explicit markup
for the operator over. I rejected that posibility in the past but now i
am returning to analize it with more detail.
For example, i could define a rule or macro in my own approach such
parser can translate
[a over b] to (over a b) or standard (/ a b) for symbolic computation
or to {a \over b} for printing selecting diferent "stylesheets".
On that case if i am able to perform the rule/macro, any information
contained in (/ a b) would be available from [a over b]. What do you
think?
Note that [a over b] is not a s-expr therefore there is not binary
trees.
Juan R.
Center for CANONICAL |SCIENCE)
"Juan R." <··············@canonicalscience.com> writes:
> Thomas A. Russ wrote:
> >
> > One of the points about the uniform syntax of lisp is that functions and
> > variables and many other things in the lisp system are named by symbols.
> > Any symbols. There are no special characters which name only
> > operators. In Java, for example, you can't name an operator "+", so if
> > you see the plus sign, you don't have to worry about whether it names a
> > variable, or if it is even part of a variable. That is why "a+b" is
> > unambiguously an arithmetic expression in Java. In Lisp it is a
> > symbol. [Digression: In Dylan, it is a symbol, but "a + b" is an
> > arithmetic expression].
> >
> > So the real reason for always using prefix notation is because one
> > really wants to know, without any clues from the symbol name, which
> > symbol names the operator of the s-expression. Having the operator
> > always be the first element works great.
>
> Yes, this point was discussed here. An option for infix operators
> (outside LISP) is explicit markup, such as TeX {a \over b}, that would
> be encoded as (over a b) in s-expr because there is not explicit
> notation for the over command in pure LISP.
Well, that is certainly possible. But you would need the notation you
choose to be a unique one that means this is the operator of the
particular form.
Otherwise you give up the ability to treat operators and functions
themselves as first-class values. Higher order functions require that
you be able to pass function objects as arguments. So that means you
will need to introduce an addition syntactic marker, all so that one can
avoid prefix notation.
It seems that one will really need to have a great aversion to prefix
notation to go through all the trouble of doing that just to avoid
prefix notation. (BTW, postfix notation will also work with most of the
same benefits, except perhaps for some convenience in knowing the
what the operator is before processing arguments....)
> > No other convention would work
> > as well, at least not if you wanted to also support unary operators.
> > Except for the degenerate case of (), there is always a first element.
> >
> > I suppose that one could come up with a more complicated system in which
> > the operator is the first element, unless there are three subforms, in
> > which case the operator is the second element. If there are more than
> > three subforms, the operator is the first element again? Some other
> > choice? And even for the unary case, I bet if you get binary operators,
> > you would also like to get postfix operators like ! for factorial.
> >
> > Now this is beginning to get muchly more complicated, and doesn't even
> > help you with everything because you also can, I'm sure, come up with
> > binary operators that you would prefer not be in-fix.
>
> I find this part of debate very interesting and if you agree i would
> discuss more about posibilities for [a over b] without explicit markup
> for the operator over. I rejected that posibility in the past but now i
> am returning to analize it with more detail.
>
> For example, i could define a rule or macro in my own approach such
> parser can translate
Well, I think your parser would still have diffculty with the example I
posted. For example, what if both "a" and "over" were operators? How
would your rule know which one should be controlling?
> [a over b] to (over a b) or standard (/ a b) for symbolic computation
>
> or to {a \over b} for printing selecting diferent "stylesheets".
>
> On that case if i am able to perform the rule/macro, any information
> contained in (/ a b) would be available from [a over b]. What do you
> think?
I think it only works if you already know all the operators when you
build your system. What about
[nextto over under]
Do you mean for this to be
(nextto over under)
(over nexto under)
(under nexto over)
? How do you tell? You need to be able to handle the general case,
where operators themselves can be arguments to functions.
--
Thomas A. Russ, USC/Information Sciences Institute
Thomas A. Russ wrote:
> > Yes, this point was discussed here. An option for infix operators
> > (outside LISP) is explicit markup, such as TeX {a \over b}, that would
> > be encoded as (over a b) in s-expr because there is not explicit
> > notation for the over command in pure LISP.
>
> Well, that is certainly possible. But you would need the notation you
> choose to be a unique one that means this is the operator of the
> particular form.
In fact, i also avoid multiple uses of same operator. In TeX, a^b
varies in function of what is a. I find this disturbing.
> Otherwise you give up the ability to treat operators and functions
> themselves as first-class values. Higher order functions require that
> you be able to pass function objects as arguments. So that means you
> will need to introduce an addition syntactic marker, all so that one can
> avoid prefix notation.
>
> It seems that one will really need to have a great aversion to prefix
> notation to go through all the trouble of doing that just to avoid
> prefix notation. (BTW, postfix notation will also work with most of the
> same benefits, except perhaps for some convenience in knowing the
> what the operator is before processing arguments....)
It is easy, I would devote more money and time to this project than to
convince users to work mathematics and science in a prefix way.
Morever, even if using a prefix way for internal encoding, i would
translate to infix for presentation of results.
> > I find this part of debate very interesting and if you agree i would
> > discuss more about posibilities for [a over b] without explicit markup
> > for the operator over. I rejected that posibility in the past but now i
> > am returning to analize it with more detail.
> >
> > For example, i could define a rule or macro in my own approach such
> > parser can translate
>
> Well, I think your parser would still have diffculty with the example I
> posted. For example, what if both "a" and "over" were operators? How
> would your rule know which one should be controlling?
Take this case [a over 2] ==> (/ a 2) or {a \over 2}
Take this case [alpha over 2] ==> (/ (alpha) 2) or {\alpha \over 2}
Take this [mynum over 2] ==> (/ (+ a b) 2) or {{a+b} \over 2}
if mynum is [a+b]
> > [a over b] to (over a b) or standard (/ a b) for symbolic computation
> >
> > or to {a \over b} for printing selecting diferent "stylesheets".
> >
> > On that case if i am able to perform the rule/macro, any information
> > contained in (/ a b) would be available from [a over b]. What do you
> > think?
>
> I think it only works if you already know all the operators when you
> build your system. What about
>
> [nextto over under]
Sorry I do not understand this, what is LISP representation? I do not
know that you mean by under. In layouts, under is lacking argument.
> Do you mean for this to be
> (nextto over under)
> (over nexto under)
> (under nexto over)
> ? How do you tell? You need to be able to handle the general case,
> where operators themselves can be arguments to functions.
Juan R.
Center for CANONICAL |SCIENCE)
"Juan R." <··············@canonicalscience.com> writes:
> Thomas A. Russ wrote:
> > Juan R writes:
> > > Yes, this point was discussed here. An option for infix operators
> > > (outside LISP) is explicit markup, such as TeX {a \over b}, that would
> > > be encoded as (over a b) in s-expr because there is not explicit
> > > notation for the over command in pure LISP.
> >
> > Well, that is certainly possible. But you would need the notation you
> > choose to be a unique one that means this is the operator of the
> > particular form.
>
> In fact, i also avoid multiple uses of same operator. In TeX, a^b
> varies in function of what is a. I find this disturbing.
Well, my point is that if you allow mixing of infix and prefix
operators, you have to have some way of knowing which one you
want. Since you seem to like mathematics, what would be the preferred
notation for sin(x) ? In previous posts, you wanted to turn everything
into binary operator form, but I'm at a bit of a loss as to how you do
that with sine.
>
> > Otherwise you give up the ability to treat operators and functions
> > themselves as first-class values. Higher order functions require that
> > you be able to pass function objects as arguments. So that means you
> > will need to introduce an addition syntactic marker, all so that one can
> > avoid prefix notation.
And your response to the issue of higher order functions is?
...
> > > I find this part of debate very interesting and if you agree i would
> > > discuss more about posibilities for [a over b] without explicit markup
> > > for the operator over. I rejected that posibility in the past but now i
> > > am returning to analize it with more detail.
> > >
> > > For example, i could define a rule or macro in my own approach such
> > > parser can translate
> >
> > Well, I think your parser would still have diffculty with the example I
> > posted. For example, what if both "a" and "over" were operators? How
> > would your rule know which one should be controlling?
>
> Take this case [a over 2] ==> (/ a 2) or {a \over 2}
>
> Take this case [alpha over 2] ==> (/ (alpha) 2) or {\alpha \over 2}
>
> Take this [mynum over 2] ==> (/ (+ a b) 2) or {{a+b} \over 2}
>
> if mynum is [a+b]
You missed the point of the question. How is it that you know that
"over" is the operator with arguments a, 2 instead of a being the
operator with arguments over, 2 ?
I guess if everything is binary it works, but that still leaves open the
situation where you have unary or ternary or in general n-ary functions
or opeators. Granted, it is theoretically possible to encode n-ary
functions (awkwardly) as sets of binary ones, but it gets very tedious.
And it also leads to a need to avoid nice abstractions which can be
provided by n-ary relations. For example, what if one wanted to say
that A is BETWEEN X and Y? How would you encode that? In lisp, I
would choose one of
(between a x y) or perhaps (ordered x a y).
Note that we haven't said anything about whether x > y or x < y, so
reducing the encoding to binary cases will get a lot messier....
> > > [a over b] to (over a b) or standard (/ a b) for symbolic computation
> > >
> > > or to {a \over b} for printing selecting diferent "stylesheets".
> > >
> > > On that case if i am able to perform the rule/macro, any information
> > > contained in (/ a b) would be available from [a over b]. What do you
> > > think?
> >
> > I think it only works if you already know all the operators when you
> > build your system. What about
> >
> > [nextto over under]
>
> Sorry I do not understand this, what is LISP representation? I do not
> know that you mean by under. In layouts, under is lacking argument.
Yes, that is the entire point.
In your scheme you can't interpret this without having to know a priori
which of these is the operator. In lisp, this is clear, because the
operator is always the first element of the list.
> > Do you mean for this to be
> > (nextto over under)
> > (over nexto under)
> > (under nexto over)
> > ? How do you tell? You need to be able to handle the general case,
> > where operators themselves can be arguments to functions.
--
Thomas A. Russ, USC/Information Sciences Institute
Thomas A. Russ wrote:
> Well, my point is that if you allow mixing of infix and prefix
> operators, you have to have some way of knowing which one you
> want. Since you seem to like mathematics, what would be the preferred
> notation for sin(x) ? In previous posts, you wanted to turn everything
> into binary operator form, but I'm at a bit of a loss as to how you do
> that with sine.
I already talked about this, as in TeX [::sin x]. The :: is the
corresponding to TeX "\": {\sin x}. Also said as prefix operator was a
special case of a infix parser [{} ::sin x].
> >
> > > Otherwise you give up the ability to treat operators and functions
> > > themselves as first-class values. Higher order functions require that
> > > you be able to pass function objects as arguments. So that means you
> > > will need to introduce an addition syntactic marker, all so that one can
> > > avoid prefix notation.
>
> And your response to the issue of higher order functions is?
Not sure still.
f(x) ==> [::f x]
g(f(x)) ==> [::g [::f x]]
h(x, f(x), g(f(y))) ==> [::h x [::f x] [::g [::f y]]]
Now, the problem is in operators acting on the operator before latter
act in its arguments.
Maybe one possibility could be return to previous version where
operators are explicitly marked. THen operator can be variable or
operator in function of if contains :: or not. That could be similar to
if symbols is head in a LISP list or not.
>
> You missed the point of the question. How is it that you know that
> "over" is the operator with arguments a, 2 instead of a being the
> operator with arguments over, 2 ?
Yes i can see your point. The point about simple stuff as [a b c d] was
for easyness of input by authors (and i was based in ASCIIMath here
where operators are not marked). In TeX operators are marked with "\"
and in LISP by the head position. In fact, the [a over b] construct is
a copy of TeX {a \over b}
Then i could return to previous version with operators explcitely
tagged
(over a 2) is [a ::over 2]
and
(a over 2) is [::a over 2] or [over ::a 2] or [over 2 ::a] depending of
definition of ::a.
Thanks by this useful correction.
> I guess if everything is binary it works, but that still leaves open the
> situation where you have unary or ternary or in general n-ary functions
> or opeators. Granted, it is theoretically possible to encode n-ary
> functions (awkwardly) as sets of binary ones, but it gets very tedious.
This is purely a scientific requirement i am imposing. Of course, any
guy can relax it if find disturbing (it will be implemented in a
special scientific module, not in the core). I can understand it can
sound strange, but please let me follow this way. In nature,
A ==> P
is not fundamental, fundamental process is A + S ==> P + S, however A
==> P is a kind of macroscopic representation or notational
convenience. In mathematics something as sin(x) can be represented as
sequence of binary operations. See the close relationship!
Now turn to ternary processes
A + B + C ==> P
is not fundamental again (in fact nobody has measured a termolecular
process in nature or laboratory). Above is a notational or macroscopic
definition for a sequence of binary processes. Maybe
A + B ==> I
I + C ==> P
Example from mathematics? (2+3+5) is modelled as ((2+3)+5) if one
follow the usual left. In fact formally + is defined binary in
Mathematics and something as 2+3+5 is a notation.
> And it also leads to a need to avoid nice abstractions which can be
> provided by n-ary relations. For example, what if one wanted to say
> that A is BETWEEN X and Y? How would you encode that? In lisp, I
> would choose one of
> (between a x y) or perhaps (ordered x a y).
It is clear i am not explaining myself. In the approach i am
delineating you can write
(::between a x y) or (::ordered x a y) if you want. Simply ::between
or ::ordered are macro-commands for fundamental binary relationships.
E.g. in Formal mathematics, one can define (x < a < y) as a notation
for binary sequence
(x < a) and (a < y)
This is not very different from relaxing ((2+3)+4) to (2+3+4).
> Note that we haven't said anything about whether x > y or x < y, so
> reducing the encoding to binary cases will get a lot messier....
But it is as math is defined. There is not a "between" command. You can
work directly with higher level definitions as you can work with LISP
code, but computer (at least mine) works with low-level code
> > Sorry I do not understand this, what is LISP representation? I do not
> > know that you mean by under. In layouts, under is lacking argument.
>
> Yes, that is the entire point.
>
> In your scheme you can't interpret this without having to know a priori
> which of these is the operator. In lisp, this is clear, because the
> operator is always the first element of the list.
Yes, it is a difficulty of the ASCIIMath notation. However if i return
to previous version with operator explicitely marked the head of the
list correspond to "::".
Juan R.
Center for CANONICAL |SCIENCE)
Juan R. wrote:
> I can understand it can
> sound strange, but please let me follow this way. In nature,
>
> A ==> P
>
> is not fundamental, fundamental process is A + S ==> P + S, however A
> ==> P is a kind of macroscopic representation or notational
> convenience. In mathematics something as sin(x) can be represented as
> sequence of binary operations. See the close relationship!
You should look up the definition of "idée fixe".
> It is clear i am not explaining myself. In the approach i am
> delineating you can write
>
> (::between a x y) or (::ordered x a y) if you want. Simply ::between
> or ::ordered are macro-commands for fundamental binary relationships.
> E.g. in Formal mathematics, one can define (x < a < y) as a notation
> for binary sequence
>
> (x < a) and (a < y)
>
> This is not very different from relaxing ((2+3)+4) to (2+3+4).
How about the notion of `colinear'? You need at least three points to
discuss the notion of colinearity.
Joe Marshall wrote:
> Juan R. wrote:
> > I can understand it can
> > sound strange, but please let me follow this way. In nature,
> >
> > A ==> P
> >
> > is not fundamental, fundamental process is A + S ==> P + S, however A
> > ==> P is a kind of macroscopic representation or notational
> > convenience. In mathematics something as sin(x) can be represented as
> > sequence of binary operations. See the close relationship!
>
> You should look up the definition of "idée fixe".
>
> > It is clear i am not explaining myself. In the approach i am
> > delineating you can write
> >
> > (::between a x y) or (::ordered x a y) if you want. Simply ::between
> > or ::ordered are macro-commands for fundamental binary relationships.
> > E.g. in Formal mathematics, one can define (x < a < y) as a notation
> > for binary sequence
> >
> > (x < a) and (a < y)
> >
> > This is not very different from relaxing ((2+3)+4) to (2+3+4).
>
> How about the notion of `colinear'? You need at least three points to
> discuss the notion of colinearity.
Yes, and the basic Feynman diagram:
\
\
*~~~~~
/
/
is not binary because one can see *three* lines.
Many thanks by assistance, discussion, and amazing jokes.
Bye!
Juan R.
Center for CANONICAL |SCIENCE)
"Juan R." <··············@canonicalscience.com> writes:
>> I think it only works if you already know all the operators when you
>> build your system. What about
>>
>> [nextto over under]
>
> Sorry I do not understand this, what is LISP representation? I do not
> know that you mean by under. In layouts, under is lacking argument.
See! That's the whole point of lisp! You can "interpret" any lisp
form knowing very little about the elements that compose it.
- there is a small and fixed standard list of special operators.
- there are macros.
- all the other operators are functions.
Special operators and macros have their own rules of interpretation,
but macros can be expanded to reduce to function or special operator
calls. So you only need to know the interpretation rules specific to
each special operator.
Functions always get all their arguments evaluated from left to right,
then the function is called.
So any form like:
(over nexto under)
can be interpreted easily:
(special-operator-p 'over) ==> use the special rule.
(macro-function 'over) ==> (macroexpand '(over nexto under))
(fboundp 'over) ==> over is a function to be called with the
values of the nexto and under variables.
otherwise ==> it's an error.
That's all you need to know to understand lisp and to run lisp programs.
--
__Pascal Bourguignon__ http://www.informatimago.com/
"You can tell the Lisp programmers. They have pockets full of punch
cards with close parentheses on them." --> http://tinyurl.com/8ubpf
Pascal Bourguignon wrote:
> See! That's the whole point of lisp! You can "interpret" any lisp
> form knowing very little about the elements that compose it.
Therein i am trying to 'copy' it!
> - there is a small and fixed standard list of special operators.
>
> - there are macros.
>
> - all the other operators are functions.
>
> Special operators and macros have their own rules of interpretation,
> but macros can be expanded to reduce to function or special operator
> calls. So you only need to know the interpretation rules specific to
> each special operator.
>
> Functions always get all their arguments evaluated from left to right,
> then the function is called.
>
> So any form like:
>
> (over nexto under)
>
> can be interpreted easily:
>
> (special-operator-p 'over) ==> use the special rule.
>
> (macro-function 'over) ==> (macroexpand '(over nexto under))
>
> (fboundp 'over) ==> over is a function to be called with the
> values of the nexto and under variables.
>
> otherwise ==> it's an error.
>
> That's all you need to know to understand lisp and to run lisp programs.
nexto here is operator or variable? i assume is always variable. Then
there is not problem with [nexto over under].
If nexto is special operator with zero arguments -e.g. similar to (br)
of SchemeXML- then
(over (nexto) under) is also equivalent to [nexto over under]. No
problem here, since parser can deal with both cases.
The problem (and reason i asked) is if over is a command acting on
nexto and nexto is a command acting on over.
In that case [nexto over under] do not work. Could this case to be
solved in LISP? and how please?
I only can imagine (over nexto under) and ((nexto over) under). But
then both over and nexto are different, e.g. over in first case is
binary operator, whereas in latter over is argument of nexto.
Both case can be distinguished if operators are explicitely marked as
in original CanonML approach: [nexto ::over under].
My current emphasis on simple [nexto over under] is based in LISP and
ASCIIMath.
Juan R.
Center for CANONICAL |SCIENCE)
"Juan R." <··············@canonicalscience.com> writes:
> Pascal Bourguignon wrote:
> > See! That's the whole point of lisp! You can "interpret" any lisp
> > form knowing very little about the elements that compose it.
>
> Therein i am trying to 'copy' it!
>
> > - there is a small and fixed standard list of special operators.
> >
> > - there are macros.
> >
> > - all the other operators are functions.
> >
> > Special operators and macros have their own rules of interpretation,
> > but macros can be expanded to reduce to function or special operator
> > calls. So you only need to know the interpretation rules specific to
> > each special operator.
> >
> > Functions always get all their arguments evaluated from left to right,
> > then the function is called.
> >
> > So any form like:
> >
> > (over nexto under)
> >
> > can be interpreted easily:
> >
> > (special-operator-p 'over) ==> use the special rule.
> >
> > (macro-function 'over) ==> (macroexpand '(over nexto under))
> >
> > (fboundp 'over) ==> over is a function to be called with the
> > values of the nexto and under variables.
> >
> > otherwise ==> it's an error.
> >
> > That's all you need to know to understand lisp and to run lisp programs.
>
> nexto here is operator or variable? i assume is always variable. Then
> there is not problem with [nexto over under].
You see, that is the entire problem that many of us have been
(mostly unsuccessfully) trying to bring to your attention.
You are having to make _assumptions_ about how to interpret the various
parts of the expression. Common Lisp has very simple _rules_ about how
it is done. It just so happens that the simplicity of those rules
depends on the prefix nature of the syntax. It is precisely to gain
this simplicity and uniformity of interpretation that the prefix syntax
is prized.
> If nexto is special operator with zero arguments -e.g. similar to (br)
> of SchemeXML- then
Well, if it were an operator that was supposed to be applied to
arguments, then wouldn't it need to have different syntax? If you want
to be able to pass operators, functions, etc. as arguments, then you
will need a way to distinguish between an application of the function
and a reference to the function itself.
In particular, try to consider how you would want to write a mapping
operator. In particular consider the following examples:
(mapcar #'sqrt '(1.0 4.0 16.0)) ==> (1.0 2.0 4.0)
(mapcar #'+ '(1 2 3) '(1 2 3)) ==> (2 4 6)
(mapcar #'- '(1 2 3)) ==> (-1 -2 -3)
(mapcar #'- '(1 2 3) '(1 2 3)) ==> (0 0 0)
(mapcar #'+ '(1 2 3) '(1 2 3) '(1 2 3)) ==> (3 6 9
and so forth. Especially consider the case where
(mapcar f '(1 2 3) '(1 2 3) '(1 2 3))
where f is passed in as a bound variable.
> (over (nexto) under) is also equivalent to [nexto over under]. No
> problem here, since parser can deal with both cases.
Well, if you have two different interpretations that are both equivalent
to your starting form, then it looks like you will need some sort of
non-deterministic parser. Having such ambiguity is a killer.
> The problem (and reason i asked) is if over is a command acting on
> nexto and nexto is a command acting on over.
>
> In that case [nexto over under] do not work. Could this case to be
> solved in LISP? and how please?
This case is trivially solved in Lisp.
That was the point of Pascal Bourguinon's reply.
There is a uniform rule for interpreting s-expressions that is based on
having a uniform, prefix syntax. You do not need to consider all of
these complicated cases, because the syntax makes it clear which of the
interpretations is the correct one.
> I only can imagine (over nexto under) and ((nexto over) under). But
> then both over and nexto are different, e.g. over in first case is
> binary operator, whereas in latter over is argument of nexto.
>
> Both case can be distinguished if operators are explicitely marked as
> in original CanonML approach: [nexto ::over under].
>
> My current emphasis on simple [nexto over under] is based in LISP and
> ASCIIMath.
Not entirely it isn't.
You seem to start with the lisp solution, and then attempt to remove
the part of the interpretation rule (prefix notation) which makes such
an interpretation unambiguous.
You have reacted so viscerally against prefix notation and tried to
remove it from your system without actually understanding the design
decisions that led to its adoption. You continue to do this, even in
the face of large amounts of examples pointing up difficulties with your
preferred method of having a mixture of prefix and infix notations.
Then when we point out problems in your approach, you ask how it is
solved in lisp. The answers are provided above.
--
Thomas A. Russ, USC/Information Sciences Institute
Thomas A. Russ wrote:
> You see, that is the entire problem that many of us have been
> (mostly unsuccessfully) trying to bring to your attention.
Sorry by inconvenience, I did an effort to understand! and i think that
most part of confusion become from the fact we were talking "different
languages"!
> You are having to make _assumptions_ about how to interpret the various
> parts of the expression. Common Lisp has very simple _rules_ about how
> it is done. It just so happens that the simplicity of those rules
> depends on the prefix nature of the syntax. It is precisely to gain
> this simplicity and uniformity of interpretation that the prefix syntax
> is prized.
Maybe the whole problem is we become from different comunities and it
is being obvious for one is not for the other; for instance you are
using "very simple" for I would call complex and apparently you call
complex I consider simple.
My apologies also for my often bad (or incomplete) explanations in this
list.
> > If nexto is special operator with zero arguments -e.g. similar to (br)
> > of SchemeXML- then
>
> Well, if it were an operator that was supposed to be applied to
> arguments, then wouldn't it need to have different syntax?
Initially I thought that and provided "::" as an version of TeX "\".
However, a system as ASCIIMath omits the "\" for encoding
presentational mathematics. I simply am exploring now that posibility.
Probably, I will perform a poll on the topic and users and visitors
will choose they prefer.
> If you want
> to be able to pass operators, functions, etc. as arguments, then you
> will need a way to distinguish between an application of the function
> and a reference to the function itself.
I think that I can. I have not decided still the way, but I have
several thoughts and different versions of CanonCode module on my table
now.
> In particular, try to consider how you would want to write a mapping
> operator. In particular consider the following examples:
>
> (mapcar #'sqrt '(1.0 4.0 16.0)) ==> (1.0 2.0 4.0)
> (mapcar #'+ '(1 2 3) '(1 2 3)) ==> (2 4 6)
> (mapcar #'- '(1 2 3)) ==> (-1 -2 -3)
> (mapcar #'- '(1 2 3) '(1 2 3)) ==> (0 0 0)
> (mapcar #'+ '(1 2 3) '(1 2 3) '(1 2 3)) ==> (3 6 9
I see not difficulty here. I do not know still what final method I will
follow.
> and so forth. Especially consider the case where
>
> (mapcar f '(1 2 3) '(1 2 3) '(1 2 3))
>
> where f is passed in as a bound variable.
>
> > (over (nexto) under) is also equivalent to [nexto over under]. No
> > problem here, since parser can deal with both cases.
>
> Well, if you have two different interpretations that are both equivalent
> to your starting form, then it looks like you will need some sort of
> non-deterministic parser. Having such ambiguity is a killer.
No, parser is deterministic.
> > The problem (and reason i asked) is if over is a command acting on
> > nexto and nexto is a command acting on over.
> >
> > In that case [nexto over under] do not work. Could this case to be
> > solved in LISP? and how please?
>
> This case is trivially solved in Lisp.
If I had received an euro each time I heard this during my life I would
become rich!
> That was the point of Pascal Bourguinon's reply.
> There is a uniform rule for interpreting s-expressions that is based on
> having a uniform, prefix syntax.
Some maintainers of LISP compilers would call uniform the philosophy
underlying my own (non-LISP) approach whereas disliking CL code as
unelegant or even contrary to LISP original style.
> You do not need to consider all of
> these complicated cases, because the syntax makes it clear which of the
> interpretations is the correct one.
Take a pair of "clear examples"; how would you interpret LISP code
below?
example_1
(DEFUN F (X) (+ X 1))
(DEFUN G (F) (F 3))
example_2
(DEFUN PRINT-SQUARES (LIST)
(DOLIST (ELEMENT LIST)
(PRINT (LIST ELEMENT (EXPT ELEMENT 2)))))
Well the theoretical view varies in function of kind of programming
philosophy (academician? industrial oriented?). Whereas some LISP
compilers can understand some examples cannot understand others and
would offer error.
In fact, i have been recently trained that some LISP programmers do
mistakes when arrive to a different LISP family. And i am not refering
to changes in reserved commands, but that something so simple as (LIST
LIST) can be valid code for some LISPs and incorrect for others.
<blockquote>
To some programmers, a basic 'rule' of Lisp style is that code is
clearest when the least amount of context is necessary to determine the
meaning of an expression. Unfortunately, that rule is violated in [CL].
</blockquote>
My own design goes beyond "pure" LISP since commands can be interpreted
with less context that in "pure" (academic oriented) LISP. See below.
> > I only can imagine (over nexto under) and ((nexto over) under). But
> > then both over and nexto are different, e.g. over in first case is
> > binary operator, whereas in latter over is argument of nexto.
> >
> > Both case can be distinguished if operators are explicitely marked as
> > in original CanonML approach: [nexto ::over under].
> >
> > My current emphasis on simple [nexto over under] is based in LISP and
> > ASCIIMath.
>
> Not entirely it isn't.
I did mean just "elimination of the ::" was based in LISP and ASCIIMath
since both do not use special tags for operators (unlike TeX using
"\"). Still i need explore a bit the concept before seeing pros and
cons of using "::" for code and math. In textual mode, i have no doubt
and i will use something as
[::emph this is an important text]
before LISP
(emph "this is an important text").
> You seem to start with the lisp solution, and then attempt to remove
> the part of the interpretation rule (prefix notation) which makes such
> an interpretation unambiguous.
That is, according to you the strong point of the interpretation rule
(prefix notation) is that results in an unambigous interpretations of
an expression, X:
(X ...) vs. (... X ...)
E.g. CL can differentiate LIST on
(ELEMENT LIST)
and on
(LIST ELEMENT)
because the prefix position. But that obligate to know the context
before calling the function. In my approach the CL sequence
[ELEMENT LIST]
[LIST ELEMENT]
is *illegal* (just as it is in other LISPs). But whereas those "pure"
(academic) LISP dialects eliminate many CL context from evaluation,
still remain using the prefix notation (I understand firmly based on
dotted pairs). The prefix notation obligates to add a new kind of
"context": parentheses.
Whithout parentheses, "pure" LISP cannot understand something as (...
BR ...) and you may type (... (BR) ...).
But, i am not using dotted pairs, just c-expr that are a generalization
of Keizer vectors:
(n^+) = (n^-)
In my approach [a b c] is not [a.[b.[c.NIL]]] or similar. Therefore the
emphasis on dualism notation <-> data disappear. I have understood
failures to provide an infix notation for LISP systems, but i am not
constrained by dotted pairs or similar.
Therefore my approach, introduces the same X command (e.g. rho or
partial) in any place
[partial rho over partial t] = L rho]
That can be seen as a minimalist modification of above "basic rule of
LISP style":
<blockquote>
... a basic 'rule' of Canon style is that code is clearest when the
minimal amount of context (including position in a list) is necessary
to determine the meaning of an expression. Unfortunately, that rule is
violated in [LISP].
</blockquote>
For any scientist or mathematician i know, that the partial command
after "[" was different from the partial command after "over" in above
mathematical formula would be more than a surprise, and target matters.
Therefore, i see no reason which [LIST LIST] would embrace two
different concepts of item LIST when writing in the code module
[%% [LIST LIST]]
whereas (beta beta) would mean sequence of the *same* beta when writing
in the formal-scientific module:
[::formal [beta beta]].
Is this approach limited? Is the rule too minimalist and at the end i
will finalize with something more "industrial" more CL oriented. I do
*not* know; it is a research in progress. Today it is working very well
for the target delineated at the very beggining of the program.
> You have reacted so viscerally against prefix notation and tried to
> remove it from your system without actually understanding the design
> decisions that led to its adoption. You continue to do this, even in
> the face of large amounts of examples pointing up difficulties with your
> preferred method of having a mixture of prefix and infix notations.
Try to understand me. If you are able to convince my users/visitors to
use a fully prefix notation during this year, then I will sure you that
I will abandon this project and turn to use a standard LISP approach
for 2007.
But my personal experience, some feedback and informal polls, and a
simple look to the infinitesimal impact of near 40 years of promotion
of prefix notation from the LISP community...
> Then when we point out problems in your approach, you ask how it is
> solved in lisp. The answers are provided above.
>
> --
> Thomas A. Russ, USC/Information Sciences Institute
Many thanks by collaboration and useful discussion. Since i already
solved my initial enquiry about LISP prefix notation i would do not
disturb this list more.
Juan R.
Center for CANONICAL |SCIENCE)
"Juan R." <··············@canonicalscience.com> writes:
> Take a pair of "clear examples"; how would you interpret LISP code
> below?
>
> example_1
>
> (DEFUN F (X) (+ X 1))
>
> (DEFUN G (F) (F 3))
In G, the second F doesn't refer the first.
(g z) == (f 3) == (+ 3 1)
Try scheme if you want it differently:
(define (f x) (+ x 1))
(define (g f) (f 3))
(g (lambda (x) (* 2 x))) --> 6
> example_2
>
> (DEFUN PRINT-SQUARES (LIST)
> (DOLIST (ELEMENT LIST)
> (PRINT (LIST ELEMENT (EXPT ELEMENT 2)))))
This works perfectly in Common-Lisp, and (the equivalent would) fail in scheme.
> Well the theoretical view varies in function of kind of programming
> philosophy (academician? industrial oriented?). Whereas some LISP
> compilers can understand some examples cannot understand others and
> would offer error.
>
> In fact, i have been recently trained that some LISP programmers do
> mistakes when arrive to a different LISP family. And i am not refering
> to changes in reserved commands,
There no "reserved commands" properly in Common Lisp.
> but that something so simple as (LIST
> LIST) can be valid code for some LISPs and incorrect for others.
> [...]
> E.g. CL can differentiate LIST on
>
> (ELEMENT LIST)
>
> and on
>
> (LIST ELEMENT)
>
> because the prefix position. But that obligate to know the context
> before calling the function. In my approach the CL sequence
>
> [ELEMENT LIST]
> [LIST ELEMENT]
>
> is *illegal* (just as it is in other LISPs).
This is legal in ALL LISPs, including scheme:
Welcome to MzScheme version 299.200, Copyright (c) 2004-2005 PLT Scheme, Inc.
> (define (element list) list)
> (define (list element) (cons element '()))
> (element list)
#<procedure:list>
> (list element)
(#<procedure:element>)
> [...]
> Whithout parentheses, "pure" LISP cannot understand something as (...
> BR ...) and you may type (... (BR) ...).
What is "pure" LISP?
In Common Lisp, if you need to call a function when you write a
symbol, you can define a symbol macro:
(defvar *br-from-symbol-macro* nil)
(define-symbol-macro br (let ((*br-from-symbol-macro* t)) (br)))
(defun br ()
(format t "~&Called as ~:[function~;variable~]~%" *br-from-symbol-macro*)
:br)
[200]> (br)
Called as function
:BR
[201]> (list "Some" br "values")
Called as variable
("Some" :BR "values")
[202]> (list "Some" (br) "values")
Called as function
("Some" :BR "values")
> [...]
--
__Pascal Bourguignon__ http://www.informatimago.com/
"You question the worthiness of my code? I should kill you where you
stand!"
Thomas A. Russ wrote:
> That is why "a+b" is
> unambiguously an arithmetic expression in Java. In Lisp it is a
> symbol. [Digression: In Dylan, it is a symbol, but "a + b" is an
> arithmetic expression].
Thanks Thomas! Even though you are responding to a troll I still
learned some intesting things from your posting.
--fj
funkyj wrote:
> Thomas A. Russ wrote:
>
> > That is why "a+b" is
> > unambiguously an arithmetic expression in Java. In Lisp it is a
> > symbol. [Digression: In Dylan, it is a symbol, but "a + b" is an
> > arithmetic expression].
>
> Thanks Thomas! Even though you are responding to a troll I still
> learned some intesting things from your posting.
>
> --fj
You are the T troll filling this list with anonimous attacks, and
moreover you are a snob cobard. Funk you NIL!
Juan R. wrote:
> funkyj wrote:
>
>>Thomas A. Russ wrote:
>>
>>
>>>That is why "a+b" is
>>>unambiguously an arithmetic expression in Java. In Lisp it is a
>>>symbol. [Digression: In Dylan, it is a symbol, but "a + b" is an
>>>arithmetic expression].
>>
>>Thanks Thomas! Even though you are responding to a troll I still
>>learned some intesting things from your posting.
>>
>> --fj
>
>
> You are the T troll filling this list with anonimous attacks, and
> moreover you are a snob cobard. Funk you NIL!
>
No, no, no. You are doing fine, don't get into the troll-not-troll
thing, we love trolls here.
It is obvious you are a troll, anyway. Asking a question when you
already had your mind made up, responding to every article, whining
about nonsense like how to write highly efficient mathematical notation
in a programming language. Don't worry, these dolts will never pick up
on that stupidity. jeez, mathematicians encode exponents using 2d
orientation and decremented font size - what programming language does
that? Fractions, vertical orientation. What PL does that? What PL does
implied multiplication? lemme check... oh, none!
So shut up on the troll issue and you can keep this going for weeks.
Now what was the Feynman joke?
kenny
--
Cells: http://common-lisp.net/project/cells/
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Ken Tilton wrote:
> It is obvious you are a troll, anyway. Asking a question when you
> already had your mind made up, responding to every article, whining
> about nonsense like how to write highly efficient mathematical notation
> in a programming language.
My optimism and faith in the human race leads me to refuse to believe
that trolls like Juan and Xah are human -- no human, no matter how
stupid could drone on for so long without getting bored! These guys
are actually grad student thesis showing that the "turing test" sets
the bar waaaaay too low ;^)
As drivel from a human troll this stuff is annoying but viewed as an AI
project it is more interesting...
--fj
funkyj wrote:
> Ken Tilton wrote:
>
> > It is obvious you are a troll, anyway. Asking a question when you
> > already had your mind made up, responding to every article, whining
> > about nonsense like how to write highly efficient mathematical notation
> > in a programming language.
>
> My optimism and faith in the human race leads me to refuse to believe
> that trolls like Juan and Xah are human -- no human, no matter how
> stupid could drone on for so long without getting bored! These guys
> are actually grad student thesis showing that the "turing test" sets
> the bar waaaaay too low ;^)
>
> As drivel from a human troll this stuff is annoying but viewed as an AI
> project it is more interesting...
>
> --fj
Obsession FUNKYouJ?
[http://www.obsessionwithfood.com/]
Juan R.
Center for CANONICAL |SCIENCE)
Ken Tilton wrote:
>
> No, no, no. You are doing fine, don't get into the troll-not-troll
> thing, we love trolls here.
>
> It is obvious you are a troll, anyway. Asking a question when you
> already had your mind made up,
false
> responding to every article,
This may be your problem.
> whining
> about nonsense like how to write highly efficient mathematical notation
> in a programming language. Don't worry, these dolts will never pick up
> on that stupidity. jeez, mathematicians encode exponents using 2d
> orientation and decremented font size - what programming language does
> that?
I can understand ignorance but i am not polite with stupid and arrogant
people.
I doubt what is your definition of PL, but if Scheme is a PL for you...
TeX code c^2 can be encoded as s-expr via
(msup (mi c) (mn 2))
> Fractions, vertical orientation. What PL does that?
TeX code {a \over b} is typed as
(mfrac (mi a) (mi b))
> What PL does
> implied multiplication? lemme check... oh, none!
Using Scheme XPath and Scheme XSLT one can match and transform anything
s-expr as
(mrow (mi a) (mi b))
to
(apply (times) (ci a) (ci b))
and latter to standard LISP (* a b)
In fact, even one can ignore presentational mathematical markup and use
generic pure presentational markup for exponents for instance,using
Scheme representation of layout code.
(fo:inline-block base... superindex...)
[Rest of your nonsense erased]
I am searching an "input" syntax -CanonML- that
CanonML ==> LISP for simbolic computation
CanonML ==> TeX for printing
CanonML ==> MathML, XML-MAIDEN or other for web
Juan R.
Center for CANONICAL |SCIENCE)
Juan R. wrote:
> Ken Tilton wrote:
>
>>No, no, no. You are doing fine, don't get into the troll-not-troll
>>thing, we love trolls here.
>>
>>It is obvious you are a troll, anyway. Asking a question when you
>>already had your mind made up,
>
>
> false
>
>
>>responding to every article,
>
>
> This may be your problem.
>
>
>>whining
>>about nonsense like how to write highly efficient mathematical notation
>>in a programming language. Don't worry, these dolts will never pick up
>>on that stupidity. jeez, mathematicians encode exponents using 2d
>>orientation and decremented font size - what programming language does
>>that?
>
>
> I can understand ignorance but i am not polite with stupid and arrogant
> people.
>
> I doubt what is your definition of PL, but if Scheme is a PL for you...
>
> TeX code c^2 can be encoded as s-expr via
>
> (msup (mi c) (mn 2))
You are not as smart as you think you are. I meant what text editor
(besides, mine of course)* allows you to edit mathematics in wysiwyg
fashion (and, no, I do not mean so-called equation editors that feel
like erector sets) and then what computer language understands the
output of that editor?
Perhaps now the (I thought) obvious will not elude you: math has a
highly evolved efficient scheme for conveying its abstract semantics.
Judging a language by how well it stacks up against that is... a great
troll?
Infix gives one tiny win over prefix, and then.... all PLs suck. My
final thought is that one programs with a PL, one does not do
mathematics symbolically such as solve an algebra problem by moving down
the screen typing in C or Fortran or Lisp. So all you have to do is
translate from the final mathematics result to the PL. There is a
difference between working in a notation and translating to one.
But do not worry, these guys always respond literally to whatever is put
in front of them, even after the troll is pointed out.
Now what was the damn joke! "Three lines are in a small particle about
to decay and there is only one wormhole..."?
kt
* Anyone actually know of a good one?
>
>
>>Fractions, vertical orientation. What PL does that?
>
>
> TeX code {a \over b} is typed as
>
> (mfrac (mi a) (mi b))
You are not listening. I want to type it in wysiwyg and see it
vertically with these the keystrokes "a" "/" "b"! And have my language
understand it needs to divide. Fortran might make a comeback.
k
--
Cells: http://common-lisp.net/project/cells/
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Ken Tilton <·········@gmail.com> writes:
> [...]
>
> jeez, mathematicians encode exponents using 2d orientation and
> decremented font size - what programming language does that?
> Fractions, vertical orientation. What PL does that? What PL does
> implied multiplication? lemme check... oh, none!
Well, FORTRESS does ;-) Or at least it will, when it's done. From page
38 of the preliminary language report [1]:
Simple juxtaposition is also regarded as an infix operator in
Fortress. When the left operand is a function, juxtaposition
performs function application; when the left operand is a number,
juxtaposition conventionally performs multiplication; when the
left operand is a string, juxtaposition conventionally performs
string concatenation.
On the same page, there are also examples for some of the other things
you mention.
Personally, I think that Fortress' approach is totally misguided. The
reason I bring it up is more as a warning as to what will become of a
language that tries to imitate mathematic notation (or any other
"natural" notation for that matter) very closely.
Wolfram
Footnotes:
[1] <http://research.sun.com/projects/plrg/fortress0903.pdf>
Wolfram Fenske wrote:
> Ken Tilton <·········@gmail.com> writes:
>
>
>>[...]
>>
>>jeez, mathematicians encode exponents using 2d orientation and
>>decremented font size - what programming language does that?
>>Fractions, vertical orientation. What PL does that? What PL does
>>implied multiplication? lemme check... oh, none!
>
>
> Well, FORTRESS does ;-) Or at least it will, when it's done.
Interesting: "2 pi radian / 200 million year"
But not good enough. They need a math savvy editor that can lay things
out naturally, and make the editing as fluid as possible. Hmmm, maybe I
have a customer/client...
kt
--
Cells: http://common-lisp.net/project/cells/
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Wolfram Fenske wrote:
> Ken Tilton <·········@gmail.com> writes:
>
> > [...]
> >
> > jeez, mathematicians encode exponents using 2d orientation and
> > decremented font size - what programming language does that?
> > Fractions, vertical orientation. What PL does that? What PL does
> > implied multiplication? lemme check... oh, none!
>
> Well, FORTRESS does ;-) Or at least it will, when it's done. From page
> 38 of the preliminary language report [1]:
>
> Simple juxtaposition is also regarded as an infix operator in
> Fortress. When the left operand is a function, juxtaposition
> performs function application; when the left operand is a number,
> juxtaposition conventionally performs multiplication; when the
> left operand is a string, juxtaposition conventionally performs
> string concatenation.
Also mathematica (and Maple if i remember correctly) are able to do
that. m c is interpreted as (m * c). I do not know if Mathematica is
considered a PL here but some people think so.
> On the same page, there are also examples for some of the other things
> you mention.
>
> Personally, I think that Fortress' approach is totally misguided. The
> reason I bring it up is more as a warning as to what will become of a
> language that tries to imitate mathematic notation (or any other
> "natural" notation for that matter) very closely.
>
>
> Wolfram
>
> Footnotes:
> [1] <http://research.sun.com/projects/plrg/fortress0903.pdf>
Thanks by this link it is very interesting!
Juan R.
Center for CANONICAL |SCIENCE)
On Wed, 28 Jun 2006 20:31:03 +0200, Wolfram Fenske <·····@gmx.net> wrote:
> Ken Tilton <·········@gmail.com> writes:
>
>> [...]
>>
>> jeez, mathematicians encode exponents using 2d orientation and
>> decremented font size - what programming language does that?
>> Fractions, vertical orientation. What PL does that? What PL does
>> implied multiplication? lemme check... oh, none!
>
> Well, FORTRESS does ;-) Or at least it will, when it's done. From page
> 38 of the preliminary language report [1]:
>
> Simple juxtaposition is also regarded as an infix operator in
> Fortress. When the left operand is a function, juxtaposition
> performs function application; when the left operand is a number,
> juxtaposition conventionally performs multiplication; when the
> left operand is a string, juxtaposition conventionally performs
> string concatenation.
>
> On the same page, there are also examples for some of the other things
> you mention.
>
> Personally, I think that Fortress' approach is totally misguided. The
> reason I bring it up is more as a warning as to what will become of a
> language that tries to imitate mathematic notation (or any other
> "natural" notation for that matter) very closely.
>
>
> Wolfram
>
> Footnotes:
> [1] <http://research.sun.com/projects/plrg/fortress0903.pdf>
>
Speaking of wolfram.
I think Mathematica has a great language for describing mathematics.
Have you take a look at that?
It combines a Lisp like syntax with pattern matching capabilities.
I could talk about it all day but it is probably better if you
see for yourself. Get a 1 month trial copy at
http://www.wolfram.com.
John
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
"Juan R." <··············@canonicalscience.com> writes:
> Harald Hanche-Olsen wrote:
> > The advantage of Lisp syntax becomes obvious once you start playing
> > with macros. Since the relation between a Lisp expression and the
> > corresponding parse tree is more or less trivial, and macros work on
> > the parse tree level, complex macros are orders of magnitude easier to
> > write and understand than they otherwise would. (And they need to be,
> > since macros can quickly become quite hard to understand anyhow.)
> >
>
> I see not further difficulties with something like
>
> (A -> B)
>
> instead
>
> (-> A B)
>
> Do you know some reference where this was explained to a formal level?
Well, not at a formal level, but consider the following bit of lisp
code:
(defun a (x y) (+ x y))
(defun -> (x y) (- x y))
(let ((a 1)
(b 2)
(-> 10))
(list (a -> b)
(-> a b)))
So what is this supposed to return?
One of the points about the uniform syntax of lisp is that functions and
variables and many other things in the lisp system are named by symbols.
Any symbols. There are no special characters which name only
operators. In Java, for example, you can't name an operator "+", so if
you see the plus sign, you don't have to worry about whether it names a
variable, or if it is even part of a variable. That is why "a+b" is
unambiguously an arithmetic expression in Java. In Lisp it is a
symbol. [Digression: In Dylan, it is a symbol, but "a + b" is an
arithmetic expression].
So the real reason for always using prefix notation is because one
really wants to know, without any clues from the symbol name, which
symbol names the operator of the s-expression. Having the operator
always be the first element works great. No other convention would work
as well, at least not if you wanted to also support unary operators.
Except for the degenerate case of (), there is always a first element.
I suppose that one could come up with a more complicated system in which
the operator is the first element, unless there are three subforms, in
which case the operator is the second element. If there are more than
three subforms, the operator is the first element again? Some other
choice? And even for the unary case, I bet if you get binary operators,
you would also like to get postfix operators like ! for factorial.
Now this is beginning to get muchly more complicated, and doesn't even
help you with everything because you also can, I'm sure, come up with
binary operators that you would prefer not be in-fix.
>
> Juan R.
>
> Center for CANONICAL |SCIENCE)
>
--
Thomas A. Russ, USC/Information Sciences Institute
> Whereas i see the point of advantages of something as
>
> (+ (* 1 2) (/ 3 4))
>
> over algebraic
>
> 1 * 2 + 3 / 4
>
> -specially when managing dozens of operators- i am unable to see
> realistic advantages over infix notation
>
> ((1 * 2) + (3 / 4))
what about
(+ (* 1 2 3) (/ 4 5 6))
vs
((1 * 2 * 3) + (4 / 5 / 6))
Takehiko Abe wrote:
>
> what about
>
> (+ (* 1 2 3) (/ 4 5 6))
>
> vs
>
> ((1 * 2 * 3) + (4 / 5 / 6))
Yes, but
i) In my experience in science those constructs are unusual. Mixed
operators sequences are more usual and in practice simplification of
prefix notation is not noted.
ii) I tend to think in terms of binary operations and then something as
(* 1 2 3)
looks "non-mathematical". I would prefer
(* * 1 2 3)
Moreover, the translation between both forms infix and prefix is simple
and computer can do it very well.
Maybe in the past, prefix notation was a requirement for hardware but
today i see no realistic advantage (unless i was completely wrong).
Juan R.
Center for CANONICAL |SCIENCE)
On Fri, 23 Jun 2006 20:14:09 +0200, Juan R. <··············@canonicalscience.com> wrote:
> Maybe in the past, prefix notation was a requirement for hardware but
> today i see no realistic advantage (unless i was completely wrong).
Then you are lucky: most programming languages don't use
sexpr notation.
What are you complaining about? (btw, yes).
P.
--
Anything below this line is being added by the newsserver
Inviato da X-Privat.Org - Registrazione gratuita http://www.x-privat.org/join.php
> > what about
> >
> > (+ (* 1 2 3) (/ 4 5 6))
> >
> > vs
> >
> > ((1 * 2 * 3) + (4 / 5 / 6))
>
> Yes, but
>
> i) In my experience in science those constructs are unusual. Mixed
> operators sequences are more usual and in practice simplification of
> prefix notation is not noted.
>
> ii) I tend to think in terms of binary operations and then something as
>
>
> (* 1 2 3)
>
> looks "non-mathematical". I would prefer
>
> (* * 1 2 3)
Ah. I guess Lisp is not for you then.
I think that either you like it or you hate it on the first
sight. Do not try too hard. It's futile.
····@gol.com (Takehiko Abe) writes:
>> [...]
>>
>> ii) I tend to think in terms of binary operations and then something as
>>
>> (* 1 2 3)
>>
>> looks "non-mathematical". I would prefer
>>
>> (* * 1 2 3)
>
> Ah. I guess Lisp is not for you then.
>
> I think that either you like it or you hate it on the first
> sight. Do not try too hard. It's futile.
Not necessarily. At least, it wasn't for me. When I first saw lisp,
I thought the designers were simply too lazy to write a real parser
and that the language wasn't all that great. Much later, I stumbled
upon Paul Graham's essays where he claimed over and over that lisp was
the most powerful programming language ever invented, and after
reading several of them, I started believing him. To see what it's
all about, I bought Peter Seibel's excellent book, "Practical Common
Lisp," finally got macros and now I'm something of a convert.
Understanding macros is essential to appreciating the power of lisp,
though. IMO, if lisp didn't have its macro system, there'd be no
significant advantage over, say, Python and hardly any justification
for its (lack of) syntax.
Wolfram
Wolfram Fenske wrote:
> ····@gol.com (Takehiko Abe) writes:
>> Ah. I guess Lisp is not for you then.
>>
>> I think that either you like it or you hate it on the first
>> sight. Do not try too hard. It's futile.
>
> Not necessarily. At least, it wasn't for me. When I first saw lisp,
> I thought the designers were simply too lazy to write a real parser
> and that the language wasn't all that great. Much later, I stumbled
> upon Paul Graham's essays where he claimed over and over that lisp was
> the most powerful programming language ever invented, and after
> reading several of them, I started believing him. To see what it's
> all about, I bought Peter Seibel's excellent book, "Practical Common
> Lisp," finally got macros and now I'm something of a convert.
> Understanding macros is essential to appreciating the power of lisp,
> though. IMO, if lisp didn't have its macro system, there'd be no
> significant advantage over, say, Python and hardly any justification
> for its (lack of) syntax.
>
An interesting view, and quite the opposite of what makes me thick. It
is precisely the lack of syntax that I admire in Lisp (Scheme actually).
I did learn Python (some years ago), and did not like the extra syntax
much, but most of all what made me drop Python was that at version 2.1,
they still did not get the lexical scope properly (failing to create
closures). As for really impressive syntax languages like Java, I did
manage to read one 900+ Java book, but it was a really painful
experience. I had to constantly flip back not for failing to understand
how exercises were supposed to be solved, but for not being able to
remember the ton of syntax that Java was throwing at me. But then again,
I'm getting old, so maybe that is the problem :-)
-- Hrvoje
Hrvoje Blazevic <······@despammed.com> writes:
> Wolfram Fenske wrote:
>> ····@gol.com (Takehiko Abe) writes:
>>> Ah. I guess Lisp is not for you then.
>>>
>>> I think that either you like it or you hate it on the first
>>> sight. Do not try too hard. It's futile.
>>
>> Not necessarily. At least, it wasn't for me. When I first saw
>> lisp, I thought the designers were simply too lazy to write a real
>> parser and that the language wasn't all that great. Much later, I
>> stumbled upon Paul Graham's essays where he claimed over and over
>> that lisp was the most powerful programming language ever invented,
>> and after reading several of them, I started believing him. To see
>> what it's all about, I bought Peter Seibel's excellent book,
>> "Practical Common Lisp," finally got macros and now I'm something
>> of a convert. Understanding macros is essential to appreciating
>> the power of lisp, though. IMO, if lisp didn't have its macro
>> system, there'd be no significant advantage over, say, Python and
>> hardly any justification for its (lack of) syntax.
>
> An interesting view, and quite the opposite of what makes me
> thick. It is precisely the lack of syntax that I admire in Lisp
> (Scheme actually).
Admittedly, that has a certain aesthetic beauty to it. There's hardly
any syntax in the core language of CL and of Scheme, i. e. the basic
evaluation rules plus the special operators. But when it comes to
macros, you get additional, non-regular syntax in Lisp as well.
I think there are some cases where more syntax would be nice in Lisp.
One thing I especially like in Python is it's notation for accessing
elements or subsequences of a sequence, the abstract super-type of
string, list, tuple and dictionary (Python's hash table). For
elements it's simply
elem = seq[i]
seq[i] = new_elem
For subsequences it's
sub_seq = seq[i:j]
seq[i:j] = new_sub_seq
I find that more convenient and easier to read than what standard CL
offers, namely
(let ((elem (elt seq i)))
...)
(setf (elt seq i) new-elem)
(let ((sub-seq (subseq seq i j)))
...)
(setf (subseq seq i j) new-sub-seq)
I guess one could write a reader macro to transform foo[i] into (elt
foo i). Hm ... Anyway, in the presence of CL's macro system, these
issues become way less important for me, since I can spare myself so
much stupid typing that having to write (elt seq i) is a small price
to pay. *But:* If I were to design a new programming language without
such a powerful macro system (not that I want that), I'd probably not
choose S-expressions because I think other representations would be
more suitable.
> I did learn Python (some years ago), and did not like the extra
> syntax much, but most of all what made me drop Python was that at
> version 2.1, they still did not get the lexical scope properly
> (failing to create closures).
That's indeed quite disappointing.
> As for really impressive syntax languages like Java, I did manage to
> read one 900+ Java book, but it was a really painful experience.
No doubt about that. ;-)
> I had to constantly flip back not for failing to understand how
> exercises were supposed to be solved, but for not being able to
> remember the ton of syntax that Java was throwing at me. But then
> again, I'm getting old, so maybe that is the problem :-)
Hehe! :-) Certainly Java isn't the best example of a language without
S-expression-syntax. But there's e. g. Ruby, Python, Perl or OCaml
[1].
I guess my point was, although I didn't express it very clearly in my
other post, that I'm more than fine with S-expressions in Lisp because
it gets me this powerful macro system. But if I didn't have that, I
think I'd prefer another syntax.
Wolfram
Footnotes:
[1] OCaml actually lets you extend the parser so that you can build
your own preprocessor (don't think C preprocessor here) that
transforms your dialect into proper OCaml code which then gets
compiled. It's not as nicely integrated as CL's macros but equally
powerful.
Wolfram Fenske wrote:
> Hehe! :-) Certainly Java isn't the best example of a language without
> S-expression-syntax. But there's e. g. Ruby, Python, Perl or OCaml
> [1].
My personal favorite is Haskell, and OCaml would be second when it comes
to non s-expression syntax. Interestingly enough, Haskell syntax never
bothered me, and just like with Scheme, I could read a CS book (that
does not teach Haskell as per se), without thinking much about the
syntax. Maybe the problem is not in the syntax alone, but the coupling
of the syntax with the programming paradigm. My brain must be wired
functionally :-). That would rule out Ruby, Python and Perl.
-- Hrvoje
> > I think that either you like it or you hate it on the first
> > sight. Do not try too hard. It's futile.
>
> Not necessarily. At least, it wasn't for me.
I see.
> [...]
>
> Understanding macros is essential to appreciating the power of lisp,
> though. IMO, if lisp didn't have its macro system, there'd be no
> significant advantage over, say, Python and hardly any justification
> for its (lack of) syntax.
So you tolerate the lisp's (non) syntax because of macros?
That's too bad. I guess I am a happier lisper than you.
Wild guess: Some people don't like prefix notation perhaps
because they want to read the code aloud? It's not speech
oriented.
····@gol.com (Takehiko Abe) writes:
>> > I think that either you like it or you hate it on the first
>> > sight. Do not try too hard. It's futile.
>>
>> [...]
>>
>> Understanding macros is essential to appreciating the power of lisp,
>> though. IMO, if lisp didn't have its macro system, there'd be no
>> significant advantage over, say, Python and hardly any justification
>> for its (lack of) syntax.
>
> So you tolerate the lisp's (non) syntax because of macros?
> That's too bad. I guess I am a happier lisper than you.
If CL didn't have its macros, I'm pretty sure that one could find
another syntax that would lead to programs that are both shorter and
easier to read and understand than equivalent programs using s-expr
syntax. As I wrote in another post:
I think there are some cases where more syntax would be nice in
Lisp. [...] If I were to design a new programming language
without such a powerful macro system (not that I want that), I'd
probably not choose S-expressions because I think other
representations would be more suitable.
One example I gave were references to array elements. In Python you
write:
elem = seq[i]
seq[i] = new_elem
Where seq is a sequence type, i. e. a list, a tuple, a string or a
dictionary. In CL you have to write:
(let ((elem (elt seq i)))
...)
(setf (elt seq i) new-elem)
I'm sure there are other examples.
> Wild guess: Some people don't like prefix notation perhaps
> because they want to read the code aloud? It's not speech
> oriented.
I don't know what you mean.
Wolfram
"Wolfram Fenske" <·····@gmx.net> writes:
> One example I gave were references to array elements. In Python you
> write:
>
> elem = seq[i]
> seq[i] = new_elem
>
> Where seq is a sequence type, i. e. a list, a tuple, a string or a
> dictionary. In CL you have to write:
>
> (let ((elem (elt seq i)))
> ...)
> (setf (elt seq i) new-elem)
In CL muss man meist nicht muessen:
(defmacro with-implicit ((op on &rest args) &body body)
(assert (eq on :on))
`(macrolet ,(mapcar (lambda (arg) `(,arg (&rest #1=#:rest) `(,',op ,',arg
,@#1#))) args) ,@body))
(defmacro := (&rest args) `(setf ,@args))
(let ((x (vector 1 2 3)) (y (list 4 5 6)))
(with-implicit (elt :on x y)
(format t "first x: ~10s y: ~10s x[1]: ~3s y[2]: ~3s ~%" x y (x 1) (y 2))
(:= (x 1) (- (x 1))
(y 2) (- (y 2)))
(format t "later x: ~10s y: ~10s x[1]: ~3s y[2]: ~3s ~%" x y (x 1) (y 2))
))
'as
> If CL didn't have its macros, I'm pretty sure that one could find
> another syntax that would lead to programs that are both shorter and
> easier to read and understand than equivalent programs using s-expr
> syntax.
I guess that's one reason why some people invented Dylan. But it
didn't fly. The problem is that some of us don't feel that way.
I can point the two typos:
> One example I gave were references to array elements. In Python you
> write:
--> "In Python you have to write:"
>
> elem = seq[i]
> seq[i] = new_elem
>
> Where seq is a sequence type, i. e. a list, a tuple, a string or a
> dictionary. In CL you have to write:
--> "In CL you write:"
>
> (let ((elem (elt seq i)))
> ...)
> (setf (elt seq i) new-elem)
>
> I'm sure there are other examples.
But let's not discuss why I like A and you like B.
>
> > Wild guess: Some people don't like prefix notation perhaps
> > because they want to read the code aloud? It's not speech
> > oriented.
>
> I don't know what you mean.
I thought that some might read ((1 * 2) + (3 / 4)) as "1 times 2
plus 3 divided by 4". Suppose human kind never invented writing
system and communcated only verbally, then syntax of computer
languages would be quite different.... bah. never mind. I only
have very vague idea
Wolfram Fenske wrote:
> I think there are some cases where more syntax would be nice in
> Lisp. [...] If I were to design a new programming language
> without such a powerful macro system (not that I want that), I'd
> probably not choose S-expressions because I think other
> representations would be more suitable.
>
> One example I gave were references to array elements. In Python you
> write:
>
> elem = seq[i]
> seq[i] = new_elem
>
> Where seq is a sequence type, i. e. a list, a tuple, a string or a
> dictionary. In CL you have to write:
>
> (let ((elem (elt seq i)))
> ...)
> (setf (elt seq i) new-elem)
In newLISP:
> (set 'seq '(2 4 6 8))
(2 4 6 8)
> (set 'elem (seq -1))
8
> (nth-set (seq -1) 9)
8
> seq
(2 4 6 9)
"William James" <·········@yahoo.com> writes:
> Wolfram Fenske wrote:
>
>> I think there are some cases where more syntax would be nice in
>> Lisp. [...] If I were to design a new programming language
>> without such a powerful macro system (not that I want that), I'd
>> probably not choose S-expressions because I think other
>> representations would be more suitable.
>>
>> One example I gave were references to array elements. In Python you
>> write:
>>
>> elem = seq[i]
>> seq[i] = new_elem
>>
>> Where seq is a sequence type, i. e. a list, a tuple, a string or a
>> dictionary. In CL you have to write:
>>
>> (let ((elem (elt seq i)))
>> ...)
>> (setf (elt seq i) new-elem)
>
> In newLISP:
>
>> (set 'seq '(2 4 6 8))
> (2 4 6 8)
>> (set 'elem (seq -1))
> 8
>> (nth-set (seq -1) 9)
> 8
>> seq
> (2 4 6 9)
This seems to be one of the ideas that Paul Graham had for Arc [1]:
Any compound data object (meaning one with several separately
addressable parts) behaves like a function on indices. So for
example to get the third element of a list you "call" the list
with 2 as an argument.
[...]
CL: (aref a 5)
C: a[5]
Arc: (a 5)
It's nice that newLISP has this. (BTW, I also like the wrapping of
negative indices.) Since I find myself accessing array/list elements
a lot, I think having a more compact notation for it is big benefit.
I'm not sure I like the fact that this looks exactly like a function
call, though. I guess I would have to play around with it a bit to
see how confusing that is. Maybe [seq idx] would be better.
Wolfram
Footnotes:
[1] <http://www.paulgraham.com/arcll1.html>
Takehiko Abe wrote:
> > ii) I tend to think in terms of binary operations and then something as
> >
> >
> > (* 1 2 3)
> >
> > looks "non-mathematical". I would prefer
> >
> > (* * 1 2 3)
>
> Ah. I guess Lisp is not for you then.
>
> I think that either you like it or you hate it on the first
> sight. Do not try too hard. It's futile.
Sorry was a typo
(* (* 1 2) 3)
is so LISP as
(* 1 2 3)
My point is that
1 * 2 * 3
is not defined in mathematics.
Somewhat as (5 + 23) is but (5 + 23 + 7) is not and i begin to suspect
(but cannot still prove it 100%) the operation a + b + c is NOT defined
in nature.
Nature talks binary operations. In fact when a chemist write
(A => P)
or
(A + B + C => P)
knows that is not fundamental, just a notational convenience for the
real process.
Juan R.
Center for CANONICAL |SCIENCE)
"Juan R." <··············@canonicalscience.com> writes:
> My point is that
>
> 1 * 2 * 3
>
> is not defined in mathematics.
>
> Somewhat as (5 + 23) is but (5 + 23 + 7) is not and i begin to suspect
> (but cannot still prove it 100%) the operation a + b + c is NOT defined
> in nature.
Well 5+23+7 is perfectly defined in maths.
First, we've proved that + is commutative and associative,
so we know that you can group any two arguments and sum and recurse.
But we're even taught in primary school an algorithm to compute the sum directly!
12314
121351
2425
+ 82312
--------
When you compute this sum, you don't compute it using explicitely the
associativity: you compute it holistically, as a single n-operand
operation.
In the case of multiplication, we don't, but we could most certainly
develop an algorithm to compute directly the product of more than two
operands at once.
Let's start in base 4.
(let ((base 4))
(loop
:for i :from 0 :below base
:do (loop
:initially (loop
:for k :from 0 :below base
:initially (format t "~2%~2D*|" i)
:do (format t "~3D|" k))
:for j :from 0 :below base
:do (loop
:initially (format t "~%~3D|" j)
:for k :from 0 :below base
:do (format t "~3D|" (* i j k))))))
Learn your ternary * tables:
0*| 0| 1| 2| 3|
0| 0| 0| 0| 0|
1| 0| 0| 0| 0|
2| 0| 0| 0| 0|
3| 0| 0| 0| 0|
1*| 0| 1| 2| 3|
0| 0| 0| 0| 0|
1| 0| 1| 2| 3|
2| 0| 2| 4| 6|
3| 0| 3| 6| 9|
2*| 0| 1| 2| 3|
0| 0| 0| 0| 0|
1| 0| 2| 4| 6|
2| 0| 4| 8| 12|
3| 0| 6| 12| 18|
3*| 0| 1| 2| 3|
0| 0| 0| 0| 0|
1| 0| 3| 6| 9|
2| 0| 6| 12| 18|
3| 0| 9| 18| 27|
Now, proceed to multiply:
213
32
* 121
------
xxx
xxx (* 213 32 1)
yyy
yyy (* 213 32 2)
zzz
+ zzz (* 213 32 1)
----------
ssssss
and run you n-ary sum algorithm.
Now, you can even prove that this ternary multiplication is well
behaved with respect to the binary one (thanks to the associativity of
the binary product), an be happy.
--
__Pascal Bourguignon__ http://www.informatimago.com/
READ THIS BEFORE OPENING PACKAGE: According to certain suggested
versions of the Grand Unified Theory, the primary particles
constituting this product may decay to nothingness within the next
four hundred million years.
Pascal Bourguignon wrote:
> "Juan R." <··············@canonicalscience.com> writes:
> > My point is that
> >
> > 1 * 2 * 3
> >
> > is not defined in mathematics.
> >
> > Somewhat as (5 + 23) is but (5 + 23 + 7) is not and i begin to suspect
> > (but cannot still prove it 100%) the operation a + b + c is NOT defined
> > in nature.
>
> Well 5+23+7 is perfectly defined in maths.
I mean at fundamental level.
(5 + 23 + 7) is a notation for, usual, ((5 + 23) + 7).
> First, we've proved that + is commutative and associative,
> so we know that you can group any two arguments and sum and recurse.
> But we're even taught in primary school an algorithm to compute the sum directly!
>
> 12314
> 121351
> 2425
> + 82312
> --------
>
> When you compute this sum, you don't compute it using explicitely the
> associativity: you compute it holistically, as a single n-operand
> operation.
4+1=5
5+5=10
10+2=12
then
--------
2
next i continue
5+1=6
6+2=8
8+1=9
9+1=10
then
--------
12
and so on.
Moreover (a +b + c) appears to be not defined in nature. Apparently
nature likes binary and infix.
But whereas this discussion was interesting, main topic was about
advantages of LISP syntax.
I said that LISP uses infix as basis for SEXPR (x.y) now i think that
even uses infix is used in composition of atoms of language. The token
plus is p-l-u-s with "-" the hidden binding infix operator. Somewhat as
in chemistry A + B = A-B = AB
Juan R.
Center for CANONICAL |SCIENCE)
"Juan R." <··············@canonicalscience.com> writes:
> Pascal Bourguignon wrote:
>> First, we've proved that + is commutative and associative,
>> so we know that you can group any two arguments and sum and recurse.
>> But we're even taught in primary school an algorithm to compute the
>> sum directly!
>>
>> 12314
>> 121351
>> 2425
>> + 82312
>> --------
>>
>> When you compute this sum, you don't compute it using explicitely the
>> associativity: you compute it holistically, as a single n-operand
>> operation.
>
> 4+1=5
> 5+5=10
> 10+2=12
No. This is not how I sum columns of digits. I watch them, and
somewhat group them ten by ten. So at one glance, I've got 10 and 2.
And for the second column, without doing any addition, I get 10 and 0,
etc. You can train any neural network to do the same.
Binary operations are nice for binary computers because of the economy
of means it allows. But nature likes to be generous and redundant,
providing us with (European) billions of neurons, and trillions of
connections, allowing animals execute non-binary operations easily.
> Moreover (a +b + c) appears to be not defined in nature. Apparently
> nature likes binary and infix.
Nature summing three quantities at once:
|~~~~~| |~~~~~| |~~~~~|
| | | | | |
+-+ +-+ +-+ +-+ +-+ +-+
| | | | | |
| +-----------+ | | +-----------+ |
+-----------+ | | | | +-----------+
| | | | | |
| | | | | | | |
| |
| |
+-------------------+
--
__Pascal Bourguignon__ http://www.informatimago.com/
Small brave carnivores
Kill pine cones and mosquitoes
Fear vacuum cleaner
Pascal Bourguignon wrote:
> Binary operations are nice for binary computers because of the economy
> of means it allows. But nature likes to be generous and redundant,
> providing us with (European) billions of neurons, and trillions of
> connections, allowing animals execute non-binary operations easily.
A little googling on Juan post history shows that he is another 'Xah
Lee" -- either a troll or a nut job (you decide). I guess one might
enjoy participating in a discussion despite the fact that it was
started by a troll...
--fj
funkyj wrote:
> Pascal Bourguignon wrote:
>
> > Binary operations are nice for binary computers because of the economy
> > of means it allows. But nature likes to be generous and redundant,
> > providing us with (European) billions of neurons, and trillions of
> > connections, allowing animals execute non-binary operations easily.
>
> A little googling on Juan post history shows that he is another 'Xah
> Lee" -- either a troll or a nut job (you decide). I guess one might
> enjoy participating in a discussion despite the fact that it was
> started by a troll...
Only cobards insult people using nick.
+ "funkyj" <······@gmail.com>:
| A little googling on Juan post history shows that he is another 'Xah
| Lee" -- either a troll or a nut job (you decide). I guess one might
| enjoy participating in a discussion despite the fact that it was
| started by a troll...
Ah. Thanks for pointing that out. I don't know what's wrong with my
troll detector these days.
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- It is undesirable to believe a proposition
when there is no ground whatsoever for supposing it is true.
-- Bertrand Russell
Harald Hanche-Olsen wrote:
> + "funkyj" <······@gmail.com>:
>
> | A little googling on Juan post history shows that he is another 'Xah
> | Lee" -- either a troll or a nut job (you decide). I guess one might
> | enjoy participating in a discussion despite the fact that it was
> | started by a troll...
>
> Ah. Thanks for pointing that out. I don't know what's wrong with my
> troll detector these days.
Thanks!
Was not this an educated debate?
> --
> * Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
> - It is undesirable to believe a proposition
> when there is no ground whatsoever for supposing it is true.
> -- Bertrand Russell
Pascal Bourguignon wrote:
> "Juan R." <··············@canonicalscience.com> writes:
>
> > Pascal Bourguignon wrote:
> >> First, we've proved that + is commutative and associative,
> >> so we know that you can group any two arguments and sum and recurse.
> >> But we're even taught in primary school an algorithm to compute the
> >> sum directly!
> >>
> >> 12314
> >> 121351
> >> 2425
> >> + 82312
> >> --------
> >>
> >> When you compute this sum, you don't compute it using explicitely the
> >> associativity: you compute it holistically, as a single n-operand
> >> operation.
> >
> > 4+1=5
> > 5+5=10
> > 10+2=12
>
> No. This is not how I sum columns of digits. I watch them, and
> somewhat group them ten by ten. So at one glance, I've got 10 and 2.
> And for the second column, without doing any addition, I get 10 and 0,
> etc. You can train any neural network to do the same.
>
> Binary operations are nice for binary computers because of the economy
> of means it allows. But nature likes to be generous and redundant,
> providing us with (European) billions of neurons, and trillions of
> connections, allowing animals execute non-binary operations easily.
>
>
> > Moreover (a +b + c) appears to be not defined in nature. Apparently
> > nature likes binary and infix.
>
>
> Nature summing three quantities at once:
>
> |~~~~~| |~~~~~| |~~~~~|
> | | | | | |
> +-+ +-+ +-+ +-+ +-+ +-+
> | | | | | |
> | +-----------+ | | +-----------+ |
> +-----------+ | | | | +-----------+
> | | | | | |
> | | | | | | | |
> | |
> | |
> +-------------------+
>
Sorry but i cannot enter in a discussion of this kind. Nature works
with molecularity of 2. Unary and ternary processes are not real, just
net process for realistic binary process.
When a chemist writes A + B + C know that is not fundamental somewhat
as 2 + 5 + 7 mean (2 + 5) + 7 in maths.
The same when a chemist writes A => P. He means A + S => P + S
The same in particle physics, real processes are binary.
Juan R.
Center for CANONICAL |SCIENCE)
Juan R. wrote:
>
> Sorry but i cannot enter in a discussion of this kind. Nature works
> with molecularity of 2. Unary and ternary processes are not real, just
> net process for realistic binary process.
Nonsense. Look at a basic Feynman diagram:
\
\
*~~~~~
/
/
I see *three* lines.
Joe Marshall wrote:
> Juan R. wrote:
> >
> > Sorry but i cannot enter in a discussion of this kind. Nature works
> > with molecularity of 2. Unary and ternary processes are not real, just
> > net process for realistic binary process.
>
> Nonsense. Look at a basic Feynman diagram:
>
>
> \
> \
> *~~~~~
> /
> /
>
> I see *three* lines.
This is either the more astonishing misunderstanding or the most
intelligent joke about the Feynmann diagram never read.
Juan R.
Center for CANONICAL |SCIENCE)
Juan R. wrote:
> Joe Marshall wrote:
> > Juan R. wrote:
> > >
> > > Sorry but i cannot enter in a discussion of this kind. Nature works
> > > with molecularity of 2. Unary and ternary processes are not real, just
> > > net process for realistic binary process.
> >
> > Nonsense. Look at a basic Feynman diagram:
> >
> >
> > \
> > \
> > *~~~~~
> > /
> > /
> >
> > I see *three* lines.
>
>
> This is either the more astonishing misunderstanding or the most
> intelligent joke about the Feynmann diagram never read.
Assume I'm ignorant. You claim that nature works with an arity of 2,
yet I see three lines in that diagram. What am I not getting here?
Joe Marshall wrote:
> Juan R. wrote:
> > Joe Marshall wrote:
> > > Juan R. wrote:
> > > >
> > > > Sorry but i cannot enter in a discussion of this kind. Nature works
> > > > with molecularity of 2. Unary and ternary processes are not real, just
> > > > net process for realistic binary process.
> > >
> > > Nonsense. Look at a basic Feynman diagram:
> > >
> > >
> > > \
> > > \
> > > *~~~~~
> > > /
> > > /
> > >
> > > I see *three* lines.
> >
> >
> > This is either the more astonishing misunderstanding or the most
> > intelligent joke about the Feynmann diagram never read.
>
> Assume I'm ignorant.
> You claim that nature works with an arity of 2,
Nobody has measured a molecular process of arity 3 or 1. E.g. In
Lindemann mechanism an unimolecular process is modelled as binary.
There is a small number of termolecular processes. Still are modelled
as binary. E.g.
NO + Cl_2 + NO => 2 ClON
is modelled (Trautz) as
NO + Cl_2 -> Cl_2ON
Cl_2ON + NO -> 2ClNO
The real process (sequence of binaries) is perceived like a
termolecular process at macro scale, when is really a composition of
bimolecular processes.
My emphasis in 2-arity is purely a scientific requirement for CanonML,
anyone can use (+ a b c d e f g) in LISP, of course, i never claimed or
even suggested the contrary.
In CanonML you can write [A + B + C] but knowing that the real process
is a sequence of binary events, e.g. [[A + B] + C]. Look similarity
with Trautz mechanism.
> yet I see three lines in that diagram. What am I not getting here?
\
\
#--
/
/
2-arity (called bimolecular if "arguments" are molecules)
\ /
\ /
#
/ \
/ \
2-arity also even if you can see 4 lines. Number of lines does not
define n-arity of the process.
However, this is not important here in a LISP list. It would be more
important reply to next
Initially i wrote [a ::over b] where operator is tagged with ::
explicitely. That can be translated to TeX {a \over b} for printing and
to LISP (/ a b) for computation. There is not ambiguity because
contrary to LISP where operator may be sited in the head -see recent
discussion about ambiguity of (X Y Z) vs (X Y Z)- in CanonML the
operator is explicitely tagged and can be analized by parser.
Now, i think that i could construct a parser analizing the input [a
over b], without special notation for commands and i think that the
input would be not ambiguous.
What do you opine? Would i find ambiguities?
Juan R.
Center for CANONICAL |SCIENCE)
Juan R. wrote:
>
> Initially i wrote [a ::over b] where operator is tagged with ::
> explicitely. That can be translated to TeX {a \over b} for printing and
> to LISP (/ a b) for computation. There is not ambiguity because
> contrary to LISP where operator may be sited in the head -see recent
> discussion about ambiguity of (X Y Z) vs (X Y Z)- in CanonML the
> operator is explicitely tagged and can be analized by parser.
>
> Now, i think that i could construct a parser analizing the input [a
> over b], without special notation for commands and i think that the
> input would be not ambiguous.
>
> What do you opine? Would i find ambiguities?
Parsers can be written for all sorts input. The simplest would be to
accept raw binary input, and the most complex would probably be some
natural language parser. It is likely that your parser will be between
these and probably closer to the simpler end.
The more complex the language you want to parse, the more complex the
parser will be. The more complex the code, the more likely there will
be bugs and the more likely that parsing will be a significant
component of the system as a whole. Human beings can parse incredibly
complex languages, but not without years of practice and ambiguities
still occur. The more complex the language, the more effort it will
take for the human being to understand it and avoid any ambiguities.
There is, of course, an advantage to mimicking a language that is
likely to be familiar to the human reader (such as infix algebraic
notation). It seems empirically that this advantage may initially be
large, but that it makes little difference to experienced programmers.
(Many beginners find the parens confusing, but no infix parser for lisp
has ever caught on.)
In my experience (and in the experience of a lot of people in this
group), the minimal advantage of simple infix notation is completely
overwhelmed by the disadvantages of complex parsing. You can take our
advice, or not.
Joe Marshall wrote:
> Juan R. wrote:
> >
> > Initially i wrote [a ::over b] where operator is tagged with ::
> > explicitely. That can be translated to TeX {a \over b} for printing and
> > to LISP (/ a b) for computation. There is not ambiguity because
> > contrary to LISP where operator may be sited in the head -see recent
> > discussion about ambiguity of (X Y Z) vs (X Y Z)- in CanonML the
> > operator is explicitely tagged and can be analized by parser.
> >
> > Now, i think that i could construct a parser analizing the input [a
> > over b], without special notation for commands and i think that the
> > input would be not ambiguous.
> >
> > What do you opine? Would i find ambiguities?
>
> Parsers can be written for all sorts input. The simplest would be to
> accept raw binary input, and the most complex would probably be some
> natural language parser. It is likely that your parser will be between
> these and probably closer to the simpler end.
>
> The more complex the language you want to parse, the more complex the
> parser will be. The more complex the code, the more likely there will
> be bugs and the more likely that parsing will be a significant
> component of the system as a whole. Human beings can parse incredibly
> complex languages, but not without years of practice and ambiguities
> still occur. The more complex the language, the more effort it will
> take for the human being to understand it and avoid any ambiguities.
>
> There is, of course, an advantage to mimicking a language that is
> likely to be familiar to the human reader (such as infix algebraic
> notation). It seems empirically that this advantage may initially be
> large, but that it makes little difference to experienced programmers.
> (Many beginners find the parens confusing, but no infix parser for lisp
> has ever caught on.)
I buy everything of this.
> In my experience (and in the experience of a lot of people in this
> group), the minimal advantage of simple infix notation is completely
> overwhelmed by the disadvantages of complex parsing. You can take our
> advice, or not.
And i of course thanks the advice. The problem is that i am *not*
permitted to choice. How many full-prefix PL you find beyond
LISP-Scheme? 2-3? How many of the rest?
How many papers in chemistry, theoretical physics, biology, or
mathematics, do you know using prefix notation?
Juan R.
Center for CANONICAL |SCIENCE)
Take next TeX construct
{{\partial \rho \over \partial t} = L \rho}
i could write it like
(= (over ((partial) (rho)) ((partial) t)) (L (rho)))
in a S(cheme)XML like way. Initially, i suggested next way for CanonML
[[::partial ::rho ::over ::partial t] = L ::rho]
that is a pure copy of TeX-like code.
However, input sintaxes as ASCIIMath do not explicitely mark the
operators for easiness of users. And one could try something like
[[partial rho over partial t] = L rho]
In this specific case, there is not ambiguity possible and parser is
not only able to render the equation but could even transform it to
LISP code for simbolic evaluation.
As pointed here, a formulation without :: could be ambiguous for more
generic markup or code, unless using LISP head convention
(operator.arguments). The CanonML code is still shorter than the
LISP-like one (and much more simple than ultraverbose MathML or
OpenMath), but it contains a lot of "::".
Somewhat as some people invented the famous joke acronym "Lots of
Irritating Superfluous Parentheses". I suspect that maybe people would
invent a similar joke for lot of irritants double colons or any.
I recognize that this is a very difficult task (to try to offer the
best of XML, LISP, and TeX in a single approach) but has anyone some
idea about this? I have revised many approaches and either are no
popular (e.g. prefix notation) or are valid for a specific niche (e.g.
TeX for printing). I simply do not know how continuing beyond the ::
notation. Maybe it is a kind of limit for this approach.
Juan R.
Center for CANONICAL |SCIENCE)
Joe Marshall wrote:
> Juan R. wrote:
>> Joe Marshall wrote:
>>> Juan R. wrote:
>>>> Sorry but i cannot enter in a discussion of this kind. Nature works
>>>> with molecularity of 2. Unary and ternary processes are not real, just
>>>> net process for realistic binary process.
>>> Nonsense. Look at a basic Feynman diagram:
>>>
>>>
>>> \
>>> \
>>> *~~~~~
>>> /
>>> /
>>>
>>> I see *three* lines.
>>
>> This is either the more astonishing misunderstanding or the most
>> intelligent joke about the Feynmann diagram never read.
>
> Assume I'm ignorant. You claim that nature works with an arity of 2,
> yet I see three lines in that diagram. What am I not getting here?
I don't think there's anything you're not getting.
Indeed, my initial thought at the nature only uses binary operators
comment immediately made me think about 3 and 4 point vertexes in QFT.
Joe Marshall wrote:
> Juan R. wrote:
>
>>Joe Marshall wrote:
>>
>>>Juan R. wrote:
>>>
>>>>Sorry but i cannot enter in a discussion of this kind. Nature works
>>>>with molecularity of 2. Unary and ternary processes are not real, just
>>>>net process for realistic binary process.
>>>
>>>Nonsense. Look at a basic Feynman diagram:
>>>
>>>
>>> \
>>> \
>>> *~~~~~
>>> /
>>> /
>>>
>>>I see *three* lines.
>>
>>
>>This is either the more astonishing misunderstanding or the most
>>intelligent joke about the Feynmann diagram never read.
>
>
> Assume I'm ignorant. You claim that nature works with an arity of 2,
> yet I see three lines in that diagram. What am I not getting here?
>
Never mind that, I want to hear the joke. "Three lines walk into a
singularity..."?
k
--
Cells: http://common-lisp.net/project/cells/
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Ken Tilton wrote:
> Joe Marshall wrote:
> > Juan R. wrote:
> >
> >>Joe Marshall wrote:
> >>
> >>>Juan R. wrote:
> >>>
> >>>>Sorry but i cannot enter in a discussion of this kind. Nature works
> >>>>with molecularity of 2. Unary and ternary processes are not real, just
> >>>>net process for realistic binary process.
> >>>
> >>>Nonsense. Look at a basic Feynman diagram:
> >>>
> >>>
> >>> \
> >>> \
> >>> *~~~~~
> >>> /
> >>> /
> >>>
> >>>I see *three* lines.
> >>
> >>
> >>This is either the more astonishing misunderstanding or the most
> >>intelligent joke about the Feynmann diagram never read.
> >
> >
> > Assume I'm ignorant. You claim that nature works with an arity of 2,
> > yet I see three lines in that diagram. What am I not getting here?
> >
>
> Never mind that, I want to hear the joke. "Three lines walk into a
> singularity..."?
These two strings walk up to a bar. The first string walks in and
orders and the bartender throws him out and yells "I don't serve
strings in this bar. The other string ruffs himself up on the street
and curls up and orders. The bartender shouts, "Hey, didn't you hear
what I told your buddy?"
The string says "Yeah."
The bartender says, "aren't you a string?"
The string says, "No, I'm a frayed knot..."
Joe Marshall wrote:
> Ken Tilton wrote:
>
>>Joe Marshall wrote:
>>
>>>Juan R. wrote:
>>>
>>>
>>>>Joe Marshall wrote:
>>>>
>>>>
>>>>>Juan R. wrote:
>>>>>
>>>>>
>>>>>>Sorry but i cannot enter in a discussion of this kind. Nature works
>>>>>>with molecularity of 2. Unary and ternary processes are not real, just
>>>>>>net process for realistic binary process.
>>>>>
>>>>>Nonsense. Look at a basic Feynman diagram:
>>>>>
>>>>>
>>>>> \
>>>>> \
>>>>> *~~~~~
>>>>> /
>>>>> /
>>>>>
>>>>>I see *three* lines.
>>>>
>>>>
>>>>This is either the more astonishing misunderstanding or the most
>>>>intelligent joke about the Feynmann diagram never read.
>>>
>>>
>>>Assume I'm ignorant. You claim that nature works with an arity of 2,
>>>yet I see three lines in that diagram. What am I not getting here?
>>>
>>
>>Never mind that, I want to hear the joke. "Three lines walk into a
>>singularity..."?
>
>
> These two strings walk up to a bar. The first string walks in and
> orders and the bartender throws him out and yells "I don't serve
> strings in this bar. The other string ruffs himself up on the street
> and curls up and orders. The bartender shouts, "Hey, didn't you hear
> what I told your buddy?"
> The string says "Yeah."
> The bartender says, "aren't you a string?"
> The string says, "No, I'm a frayed knot..."
>
Now this thread is getting some wear.
kt
--
Cells: http://common-lisp.net/project/cells/
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Ken Tilton <·········@gmail.com> writes:
> Joe Marshall wrote:
> > These two strings walk up to a bar. The first string walks in and
> > orders and the bartender throws him out and yells "I don't serve
> > strings in this bar. The other string ruffs himself up on the street
> > and curls up and orders. The bartender shouts, "Hey, didn't you hear
> > what I told your buddy?"
> > The string says "Yeah."
> > The bartender says, "aren't you a string?"
> > The string says, "No, I'm a frayed knot..."
> >
>
> Now this thread is getting some wear.
Groan! I think I'll just twist in the wind.
--
Thomas A. Russ, USC/Information Sciences Institute
Joe Marshall <··········@gmail.com> wrote:
+---------------
| Ken Tilton wrote:
| > >>>Nonsense. Look at a basic Feynman diagram:
...
| > Never mind that, I want to hear the joke. "Three lines walk into a
| > singularity..."?
|
| These two strings walk up to a bar. The first string walks in and
| orders and the bartender throws him out and yells "I don't serve
| strings in this bar. The other string ruffs himself up on the street
| and curls up and orders. The bartender shouts, "Hey, didn't you hear
| what I told your buddy?"
| The string says "Yeah."
| The bartender says, "aren't you a string?"
| The string says, "No, I'm a frayed knot..."
+---------------
Ouch! That gives me a pain in the 'brane!
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Joe Marshall wrote:
> Juan R. wrote:
> > Sorry but i cannot enter in a discussion of this kind. Nature works
> > with molecularity of 2. Unary and ternary processes are not real, just
> > net process for realistic binary process.
>
> Nonsense. Look at a basic Feynman diagram:
>
>
> \
> \
> *~~~~~
> /
> /
>
> I see *three* lines.
This is well-known in philosophy. Bertrand Russell wrote:
"It is common to think of relations as though they always held between
two terms, but in fact this is not always the case. Some relations
demand three terms, some four, and so on. Take, for instance, the
relation 'between'. So long as only two terms come in, the relation
'between' is impossible: three terms are the smallest number that
render it possible. York is between London and Edinburgh; but if London
and Edinburgh were the only places in the world, there could be nothing
which was between one place and another. Similarly jealousy requires
three people: there can be no such relation that does not involve three
at least. Such a proposition as 'A wishes B to promote C's marriage
with D' involves a relation of four terms; that is to say, A and B and
C and D all come in, and the relation involved cannot be expressed
otherwise than in a form involving all four. Instances might be
multiplied indefinitely, but enough has been said to show that there
are relations which require more than two terms before they can occur.
"The relation involved in judging or believing must, if falsehood is to
be duly allowed for, be taken to be a relation between several terms,
not between two."
I guess modern arithmetic must be absurdly general to some whose
counting system is "one, two, many".
Tayssir
> This is well-known in philosophy. Bertrand Russell wrote:
>
It's available online:
"The Problems of Philosophy"
http://philosophy.hku.hk/think/phil/russell/12.php
http://philosophy.hku.hk/think/phil/russell/index.php
Joe Marshall wrote:
> I see *three* lines.
And note that with Feynman diagrams, you cannot just take two lines and
say "these are the input, and that one is the result." There's too much
symmetry to know what an operation is.
Is it (A + B) = C?
Or is it (C - B) = A?
Answer: Both!
--
Darren New / San Diego, CA, USA (PST)
Native Americans used every part
of the buffalo, including the wings.
Darren New <····@san.rr.com> writes:
> Joe Marshall wrote:
>> I see *three* lines.
>
> And note that with Feynman diagrams, you cannot just take two lines
> and say "these are the input, and that one is the result." There's too
> much symmetry to know what an operation is.
> Is it (A + B) = C?
> Or is it (C - B) = A?
> Answer: Both!
And not only two-both, but three-both:
(A+B)=C
(C-A)=B
(C-B)=A
--
__Pascal Bourguignon__ http://www.informatimago.com/
"Specifications are for the weak and timid!"
Juan R. wrote:
> Moreover (a +b + c) appears to be not defined in nature. Apparently
> nature likes binary and infix.
I point to the three-body problem, in which (a+b) and (b+c) and (a+c)
are all well-defined, but (a+b+c) is intractable.
--
Darren New / San Diego, CA, USA (PST)
Native Americans used every part
of the buffalo, including the wings.
Darren New wrote:
> Juan R. wrote:
> > Moreover (a +b + c) appears to be not defined in nature. Apparently
> > nature likes binary and infix.
>
> I point to the three-body problem, in which (a+b) and (b+c) and (a+c)
> are all well-defined, but (a+b+c) is intractable.
I may split macro from micro.
In macro, (a+b+c) is defined but is an approximation.
In micro (a+b+c) is not defined. In fact nobody has measured (a+b+c).
Apparently nature dislike ternary and unary processes and only binary
are fundamental. That is reason that formally i like
[a + b + c] rather than (+ a b c) because [a + b + c] is a notational
convenience for sequences of binary operations (exactly equal that in
chemistry or physics). Moreover there is topological reason for the +
was infix (quantum correlations).
This, of course, does not apply to LISP, but in my own approach i am
trying to mimic nature. Therefore, i understand advantages of LISP
notation for LISP users
> --
> Darren New / San Diego, CA, USA (PST)
> Native Americans used every part
> of the buffalo, including the wings.
Juan R.
Center for CANONICAL |SCIENCE)
+ Darren New <····@san.rr.com>:
| Juan R. wrote:
|> Moreover (a +b + c) appears to be not defined in nature. Apparently
|> nature likes binary and infix.
|
| I point to the three-body problem, in which (a+b) and (b+c) and
| (a+c) are all well-defined, but (a+b+c) is intractable.
Brilliant. So addition is non-associative, for some values of
"addition". News at eleven.
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- It is undesirable to believe a proposition
when there is no ground whatsoever for supposing it is true.
-- Bertrand Russell
Harald Hanche-Olsen wrote:
> + Darren New <····@san.rr.com>:
>
> | Juan R. wrote:
> |> Moreover (a +b + c) appears to be not defined in nature. Apparently
> |> nature likes binary and infix.
> |
> | I point to the three-body problem, in which (a+b) and (b+c) and
> | (a+c) are all well-defined, but (a+b+c) is intractable.
>
> Brilliant. So addition is non-associative, for some values of
> "addition". News at eleven.
I suspect that Darren New means that in mechanics (a+b+c) is not
mathematically defined due to Poincare resonances and may be treated as
sequence of binary events.
By mathematically i mean usual analysis and Hilbert space structure.
Morever addittion -as multiplication- is associative in function of
operands.
If a b and c are integers 2, 3 and 4 then
(2+3)+4 = 2+(3+4)
but if are elementary particle or atoms or molecules or living
organisms, then in general non-associativity is the rule.
Juan R.
Center for CANONICAL |SCIENCE)
Juan R. wrote:
> Harald Hanche-Olsen wrote:
>
>>+ Darren New <····@san.rr.com>:
>>
>>| Juan R. wrote:
>>|> Moreover (a +b + c) appears to be not defined in nature. Apparently
>>|> nature likes binary and infix.
>>|
>>| I point to the three-body problem, in which (a+b) and (b+c) and
>>| (a+c) are all well-defined, but (a+b+c) is intractable.
>>
>>Brilliant. So addition is non-associative, for some values of
>>"addition". News at eleven.
>
>
> I suspect that Darren New means that in mechanics (a+b+c) is not
> mathematically defined due to Poincare resonances and may be treated as
> sequence of binary events.
No. By what I said, I mean that you can calculate the result of gravity
applying between A and B, and between B and C, and between C and A,
pretty much indefinitely into the future. However, you cannot (so far)
calculate the result of gravity precisely between all three, without
doing it as a series of 2-body approximations.
I strongly suspect that "nature" doesn't calculate where planets and
moons end up by doing successive two-body approximations. That's
certainly not the current theory.
Hence, the statement that "nature likes binary" does not appear to be
true. It seems obvious to me that "nature likes infix" appears
nonsensical without clarification.
--
Darren New / San Diego, CA, USA (PST)
Native Americans used every part
of the buffalo, including the wings.
Darren New wrote:
> No. By what I said, I mean that you can calculate the result of gravity
> applying between A and B, and between B and C, and between C and A,
> pretty much indefinitely into the future. However, you cannot (so far)
> calculate the result of gravity precisely between all three, without
> doing it as a series of 2-body approximations.
>
> I strongly suspect that "nature" doesn't calculate where planets and
> moons end up by doing successive two-body approximations. That's
> certainly not the current theory.
Sure? Then write a paper on that but first try to understand i said,
after try to see the difference between fundamental processes and not
fundamental ones. You are there talking about classical gravity...
> Hence, the statement that "nature likes binary" does not appear to be
> true.
I find interesting that nobody has measured a true ternary process in
both nature or laboratory and reason that (a+b+c) ==> p is understood
as non-fundamental description of a real (fundamental) process via
sequence of binary events. E.g.
(a+b) --> h
(h+c) --> p
> It seems obvious to me that "nature likes infix" appears
> nonsensical without clarification.
Try to see why one writes (a+b) or (H--Cl) in physics or chemistry
instead (+ a b) or (-- H Cl). The reply is not historical one, because
notation in physics and chemistry has changed a lot of since origins.
Juan R.
Center for CANONICAL |SCIENCE)
Juan R. wrote:
> You are there talking about classical gravity...
No I'm not. You can't do it with relativity either. If you're talking
about quantum gravity, let me know when a chronon is detected. (And even
then, you'll find you have three inputs and three outputs.)
> Try to see why one writes (a+b) or (H--Cl) in physics or chemistry
Well, I don't know about (a+b), but I can see (H--Cl) as being "infix".
However, since it's not an operator, I'm not sure what the point is.
--
Darren New / San Diego, CA, USA (PST)
Native Americans used every part
of the buffalo, including the wings.
Darren New wrote:
> Juan R. wrote:
> > You are there talking about classical gravity...
>
> No I'm not.
Yes, you did!
> You can't do it with relativity either.
Again you are talking of classical physics. This is a common
misunderstanding between beginners; chaos (classical branch) and
relativity also belong to classical physics.
> If you're talking
> about quantum gravity, let me know when a chronon is detected. (And even
> then, you'll find you have three inputs and three outputs.)
About the three body problem, relationships between macro and
fundamental processes, and quantum gravity you appear very misguided.
Not the hypotetical chronon is a requirement for a quantum gravity
formulation (maybe you confound chronons with gravitons) not the last
claim about "three inputs and three outputs" has sense.
> > Try to see why one writes (a+b) or (H--Cl) in physics or chemistry
>
> Well, I don't know about (a+b), but I can see (H--Cl) as being "infix".
> However, since it's not an operator, I'm not sure what the point is.
Sorry but I have not time for this kind of discussion. HCl can be
written as H·Cl in a Boole-like algebra, with "·" being the
binding operator (a product in Boole).
Do not forget that we write today as H_2 was written as H^2 by
Berzelius several centuries ago and H^2 = H·H = 2H.
Juan R.
Center for CANONICAL |SCIENCE)
Juan R. wrote:
> About the three body problem, relationships between macro and
> fundamental processes, and quantum gravity you appear very misguided.
Plonk.
> Center for CANONICAL |SCIENCE)
Yes, I'm sure.
--
Darren New / San Diego, CA, USA (PST)
Native Americans used every part
of the buffalo, including the wings.
Juan R. <··············@canonicalscience.com> wrote:
+---------------
| Takehiko Abe wrote:
| > > (* 1 2 3)
| > > looks "non-mathematical". I would prefer
| > > (* * 1 2 3)
| >
| > Ah. I guess Lisp is not for you then.
|
| Sorry was a typo
|
| (* (* 1 2) 3)
+---------------
By the way, just so you know, (* * 1 2 3) *IS* a perfectly
legal Common Lisp form, if you ever really want to do that: ;-} ;-}
> (+ 2 3)
5
> (* * 1 2 3)
30
>
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
> Somewhat as (5 + 23) is but (5 + 23 + 7) is not and i begin to suspect
> (but cannot still prove it 100%) the operation a + b + c is NOT defined
> in nature.
'defined in nature'?? Sorry but that is a meaningless statement.
You'll never be able to prove it.
>
> Nature talks binary operations. In fact when a chemist write
Nature does not talk. It is people that talk (and define things).
Takehiko Abe wrote:
> > Somewhat as (5 + 23) is but (5 + 23 + 7) is not and i begin to suspect
> > (but cannot still prove it 100%) the operation a + b + c is NOT defined
> > in nature.
>
> 'defined in nature'?? Sorry but that is a meaningless statement.
> You'll never be able to prove it.
meaningless statement? I doubt.
> >
> > Nature talks binary operations. In fact when a chemist write
>
> Nature does not talk. It is people that talk (and define things).
Nature talks, scientists hear.
Juan R.
Center for CANONICAL |SCIENCE)
On 2006-06-23, Juan R. wrote:
> I read on
>
> [http://www.strout.net/python/pythonvslisp.html]
>
> that LISP syntax is superior to algebraic syntax.
Really? Where? He gives Python's syntax a 10 out of 10 (10 being the
best), and Lisp a 2, and generally argues that Python has a much more
readable and familiar-to-most-programmers syntax.
Aside: He later gives Python a 9 for expressiveness, and Lisp an 8.
This by itself tells me that he and I differ so strongly in how we
measure things that I can safely ignore most of his reasoning,
because we use different axioms. I would, in a similar way, ignore
any movie reviewer that panned "Tombstone" or "Fight Club" or "The
Incredibles", three movies that I really liked.
Other have given several reasons why they like the Lisp syntax, and
how it has several benefits, given Lispniks' propensity for writing
macros. In the context of Lisp, Lisp syntax is superior.
And that's the crux of it: context. You can't say "X is better than
Y" in any absolute sense, only "in such-and-such context, X has these
benefits and these pitfalls, whereas Y has these benefits and these
pitfalls, and for my usage, I prefer X over Y."
Empirically, people that program in Lisp a lot get used to the prefix
notation, and many grow to prefer it. This means exactly as much as
Pythonistas' love of indentation-based blocks.
> Whereas i see the point of advantages of something as
>
> (+ (* 1 2) (/ 3 4))
>
> over algebraic
>
> 1 * 2 + 3 / 4
>
> -specially when managing dozens of operators- i am unable to see
> realistic advantages over infix notation
>
> ((1 * 2) + (3 / 4))
>
> Any advice?
If you're programming in Lisp, use
(+ (* 1 2) (/ 3 4))
If you're programming in some other language, use that language's
syntax.
-- Larry
Larry Clapp wrote:
> On 2006-06-23, Juan R. wrote:
> > I read on
> >
> > [http://www.strout.net/python/pythonvslisp.html]
> >
> > that LISP syntax is superior to algebraic syntax.
>
> Really? Where? He gives Python's syntax a 10 out of 10 (10 being the
> best), and Lisp a 2, and generally argues that Python has a much more
> readable and familiar-to-most-programmers syntax.
>From the source
<blockquote>
One could argue that LISP syntax, despite being unconventional and
therefore difficult for beginners to learn and use, is somehow superior
to algebraic syntax. (Indeed, LISP programmers often argue exactly
this.) Or one could argue that syntax does not matter much, and reduce
the weight of that factor, closing the distance between LISP and Python
somewhat.
</blockquote>
> Aside: He later gives Python a 9 for expressiveness, and Lisp an 8.
> This by itself tells me that he and I differ so strongly in how we
> measure things that I can safely ignore most of his reasoning,
> because we use different axioms. I would, in a similar way, ignore
> any movie reviewer that panned "Tombstone" or "Fight Club" or "The
> Incredibles", three movies that I really liked.
I do not asked for subjective poits, just for formal advantages of LISP
syntax and i received some information in this list.
> Other have given several reasons why they like the Lisp syntax, and
> how it has several benefits, given Lispniks' propensity for writing
> macros. In the context of Lisp, Lisp syntax is superior.
I am not arguing if is superior or not in a global sense, not entering
a Python/LISP debate not nothing of that. Simply hearding arguments on
LISP syntax, concretely about advantages.
> Empirically, people that program in Lisp a lot get used to the prefix
> notation, and many grow to prefer it. This means exactly as much as
> Pythonistas' love of indentation-based blocks.
Yes, but i am not interested in like/dislike, but in formal properties.
> If you're programming in Lisp, use
>
> (+ (* 1 2) (/ 3 4))
>
> If you're programming in some other language, use that language's
> syntax.
And if I am developing a language for datuments? I already explained my
position here
Juan R.
Center for CANONICAL |SCIENCE)
You may have missed one of the best features of lisp!
It's perfect for the web.
Seen XML lately. Now imagine a language designated for manipulating
DOM trees. LISP?
Yes Lisp.
Optimized for this very task over 30 years.
Arguably the fastest web language around.
Take a modern language like Allegro Lisp an Allegro Cashe
and Allegro Graph and it smokes the competition.
John
John Thingstad wrote:
> You may have missed one of the best features of lisp!
> It's perfect for the web.
> Seen XML lately. Now imagine a language designated for manipulating
> DOM trees. LISP?
> Yes Lisp.
> Optimized for this very task over 30 years.
> Arguably the fastest web language around.
> Take a modern language like Allegro Lisp an Allegro Cashe
> and Allegro Graph and it smokes the competition.
>
> John
In a recent thread in xml-dev, Prof. Murray asked for some advanced
validation and programing languages, officials w3c Schema and XSLT were
not good enough. I recommended him the usage of SXML in the list. You
can manipulate DOM trees via Scheme with innumerable advantages over
w3c technologies.
My own work is clearly based in S(cheme)XML.
Juan R.
Center for CANONICAL |SCIENCE)
Juan R. wrote:
> Hi,
>
> I read on
>
> [http://www.strout.net/python/pythonvslisp.html]
>
> that LISP syntax is superior to algebraic syntax. I have searched some
> formal information in this and find some thoughts in the CL FAQ
>
> [http://www.lispniks.com/faq/faq.html]
>
> Whereas i see the point of advantages of something as
>
> (+ (* 1 2) (/ 3 4))
>
> over algebraic
>
> 1 * 2 + 3 / 4
>
> -specially when managing dozens of operators- i am unable to see
> realistic advantages over infix notation
>
> ((1 * 2) + (3 / 4))
>
> Any advice?
>
> Juan R.
>
> Center for CANONICAL |SCIENCE)
>
Lisp has syntax now?
But I get what you're asking. Lisp's lack of a syntax let's it treat
all Lisp forms equally, evaluating them in the same way and using them
in the composition of a new form in the same way[1]. Examples:
A) (+ 1 2 (* 3 4) (apply #'/ '(5 6)) (apply #'(lambda (x y z) (- x y z))
'(7 8 9)))
And in Scheme (as well as other Lisps where the function form is
evaluated in the same way as other forms)...
B) ((lambda (p) (p (lambda (x y) x))) ((lambda (x y) (lambda (c) (c x
y))) 'x 'y))
which is equivalent to the non-obfuscated-with-lambdas Common Lisp code
"(car (cons 'x 'y))".
Now, since all forms are (nearly) equal, it becomes far easier for a
program to construct new forms itself. For example, quasiquoters for
substituting values into templates of code (returning the resulting code
forms) have been written as Lisp functions.
[1] - Common Lisp actually changes the whole "equality" bit to "equality
of all parameters, but not the function form itself." Scheme and other
Lisps, make all forms equal.
--
The science of economics is the cleverest proof of free will yet
constructed.
Juan R. wrote:
> Hi,
>
> I read on
>
> [http://www.strout.net/python/pythonvslisp.html]
>
> that LISP syntax is superior to algebraic syntax. I have searched some
> formal information in this and find some thoughts in the CL FAQ
>
> [http://www.lispniks.com/faq/faq.html]
>
> Whereas i see the point of advantages of something as
>
> (+ (* 1 2) (/ 3 4))
>
> over algebraic
>
> 1 * 2 + 3 / 4
>
> -specially when managing dozens of operators- i am unable to see
> realistic advantages over infix notation
>
> ((1 * 2) + (3 / 4))
>
> Any advice?
>
> Juan R.
>
> Center for CANONICAL |SCIENCE)
After reading some interesting comments in this list i summarize my
current opinion:
1) I misunderstood original claim done in
[http://www.strout.net/python/pythonvslisp.html]
that
<blockquote>
One could argue that LISP syntax, despite being unconventional and
therefore difficult for beginners to learn and use, is somehow superior
to algebraic syntax. (Indeed, LISP programmers often argue exactly
this.)
</blockquote>
The quote is ambiguous and i thought that LISPers were claiming that
LISP syntax is superior to algebraic syntax when i think they really
mean that
LISP syntax is superior to algebraic syntax IN a LISP environment.
due to the relationship to the binary tree structure of data in LISP,
macros, edition capabilities and some others points here cited.
Thanks by correct me at this point.
2) The failure of infix or algebraic versions of LISP (e.g. MLISP) is
mainly traced to the strong link between LISP data model, processing
and the prefix notation.
3) Most of those advantages are lost in other systems outside of LISP,
therefore one can use an infix notation whereas obtaining other
advantages. In my own case of CanonML advantages are:
i) Human readability. I (and some others) think that readability of
infix notation is not due to historical or educative reasons. Chemical
notation changed a lot of since alchemy but some basic constructs as
a-b or a+b remain due to topological reasons not historical.
Somewhat as one writes (a b) instead ( ab) because topological reasons
asociated to space operator binding tokens instead historical ones.
Somewhat as any Spanish student learn math in Spansih notation (3,1416)
but after is able to change the chip and write (3.1416) when writing in
science or eginnering.
I did learn (1 + 2) but not changed to (+ 1 2) today because no clear
advantage (outside LISP).
I suspect that readability of infix notation is due to perception
rules, somewhat as web fonts are more readable than old fonts. But i
have not find studies on this.
ii) LISP advantages in nullary, binary, ternary, and n-ary operators
are minimal in a real world where mixed operations are more common
((a-b)*c), (y=(m+n)).
Moreover n-arity in several LISP dialects i know (e.g. UPCLISP) is
valid for + and * for instance but not for / or -.
(+ 1 2 3) or (* 1 2 3) is legal but (/ 4 3 2) is not. However, it
appears that CL implementations also let (/ 4 3 2).
I do not know if (= a b c) is legal in modern dialects or not. Who
knows?
iii) Binary infix operators fit well in a scientific model of nature.
One writes a+b instead + a b in physics or chemistry because
topological reasons. Using infix let me to unify the syntax of
programming language with scientific-formal models. H--Br is not
historical is topological!
iv) Ambiguities from (X Y Z) are solved when you mark the operator.
This is also done in TeX-LaTeX with the \.
v) Prefix and postfix are special cases of an infix parser
[preargument ::command postargument] => [a ::over b]
[{} ::command postargument] => [::cos 1]
[preargument ::command {}] =>
vi) Infix notation fits very well with RDF triples and natural language
[John ::likes Mary] => John likes Mary
(2 + 3) => 2 plus 3
(+ 2 3) cannot be read in natural way and superfluous "and" is add to
last token.
[http://blog.technomadic.org/index.php?p=25]
vii) Infix notation is used in LISP in space operators (a b), atoms
binding (atom), and dotted pairs (x.y). Moreover a LISP manual i read
define own LISP syntax in a infix way (similar to BNF). This suggest me
that all-prefix is not perfect.
Somewhat as a dotted pair is (x.y) i am using basic structure [x ::c
y].
Moreover the structure [x ::c y] fits very well in quantum mechanics
<x|c|y>
Therefore, whereas i like LISP over Fortran C or Java, and wait that
this language will continue to offering us good ideas in a future (i am
sure and i am following Arc and others projects) i prefer continue my
own way via infix notation.
Thanks by this amazing discussion, links provided, and related topics
and sorry by any inconvenience!
Juan R.
Center for CANONICAL |SCIENCE)
Le Sun, 25 Jun 2006 08:02:48 -0700, Juan R. a écrit :
> (+ 2 3) cannot be read in natural way and superfluous "and" is add to
> last token.
I agree with most of your post but not with this point. When I spell to
a student a mathematical operation, I usually use a prefix notation. I
rarely say "do 2 plus 3", instead I find it orally more natural to say
"add 2 and 3". And it's even more true when it applies to a higher
number of arguments. I'll say "add x, y and z" instead of "do x plus y
plus z", which is cumbersome. I'll even say "add all these numbers",
which is a concrete way of expressing the use of a prefix variadic
operator...
Subjectively,
Nowhere man
--
···········@levallois.eu.org
OpenPGP 0xD9D50D8A