Does somebody knows about some macro for putting math traditionally
you know : 2 + 3 / (5 * 7 ). instead of (/ (+ 2 3) (* 5 7))
I've tried to make something while reading On lisp but problems seems
taff one.
Pet
·······@ncsu.edu (Rob St. Amant) writes:
> ·················@gmail.com writes:
>
>> Does somebody knows about some macro for putting math traditionally
>> you know : 2 + 3 / (5 * 7 ). instead of (/ (+ 2 3) (* 5 7))
>> I've tried to make something while reading On lisp but problems seems
>> taff one.
>
> You can find a straightforward solution in Norvig's Paradigms of AI
> Programming (http://norvig.com/paip.html), in the chapter on STUDENT.
> Code is provided. Sample output:
>
> CL-USER> (print-equations ""
> '((= (+ 3 4) (* (- 5 (+ 2 x)) 7))
> (= (+ (* 3 x) y) 12)))
>
>
> (3 + 4) = ((5 - (2 + X)) * 7)
> ((3 * X) + Y) = 12
Ignore the above; I misread or ignored the subject line, thinking the
question was about translation in the opposite direction.
From: Edi Weitz
Subject: Re: Any macro for inserting math "normally"
Date:
Message-ID: <uvego3ud5.fsf@agharta.de>
On 26 Mar 2007 08:08:29 -0700, ·················@gmail.com wrote:
> Does somebody knows about some macro for putting math traditionally
> you know : 2 + 3 / (5 * 7 ). instead of (/ (+ 2 3) (* 5 7))
http://www.cl-user.net/asp/libs/infix
http://plaza.ufl.edu/lavigne/resources/infix/infix.lisp
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
On Mar 27, 12:19 am, Edi Weitz <········@agharta.de> wrote:
> http://plaza.ufl.edu/lavigne/resources/infix/infix.lisp
I happen to have written this bit of code. There are some issues:
1. There's a *BUG* with associativity. For instance, something like
this:
(nfx foo = bar -> x = 0)
will fail; the macro bollixes when you switch between left and right-
associative infix operators. In the above example, = is right-assoc,
but -> is left, which confuses nfx. I may need to re-think how I
parse the dang thing. Maybe after I finish ascending one character of
each role in NetHack (screw the DevTeam, they make an addictive game).
You may simply want to completely avoid using right-associative
operators, i.e. use setf, just so that you won't be bitten by this
unfixed infix bug.
2. No support for prefix and postfix syntaxes, but prefix syntax is
available free anyway:
(nfx foo = (- bar) * (1 + quux))
3. It uses C notation. So, instead of non-equality being /= as in
the rest of Lisp, it uses !=. x /= y is the same as x = x / y, as in
C. But then, you have the power to define your own set of infix
operators, by simply messing with the code, or using definfix.
Someone (Eric Lavigne?) has suggested to me using <- for assignment,
for example, and let = be the numeric = operator in Lisp. I agree.
It might even make it to the next release, which will be after I
finish ascending one of each role in NetHack.
Sincerely,
AmkG
On Apr 9, 2:08 pm, "Alan Manuel K. Gloria" <········@gmail.com> wrote:
> On Mar 27, 12:19 am, Edi Weitz <········@agharta.de> wrote:> http://plaza.ufl.edu/lavigne/resources/infix/infix.lisp
>
> I happen to have written this bit of code.
The latest version is at:
http://www.dwheeler.com/readable/index.html
The main thing I recall about this version is that it has a proper
copyright message, instead of the fuzzy, "I just put this up for fun,
have fun!" message on the previous version. I can't recall any other
changes.
> Someone (Eric Lavigne?) has suggested to me using <- for assignment,
Actually, it was David Wheeler. hehehe.
Sincerely,
AmkG
(message (Hello ··················@gmail.com)
(you :wrote :on '(26 Mar 2007 08:08:29 -0700))
(
P> Does somebody knows about some macro for putting math traditionally
P> you know : 2 + 3 / (5 * 7 ). instead of (/ (+ 2 3) (* 5 7))
you've made an error in your infix expression -- it's actually (+ 2 (/ 3 (*
5 7)))
are you sure you'd like to use more 'ambiquous' infix math notation with all
those operator priorities instead of straightforward lisp syntax? :)
)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"�� ���� ������� �����")
On Mar 26, 8:20 pm, "Alex Mizrahi" <········@users.sourceforge.net>
wrote:
> (message (Hello ··················@gmail.com)
> (you :wrote :on '(26 Mar 2007 08:08:29 -0700))
> (
>
> P> Does somebody knows about some macro for putting math traditionally
> P> you know : 2 + 3 / (5 * 7 ). instead of (/ (+ 2 3) (* 5 7))
>
> you've made an error in your infix expression -- it's actually (+ 2 (/ 3 (*
> 5 7)))
> are you sure you'd like to use more 'ambiquous' infix math notation with all
> those operator priorities instead of straightforward lisp syntax? :)
>
I have to, there's a lot of formulas and I prefer copy paste .
Learning Lisp afterwork isn't that easy as learning it fresh.
On Mar 27, 12:11 am, ·················@gmail.com wrote:
> I have to, there's a lot of formulas and I prefer copy paste .
How important is it to get the correct formulas?
I ask because copy-paste with infix won't work unless the source
is correct and both the source and destination use the same
precedence rules (or the source is fully parenthesized).
Human generated source is unlikely to be correct because humans
often make precedence errors. (Human readers often make the same
errors, so you don't find out that things are wrong until a computer
is involved.)
It's unlikely that the source and destination use the same
precedence rules because there is no general agreement beyond
multiplication and addition. (Yes, folks disagree about subtraction
and division - left vs right associative and all that, especially
in combination with addition and multiplication.)
On Mar 27, 4:57 pm, "Andy Freeman" <······@earthlink.net> wrote:
> I ask because copy-paste with infix won't work unless the source
> is correct and both the source and destination use the same
> precedence rules (or the source is fully parenthesized).
Copy and paste of prefix is not without problems, and copy of infix
and conversion to prefix can generate problem also.
> Human generated source is unlikely to be correct because humans
> often make precedence errors. (Human readers often make the same
> errors, so you don't find out that things are wrong until a computer
> is involved.)
>
> It's unlikely that the source and destination use the same
> precedence rules because there is no general agreement beyond
> multiplication and addition. (Yes, folks disagree about subtraction
> and division - left vs right associative and all that, especially
> in combination with addition and multiplication.)
Yes, different precedence rules can generate problems, because 2 + 3 *
5 can mean
(2 + 3) * 5
or (usual)
2 + (3 * 5)
but also prefix notation can offer problems.
(/ a b c) can be legal in some lisp dialects but illegal in others.
Juan R. wrote:
> On Mar 27, 4:57 pm, "Andy Freeman" <······@earthlink.net> wrote:
>
> > I ask because copy-paste with infix won't work unless the source
> > is correct and both the source and destination use the same
> > precedence rules (or the source is fully parenthesized).
>
> Copy and paste of prefix is not without problems
If you can't copy accurately, how will any syntax work?
> and copy of infix
> and conversion to prefix can generate problem also.
That conversion is where you figure out what the formula
is really supposed to be.
> (/ a b c) can be legal in some lisp dialects but illegal in others.
When it is, it will signal an error.
Most of us prefer signaled errors to silently wrong answers, which
is a common result from precedence mistakes.
Note that there's a difference between using the wrong function
and making a precedence error.
On Mar 26, 8:20 pm, "Alex Mizrahi" <········@users.sourceforge.net>
wrote:
> are you sure you'd like to use more 'ambiquous' infix math notation with all
> those operator priorities instead of straightforward lisp syntax? :)
If it is so straightforward like you claim, why do mathematicians
reject it masively?
On Mar 31, 5:12 am, "Juan R." <··············@canonicalscience.com>
wrote:
> On Mar 26, 8:20 pm, "Alex Mizrahi" <········@users.sourceforge.net>
> wrote:
>
> > are you sure you'd like to use more 'ambiquous' infix math notation with all
> > those operator priorities instead of straightforward lisp syntax? :)
>
> If it is so straightforward like you claim, why do mathematicians
> reject it masively?
Mathematicians write for other mathematicians. They don't have to get
it correct because readers make the same mistakes.
FWIW - Mathematicians belive that "argument from authority" is a
fallacy.
On Mar 31, 5:29 pm, "Andy Freeman" <······@earthlink.net> wrote:
> On Mar 31, 5:12 am, "Juan R." <··············@canonicalscience.com>
> wrote:
>
> > On Mar 26, 8:20 pm, "Alex Mizrahi" <········@users.sourceforge.net>
> > wrote:
>
> > > are you sure you'd like to use more 'ambiquous' infix math notation with all
> > > those operator priorities instead of straightforward lisp syntax? :)
>
> > If it is so straightforward like you claim, why do mathematicians
> > reject it masively?
>
> Mathematicians write for other mathematicians. They don't have to get
> it correct because readers make the same mistakes.
There are mathematicians writing for no-mathematicians: engineers,
physicists... mathematicians writing for computers...
But the important point is another. Language of math is optimised for
communication. Products are a shorthand for sums, I write [5 * 7]
instead the large [5 + 5 + 5 + 5 + 5 + 5 + 5].
Lisp syntax has been known for decades and its impact on mathematics,
science, and engineering is epsilon (when epsilon tends to zero). Hum,
that 'straightforward' character for lisp syntax may be a myth,
otherwise everyone would write (* 5 7) instead standard [5 * 7], no?
> FWIW - Mathematicians belive that "argument from authority" is a
> fallacy.
I am not sure to understand you completely, but if I did then reply is
not "argument from authority" but "pure statistics"; a 90-95% of
people do not use your "straightforward lisp syntax".
On Apr 6, 5:05 am, "Juan R." <··············@canonicalscience.com>
wrote:
> > > If it is so straightforward like you claim, why do mathematicians
> > > reject it masively?
>
> > Mathematicians write for other mathematicians. They don't have to get
> > it correct because readers make the same mistakes.
>
> There are mathematicians writing for no-mathematicians: engineers,
> physicists... mathematicians writing for computers...
In all but the latter case, it's as I wrote, math-trained humans
writing
for math-trained humans. They make and correct for the same mistakes.
When mathematicians write for computers, they make precedence errors.
If that's acceptable to you, feel free to use an input format that
uses
precedence. If it isn't acceptable, you can't rely on precedence.
> Language of math is optimised for communication.
I'm always amused by folks who think that communication is independent
of the sender and/or receiver.
> Lisp syntax has been known for decades and its impact on mathematics,
> science, and engineering is epsilon (when epsilon tends to zero).
None of those domains have to work with the wide variety of operators
that programmers deal with every day. (Note that even programming
languages with infix operators only use them for a small fraction of
the operations.)
And, programming isn't math.
If the results of your exercise don't have to be correct (perhaps
because
the reader will correct), feel free to use infix.
If you actually care about strict correctness, you're not going to get
it
from infix if you have more than two operators.
> I am not sure to understand you completely, but if I did then reply is
> not "argument from authority" but "pure statistics"; a 90-95% of
> people do not use your "straightforward lisp syntax".
I'm not discussing popularity, I'm discussing correctness.
I've never seen a mathmatical proof of the form "95% of people believe
X,
therefore X is true". Is that new math?
On Apr 7, 7:27 am, "Juan R." <··············@canonicalscience.com>
wrote:
> On Apr 6, 11:28 pm, "Andy Freeman" <······@earthlink.net> wrote:
>
> > On Apr 6, 5:05 am, "Juan R." <··············@canonicalscience.com>
> > wrote:
>
> > > > > If it is so straightforward like you claim, why do mathematicians
> > > > > reject it masively?
>
> > > > Mathematicians write for other mathematicians. They don't have to get
> > > > it correct because readers make the same mistakes.
>
> > > There are mathematicians writing for no-mathematicians: engineers,
> > > physicists... mathematicians writing for computers...
>
> > In all but the latter case, it's as I wrote, math-trained humans
> > writing
> > for math-trained humans. They make and correct for the same mistakes.
>
> Are LISPERs error-free?
>
> > When mathematicians write for computers, they make precedence errors.
>
> I know of mathematicians writting programs and they make no mistakes.
> In fact, i know of mathematicians who generated algorithms with no
> counterpart on LISP community.
>
> > If that's acceptable to you, feel free to use an input format that
> > uses
> > precedence. If it isn't acceptable, you can't rely on precedence.
>
> > > Language of math is optimised for communication.
>
> > I'm always amused by folks who think that communication is independent
> > of the sender and/or receiver.
>
> And who are those folks?
>
> > > Lisp syntax has been known for decades and its impact on mathematics,
> > > science, and engineering is epsilon (when epsilon tends to zero).
>
> > None of those domains have to work with the wide variety of operators
> > that programmers deal with every day. (Note that even programming
> > languages with infix operators only use them for a small fraction of
> > the operations.)
>
> Could you offer examples? A list? Number of operators used in each
> field?
>
> For the sake of comparison, of course.
>
> > And, programming isn't math.
>
> I though that fields like computational mathematics and similar had
> borrowed the distinction.
>
> > If the results of your exercise don't have to be correct (perhaps
> > because
> > the reader will correct), feel free to use infix.
>
> Apart from your arrogance anyone does not using LISP syntax is wrong,
> it appears you confound 'arithmetic' syntax with infix syntax, no?
>
> > If you actually care about strict correctness,
>
> I have worked on science, math, language, and computers and everyone
> care about 'strict correctness'.
>
> When a chemist publishes a new algorithm on _Computers and Chemistry_,
> the algorithm is correct (and computer understand!!!).
>
> When a physicist publishes a paper on _Physical Review_, the math is
> correct (and readers understand!!!).
>
> > you're not going to get
> > it
> > from infix if you have more than two operators.
>
> Sure i can.
>
> > > I am not sure to understand you completely, but if I did then reply is
> > > not "argument from authority" but "pure statistics"; a 90-95% of
> > > people do not use your "straightforward lisp syntax".
>
> > I'm not discussing popularity, I'm discussing correctness.
>
> > I've never seen a mathmatical proof of the form "95% of people believe
> > X,
> > therefore X is true". Is that new math?
>
> No, it is not new [*].
>
> [*]http://en.wikipedia.org/wiki/Degree_of_truth
Hi Juan,
I don't think that anybody questions the usefulness of infix notation
in general. It is certainly great for science and math, even though
most of the time the precise notation is not completely defined, but
context helps people cope with that. For example, if you check the
Comprehensive LaTeX Symbol List, you will see zillions of symbols,
most of them with multiple meanings in different fields, precedence
rules are certainly not defined for all of them etc. But that's OK:
most science and math papers provide the context where users can
figure it out. Only most. Recently I have seen a paper where the
author thought it would be clever to use ab/cd for (ab)/(cd), and it
took me quite a bit of frustration to figure out what he meant (it is
not usual for people to use this notation in economics). Or, in
probability theory, some people like to use the expectations operator
without parentheses, and the precedence is often unclear: is Efg=E(fg)
or fEg? People write the latter to avoid the ambiguity. but again,
with more complicated formulas it is not so obvious what to do. Some
measure theory books get into the "I'm gonna clean up the notation
once and for all" mindset, and a few even manage to do this
consistently _inside the book_ (where they only have to deal with a
subset of math) but cease to be applicable outside it.
When we program computers, it is up to the machine to interpret the
code so it can't figure out what the notation means by using context.
Of course it is perfectly possible to define unambiguous infix
notation, the trouble is, that with many symbols one has to remember
the rules are. Personally, when I program C, I just follow the advice
of Practical C Programming by Steve Oualline: remember that * binds
tighter than +, and use parentheses for everything else. And I really
hate it when people rely on precedence for anything else, because I
have to look it up, I just simply can't make myself memorize the
rules. The alternative is using a lot of parentheses, but then I
would prefer my parentheses to be intelligible at a glance. Lisp
helps with that (C-M-q rocks ;-).
Just my 2 cents,
Tamas
On Apr 7, 8:19 pm, "Tamas" <······@gmail.com> wrote:
> I don't think that anybody questions the usefulness of infix notation
> in general.
I do.
On Apr 7, 7:27 am, "Juan R." <··············@canonicalscience.com>
wrote:
> I know of mathematicians writting programs and they make no mistakes.
Now *that* is funny.
On Apr 8, 9:41 pm, "Joe Marshall" <··········@gmail.com> wrote:
> On Apr 7, 8:19 pm, "Tamas" <······@gmail.com> wrote:
>
> > I don't think that anybody questions the usefulness of infix notation
> > in general.
>
> I do.
A minority, no?
> On Apr 7, 7:27 am, "Juan R." <··············@canonicalscience.com>
> wrote:
>
> > I know of mathematicians writting programs and they make no mistakes.
>
> Now *that* is funny.
I did not mean they make none mistake. I did mean programs written by
those mathematicians are not wrong (they contain no mistakes) in the
sense of precedence rules and non lispy syntax of the poster by Andy
Freeman: "When mathematicians write for computers, they make
precedence errors".
I.e. I did mean "I know of mathematicians writing programs and they
make no precedence mistakes."
On Apr 14, 4:45 am, "Juan R." <··············@canonicalscience.com>
wrote:
> On Apr 8, 9:41 pm, "Joe Marshall" <··········@gmail.com> wrote:
>
> > On Apr 7, 8:19 pm, "Tamas" <······@gmail.com> wrote:
>
> > > I don't think that anybody questions the usefulness of infix notation
> > > in general.
>
> > I do.
>
> A minority, no?
No doubt, but now Tamas has a counterexample to his universal
quantification.
> > On Apr 7, 7:27 am, "Juan R." <··············@canonicalscience.com>
> > wrote:
>
> > > I know of mathematicians writting programs and they make no mistakes.
>
> > Now *that* is funny.
>
> I did not mean they make none mistake. I did mean programs written by
> those mathematicians are not wrong (they contain no mistakes) in the
> sense of precedence rules and non lispy syntax of the poster by Andy
> Freeman: "When mathematicians write for computers, they make
> precedence errors".
>
> I.e. I did mean "I know of mathematicians writing programs and they
> make no precedence mistakes."
I suppose that is possible, but I doubt it is true in general for
mathematicians.
On Apr 16, 9:36 pm, "Joe Marshall" <··········@gmail.com> wrote:
> > A minority, no?
>
> No doubt, but now Tamas has a counterexample to his universal
> quantification.
I agree that counterexamples are a good thing.
> > I.e. I did mean "I know of mathematicians writing programs and they
> > make no precedence mistakes."
>
> I suppose that is possible, but I doubt it is true in general for
> mathematicians.
Therefore, when I run a non-LISP program written by a mathematician I
would wait to got wrong replies, is that?
On Apr 16, 3:36 pm, "Joe Marshall" <··········@gmail.com> wrote:
> On Apr 14, 4:45 am, "Juan R." <··············@canonicalscience.com>
> wrote:
>
> > On Apr 8, 9:41 pm, "Joe Marshall" <··········@gmail.com> wrote:
>
> > > On Apr 7, 8:19 pm, "Tamas" <······@gmail.com> wrote:
>
> > > > I don't think that anybody questions the usefulness of infix notation
> > > > in general.
>
> > > I do.
>
> > A minority, no?
>
> No doubt, but now Tamas has a counterexample to his universal
> quantification.
What I meant was that nobody questions that there exist applications
for which infix notation is useful. Of course, there may be people
who question that. But I don't think this thing will be decided by a
vote, or that this needs to be decided once and for all. This is a
Lisp newsgroup, and Lisp uses prefix notation. This is not merely
some weird decision on syntax: core features of the language depend on
it.
Frankly, I can't see the point of this ongoing discussion. People who
like prefix have Lisp. So do people who would prefer infix but are
willing to put up with prefix because of the advantages Lisp offers.
People who hate prefix so much that they won't use Lisp have other
languages to choose from, or can try to invent a language as powerful
as Lisp with infix syntax (but I would be surprised to see that).
It is not clear to me what Juan is trying to accomplish.
Tamas
From: Kent M Pitman
Subject: Re: Any macro for inserting math "normally"
Date:
Message-ID: <uejmdv1rf.fsf@nhplace.com>
Tamas <······@gmail.com> writes:
> Frankly, I can't see the point of this ongoing discussion. People who
> like prefix have Lisp. So do people who would prefer infix but are
> willing to put up with prefix because of the advantages Lisp offers.
> People who hate prefix so much that they won't use Lisp have other
> languages to choose from, or can try to invent a language as powerful
> as Lisp with infix syntax (but I would be surprised to see that).
You're making and immediately mixing several assumptions.
First, people are not of one mind. People use one notation for one thing
and another for another. It's why LOOP and FORMAT have special languages
all their own. It's why regular expressions have a language of their own.
It's why filenames and URLs have a language of their own.
Second, people are not islands unto themselves never talking to others.
This is the age of mix and match, cut and paste, etc. People don't make
things from scratch--they share them. And one barrier to sharing is the
transformation of syntax. It's painful, and it introduces error. If
someone shares a formula with you, it's nice to keep it in the form they
gave you so (a) it's easier and less error-prone to drop in place,
and (b) it's easily validated by someone who's primary skill is math, since
it's in the language of math.
Third, you're failing to acknowledge that Lisp has neatly crafted a
separation between its surface reprsentation as text and its underlying
representation as s-expression that makes it ideally able to support both
notations with a minimum of impact on shared programs... very unlike other
languages which can talk about one another only by writing parsers because
they have no notion of what a parsed program tree would look like.
Fourth, not all people value (and devalue) the same things in Lisp.
Knowing someone likes Lisp is not a proof they like everything in it,
any more than you can say that electing George Bush was a claim that
everyone backed every one of his policies 100%. And so, not everyone
who likes Lisp likes it because of how it makes you write math.
Historically, btw, Interlisp, long ago, had infix math built in. I
think it used DWIM to figure out when you were doing it--I'm not sure
i was specially notated when you were doing it and when not.
Symbolics Lisp had it, too; but the characters it used were special
characters not in the ASCII set. Sharpsign Altmode (which looked kind
of like a diamond, and which appeared on the Symbolics keyboard as
Shift-Symbol-Escape) up to the next Altmode was parsed infix. MACLISP
had CGOL, written by Vaughan Pratt, which offered a full infix version
of the MACLISP language. It's a recurring theme, the wanting of infix
in Lisp. It's not for everyone. But it does not brand you an outsider
and is not something you're required to give up as part of the price
of inclusion.
Early Dylan, when it was still being defined at Apple, was probably
the best job of an infix Lisp, because it actually operated in dual
mode. (I think Dylan went rapidly downhill when it decided it could go
all the way in infix alone. The mindset that resulted from saying it
was ok, and even desirable, to sacrifice the Lisp community in the
hopes that it would endear them to the C++ crowd was not one that led
toward a good place.)
On Apr 21, 5:47 pm, Kent M Pitman <······@nhplace.com> wrote:
> Tamas <······@gmail.com> writes:
> > Frankly, I can't see the point of this ongoing discussion. People who
> > like prefix have Lisp. So do people who would prefer infix but are
> > willing to put up with prefix because of the advantages Lisp offers.
> > People who hate prefix so much that they won't use Lisp have other
> > languages to choose from, or can try to invent a language as powerful
> > as Lisp with infix syntax (but I would be surprised to see that).
>
> You're making and immediately mixing several assumptions.
Thanks for your answer, I didn't know these facts about the history of
Lisp. All of your points are valid, and I don't dispute that it is
worthwhile to experiment with languages. Maybe an infix syntax for
Lisp would be a good thing, maybe not, I don't have enough experience
to make predictions about this.
But I don't have to. If people really care about infix in Lisp, or
find a way to include it into the language that is not too disruptive
and the benefits outweigh the costs, they can do it and make the
results public. Then, if it is really a good thing, other people will
start using it and the thing will spread. This is really the easiest
way, and it seems much more productive than trying to convince people
using statistics, anecdotes, historical reasoning, arguments about
mathematicians and their (lack of) errors, etc.
Best,
Tamas
> First, people are not of one mind. People use one notation for one thing
> and another for another. It's why LOOP and FORMAT have special languages
> all their own. It's why regular expressions have a language of their own.
> It's why filenames and URLs have a language of their own.
>
> Second, people are not islands unto themselves never talking to others.
> This is the age of mix and match, cut and paste, etc. People don't make
> things from scratch--they share them. And one barrier to sharing is the
> transformation of syntax. It's painful, and it introduces error. If
> someone shares a formula with you, it's nice to keep it in the form they
> gave you so (a) it's easier and less error-prone to drop in place,
> and (b) it's easily validated by someone who's primary skill is math, since
> it's in the language of math.
>
> Third, you're failing to acknowledge that Lisp has neatly crafted a
> separation between its surface reprsentation as text and its underlying
> representation as s-expression that makes it ideally able to support both
> notations with a minimum of impact on shared programs... very unlike other
> languages which can talk about one another only by writing parsers because
> they have no notion of what a parsed program tree would look like.
>
> Fourth, not all people value (and devalue) the same things in Lisp.
> Knowing someone likes Lisp is not a proof they like everything in it,
> any more than you can say that electing George Bush was a claim that
> everyone backed every one of his policies 100%. And so, not everyone
> who likes Lisp likes it because of how it makes you write math.
>
> Historically, btw, Interlisp, long ago, had infix math built in. I
> think it used DWIM to figure out when you were doing it--I'm not sure
> i was specially notated when you were doing it and when not.
> Symbolics Lisp had it, too; but the characters it used were special
> characters not in the ASCII set. Sharpsign Altmode (which looked kind
> of like a diamond, and which appeared on the Symbolics keyboard as
> Shift-Symbol-Escape) up to the next Altmode was parsed infix. MACLISP
> had CGOL, written by Vaughan Pratt, which offered a full infix version
> of the MACLISP language. It's a recurring theme, the wanting of infix
> in Lisp. It's not for everyone. But it does not brand you an outsider
> and is not something you're required to give up as part of the price
> of inclusion.
>
> Early Dylan, when it was still being defined at Apple, was probably
> the best job of an infix Lisp, because it actually operated in dual
> mode. (I think Dylan went rapidly downhill when it decided it could go
> all the way in infix alone. The mindset that resulted from saying it
> was ok, and even desirable, to sacrifice the Lisp community in the
> hopes that it would endear them to the C++ crowd was not one that led
> toward a good place.)
From: Kent M Pitman
Subject: Re: Any macro for inserting math "normally"
Date:
Message-ID: <uabx13vsh.fsf@nhplace.com>
Tamas <······@gmail.com> writes:
> ... If people really care about infix in Lisp, or
> find a way to include it into the language that is not too disruptive
> and the benefits outweigh the costs, they can do it and make the
> results public. Then, if it is really a good thing, other people will
> start using it and the thing will spread. This is really the easiest
> way, and it seems much more productive than trying to convince people
> using statistics, anecdotes, historical reasoning, arguments about
> mathematicians and their (lack of) errors, etc. ...
Maybe this is what you were saying, I wasn't sure, so maybe we're in
agreement, but let me just add this in case it's needed:
Common Lisp is designed in such a way that the people who want this
can add it in modular fashion without the need for language design to
be involved at all. It's an ordinary user-level extension that is
non-invasive to other programs that are not interested in cooperating.
Lisp supports, to the extent possible, a pluralistic view of the way
things are done that tries not to make people have to agree in order
to cooperate. The joy of it all is that you can decide you don't like
it without having to force your dislike on others, while
simultaneously they can make and use such a feature without it being
forced on you. It is in that way unlike many other languages, which
would often make one programmer have to impose their will on another.
The reason I injected my remarks was because I perceived it had been
summed up that Lisp would support people who liked prefix or liked
infix but not so much they couldn't cope with prefix. But it's really
more flexible than that... It allows programmers to make their own
syntactic sandbox in many ways. That's all I meant to say.
In the extreme, I believe CGOL in MACLISP was implemented by calling a
function that made every single character be a readmacro that launched
the CGOL parser, and then parsing forward from there. In effect, this
means that no Lisp syntax showed through once that syntax was available
unless you exited CGOL. People mostly don't use readmacros that way.
But the important thing is that they are free to explore.
On Apr 21, 11:47 pm, Kent M Pitman <······@nhplace.com> wrote:
> It's a recurring theme, the wanting of infix
> in Lisp.
For instance, for the 'next' LISP (Arc), Graham want infix math, but
it looks like a macro approach.
Do you wait some future infix-LISP to success in a way prefix-LISP
could not during decades?
From: Kent M Pitman
Subject: Re: Any macro for inserting math "normally"
Date:
Message-ID: <uwszw8o6i.fsf@nhplace.com>
"Juan R." <··············@canonicalscience.com> writes:
> On Apr 21, 11:47 pm, Kent M Pitman <······@nhplace.com> wrote:
>
> > It's a recurring theme, the wanting of infix
> > in Lisp.
>
> For instance, for the 'next' LISP (Arc), Graham want infix math, but
> it looks like a macro approach.
>
> Do you wait some future infix-LISP to success in a way prefix-LISP
> could not during decades?
I'm not anxious for it personally. My reasons for why I like Lisp
syntax are both that it simplifies out the need to write gratuitous
parsers and, importantly and less seldom mentioned, it allows for a
simplified editing model that allows me to do from the keyboard in
Emacs things that are hard to do from either the keyboard or even the
mouse in other languages--lifting or reordering bounded fragments of
code reliably. There's a more detailed example of this in my Slashdot
interview in Part 1 of my Slashdot interview from a few years back at:
http://developers.slashdot.org/article.pl?sid=01/11/03/1726251
It's not personally desirable to me to change the availability of
infix syntax, but it's also not something where I think the two
are incompatible.
MACSYMA, a language for symbolic algebra, was basically an extension
of Lisp, and it had a parser that allowed you to code extensions in
either Lisp or Macsyma. Dylan had it, too. I think in both cases,
the correspondence was given up for political, not technical reasons.
I see no reason it couldn't be a hard requirement that both syntaxes
work. I see no reason it couldn't be that Lispy syntax would win if
some unexpected need to press on into other areas were come across.
I've seen it done well enough that I believe the contest is artificial.
Dylan had a similar choice to make, but it gave up Lispy syntax, as
far as I can tell, in a deliberate attempt to distance itself from
Lisp, not because a technical solution to keeping the two in sync was
attempted and utterly failed. Where there is a failure of will, it's
generally easy to find a failure of imagination.
So while I'm not anxious for an infix alternative, I would welcome it
only as a confirmation of my belief that the two could sit side by
side without injury.
I've been recently reading Ayn Rand's book The Fountainhead (a book I
strongly recommend, by the way, along with her Atlas Shrugged, which I
also found quite interesting). The Fountainhead makes many
interesting points, but one that it seems to repeat implicitly
throughout is how easy it is for people to just believe the
sometimes-ridiculous claims of others, based solely on the comfort of
numbers of people who have chosen to believe it, and really without
doing an independent analysis, based on fact, of what is, in fact,
possible or true. I mention the book because I think this particular
syntax issue is driven largely by pack mentality, with very little
attention to facts, just as happens for "architectural features" in
the book.
Summing up: Is infix desired by me? No. Is it by some? Yes. Has it
been tried? Yes. Is it something that is technicall workable? It has
seemed so. Have systems that used it survived? No. Was that the
reason of their demise? Probably not. Would it hurt to add it as an
option? I doubt it. Does it require help from the language
designers? Probably not.
What's holding it back, then? My guess: Lack of will on the part of
the people who want it, and frittering away their energy on
complaining to people who don't want it that it should be offered by
those who don't want it, rather than just implementing it themselves.
Some people would say that is, itself, an objective test of whether
people are really interested. True interest can often be measured by
someone putting resources on the line to make it happen. It's easy to
just _say_ "I'm interested", but when push comes to shove, many
statements of interest fall away.
In my opinion, people who think language syntax is what stands in the
way of them and commercial success are kidding themselves. If you're
not going to build something interesting, why does the syntax matter?
If you are going to build something interesting, why does the syntax
matter?
> Summing up: Is infix desired by me? No. Is it by some? Yes. Has it
> been tried? Yes. Is it something that is technicall workable? It has
> seemed so. Have systems that used it survived? No. Was that the
> reason of their demise? Probably not. Would it hurt to add it as an
> option? I doubt it. Does it require help from the language
> designers? Probably not.
Infix desired by me? Yes, in moderation. I like the illicit thrill
of screwing up other people's heads with (+ 3 4 (* 5 6)). But if I'm
prototyping something, sadly my brain is still formatted to write
infix for maths and I'll still use it. For production Lisp code
though, I'll take the trouble of transforming it all to prefix.
Is it by some? Yes, which is why I wrote my nfx macro.
Is it something that is technically workable? Yes, it's possible to
embed infix notation within the prefix Lisp language, and even do a
bit of DWIM to differentiate the two.
Have systems that used it survive? Yes. Cadence, which writes
Electronic Development Automation (EDA) tools, has developed a
Lisplike language called "Skill". It uses infix notation for maths.
Internally, a notation like 3 + 4 + 5 * 6 becomes transformed into
(plus 3 4 (times 5 6)) - symbols can't have punctuation in their
language. I say it's doing quite well, although Skill seems to be
moving more towards Scheme than CL.
Was that the reason of their demise? Probably not. Cadence Skill
survives, after all.
Would it hurt to add it as an option? No. You can embed entire
prefix-notation procedure inside my nfx macro, and (if nfx wasn't so
buggy, at least - it can't handle . notation, which I'll get around to
after I finish ascending one of each role in NetHack) >99% of the
procedures will work exactly the same. The remainder would probably
fail due to some wise guy using "+" or somesuch as a variable, which I
think isn't recommended.
Does it require help from the language designers? Yes, but only in
one form: MACRO. Macros are the ultimate (since they perform what
Church really *was* thinking when he described lambda-notation). One
of these days, when I'm less lazy (and lurk less on comp.lang.lisp),
I'm going to write an assembler with a *really*serious* macro system
and pass it off as a Lisplike.
>
> What's holding it back, then? My guess: Lack of will on the part of
> the people who want it, and frittering away their energy on
> complaining to people who don't want it that it should be offered by
> those who don't want it, rather than just implementing it themselves.
Hmm. I implemented it. It was even in the public domain, once, but
someone talked me into putting an MIT license on it.
>
> In my opinion, people who think language syntax is what stands in the
> way of them and commercial success are kidding themselves. If you're
> not going to build something interesting, why does the syntax matter?
> If you are going to build something interesting, why does the syntax
> matter?
Just as a though experiment:
(if (send-message you :build (add-property something
interesting) :scope :intention)
(why-does? (matter syntax)))
(declare :sarcasm nil) Hmm... I see your point here....
Alan Manuel K. Gloria wrote:
> Would it hurt to add it as an option? No. You can embed entire
> prefix-notation procedure inside my nfx macro, [...].
> Does it require help from the language designers? Yes, but only in
> one form: MACRO. [...]
>
> Kent Pitman wrote:
>> What's holding it back, then? My guess: Lack of will on the part of
>> the people who want it, and frittering away their energy on
>> complaining to people who don't want it that it should be offered by
>> those who don't want it, rather than just implementing it themselves.
>
> Hmm. I implemented it.
The thing that amazes me about this thread is that Edi Weitz, posting
the first reply <·············@agharta.de> to the OP way back on the
26th of March, mentioned *two* macros which implement infix notation in
Lisp, one of them Alan's nfx, and yet this thread is *still* going a
little over a month later. Sure, there have been some interesting posts
in it; for example, I just about always find something that I personally
interesting in Kent's posts. But if the issue of supporting infix
notation in lisp were a parrot, I think most of us already know what
kind of a parrot he'd be <http://preview.tinyurl.com/wwmj>. For the
love of sanity, how is it that this thread is still going?
From: Kent M Pitman
Subject: Re: Any macro for inserting math "normally"
Date:
Message-ID: <uy7k9o37n.fsf@nhplace.com>
Damien Kick <·····@earthlink.net> writes:
> how is it that this thread is still going?
So you're saying you oppose the idea?
;)
Damien Kick <·····@earthlink.net> writes:
> But if the issue of supporting infix notation in lisp were a parrot,
> I think most of us already know what kind of a parrot he'd be
> <http://preview.tinyurl.com/wwmj>. For the love of sanity, how is
> it that this thread is still going?
IMO, the discussion of infix vs. prefix more resembles the argument
sketch (which google, if you don't know it).
On Apr 28, 6:21 pm, Kent M Pitman <······@nhplace.com> wrote:
> I've been recently reading Ayn Rand's book The Fountainhead (a book I
> strongly recommend, by the way, along with her Atlas Shrugged, which I
> also found quite interesting). The Fountainhead makes many
> interesting points, but one that it seems to repeat implicitly
> throughout is how easy it is for people to just believe the
> sometimes-ridiculous claims of others, based solely on the comfort of
> numbers of people who have chosen to believe it, and really without
> doing an independent analysis, based on fact, of what is, in fact,
> possible or true. I mention the book because I think this particular
> syntax issue is driven largely by pack mentality, with very little
> attention to facts, just as happens for "architectural features" in
> the book.
I am not sure to understand you at this point, but it appears to me
that you refer to popularity of infix versus the prefix or postfix
approaches. Are you stating that unpopularity of prefix is merely
historical or a pure social issue?
What do you think about the widespread LISP community 'dogma' that
prefix notation is not more popular because familiarity issues?
> Summing up: Is infix desired by me? No. Is it by some? Yes.
"Some" means a 90% of programming world maybe?
> What's holding it back, then? My guess: Lack of will on the part of
> the people who want it, and frittering away their energy on
> complaining to people who don't want it that it should be offered by
> those who don't want it, rather than just implementing it themselves.
> Some people would say that is, itself, an objective test of whether
> people are really interested. True interest can often be measured by
> someone putting resources on the line to make it happen. It's easy to
> just _say_ "I'm interested", but when push comes to shove, many
> statements of interest fall away.
Others times I read people from LISP community stating "that is of no
real interest" for just some time after "that" acquiring a popularity
LISP never grasp.
> In my opinion, people who think language syntax is what stands in the
> way of them and commercial success are kidding themselves. If you're
> not going to build something interesting, why does the syntax matter?
> If you are going to build something interesting, why does the syntax
> matter?
If syntax does not matter, why M-expr failed?
If syntax does not matter, why early LISPERS invented the list syntax?
I.e. writing (A B C) instead more 'pure' (A.(B.(C.NIL))) ?
Syntax is an interface, and one of more important pieces in design.
Syntax can do your language to be more or less readable, more or less
concise, more or less extensible and, of course, more or less popular
and|or commercial.
The syntax of LISP was optimised for a kind of computational tasks.
Any attempt I know for applying that syntax to other kind of tasks,
different from original, have failed. As example, take any attempt to
use LISP in documentation issues. The families of TeX and SGML
languages clearly won there, because syntax matters.
From: Kent M Pitman
Subject: Re: Any macro for inserting math "normally"
Date:
Message-ID: <uk5vblwd1.fsf@nhplace.com>
"Juan R." <··············@canonicalscience.com> writes:
(This is in response to some of Juan's questions, but most of the uses
of "you" in here should be assumed to be the impersonal "you". I'm
speaking like I know the person I'm talking to and what "side" of the
argument they're on, etc. But I don't know that of him. These
questions and responses are posed generally, just using Juan's remarks
to focus my remarks a little. Also, I really wrote a much longer
essay on this but I didn't like it. So I cut out about 80% of what I
wrote, and this is the remainder. Hopefully it's still coherent even
after massive editing...)
> ... it appears to me that you refer to popularity of infix versus
> the prefix or postfix approaches. Are you stating that unpopularity
> of prefix is merely historical or a pure social issue?
First, I'm not really concerned with whether Lisp is popular. I'm
more concerned with whether it's good. If it's not good, it doesn't
matter how many users use it, it won't be better. If it is good, then
it serves those that choose to use it, however many that may be. But
I don't have a desire to perturb how others do their work. I'm happy
to talk to people seeking new ideas, but not to try to convince
someone that they should be.
Beyond that, algebraic/infix notation has as its key feature "brevity"
with all other needs (a priori intelligibility, visiblity of
grouping, etc.) heavily subordinated. I don't see it as so
obviously right that infix notation is best for all needs. Is it
handy? Sometimes.
But I'm saying that the issue is more like the issue of representing
complex numbers as polar rather than rectangular (or vice versa).
Counting up users does not tell you what you want to know. Sometimes
one is good, and sometime another is good, but trying to convince
people to always use one is questionable.
So maybe the only remaining issue is that of granularity. Do I want
to decide per-subexpression, per-expression, per file, per-package,
per-programmer, or per-language? That's a personal and/or social
issue, not a technical issue.
There's also a discussion paradigm issue in charge. The discussion is
really between a group of people who are happy with what they do and
are trying to just be left alone to do it and others who want what
those people have (Lisp) because they are not happy. If they were
happy, they would not be involving others in the discussion. (That's
one of the other points of Rand's The Fountainhead that I think is
probably right.) They perceive the only way they can get what they want
(a Lisp with infix) is to convince the people who don't want it to make
it for them, rather than to implement it themselves.
They must feel seriously disempowered, because this is an even
stronger and more sad statement than the usual "we need open source to
succeed" whining that one often sees on this newsgroup. What this
stronger statement says is "EVEN THOUGH I have open source, I still
cannot succeed without the help of others". It makes me wonder: if
the communities who want to do something like Lisp but not Lisp cannot
do it even when they have open source, why did they need the sources?
So maybe it's an issue of resource. But if that's so, how can they
argue that the reason that the lisp-notation people should help the
infix people is that the lisp-notation people are too small a
community and need the help of the outsiders. If that were so, it would
be the lisp-notation people who were pleading with the infixers for help.
But that isn't happening. The lisp-notation people like the lisp notation
in part because it empowers them not to need the resources of the others.
Summing up, the strategy seems to be for the large community to
convince the small community they are doing it wrong, so that the
large community will get the benefits that the small community has.
What's wrong with this picture?
If one believes they have The Right Paradigm, why doesn't one just run
with it? Why convince others? One of the big sadnesses of the modern
world that I hear when I talk to people about how it used to be
(including people of my own generation) is that it's so hard to find a
killer app any more... that it's hard to think up something that would
be a big hit. If you think you have a killer app idea, and that all
it involves is taking the Lispy syntax out of Lisp, go for it. Why
not? Why should anyone have to agree? Anyone who thinks this is right
and has the budget should just do it. But it seems weird to go find
someone who is a non-believer and try to convince them to do something
they perceive as risky, and to spend their own budget to do it...
What I have heard is for Lispers to say they took refuge in Lisp
because it's personally empowering to them. What I have heard is that
many of them have created special-purpose infix notations where they
think it's useful. What I have heard is that they acknowledge
benefits of infix, and use infix in other venues, they just mostly
don't want it in their Lisp. What I have seen is that they have
generously volunteered considerable time showing people who don't like
lisp-notation how to implement infix many different ways in a way that
is non-invasive. And yet, none of that (which wasn't required in the
firs place) is enough for the others.
But, ultimately, this discussion is not about live-and-let-live. It's
about all or nothing. So it goes in circles. Because people can only
be so accommodating. Asking them to simply give up what they themselves
prefer to use seems a bit much to do in the name of mere friendship and
community spirit.
> What do you think about the widespread LISP community 'dogma' that
> prefix notation is not more popular because familiarity issues?
I think there's some truth to it. In the communities where Lisp is
taught as normal, I've seen no pushback from users that it's unusable.
I suspect that if it were taught first, the ability to pretty-print,
to hop around easily while editing expressions, not to make precedence
errors, etc. would be seen as useful. So I don't think it's an
on-its-face silly claim. Whether it's _necessarily_ true, I don't
know or care. But it's worth observing that social issues are central
here. And that people waging the campaign do not acknowledge, as a
debate point, the many advantages of lisp syntax. They appear to me
to think their notation's virtues (which are primarily "conciseness")
go without saying and that all other considerations are secondary.
> If syntax does not matter, why M-expr failed?
I believe history suggests that this was exactly what I was talking
about earlier when I said that if a community isn't biased by others,
it might accept things. This may be the last true experiment on the
subject because it may no longer be possible to construct a world that
does not presuppose algebraic notation. But I think the community in
question honestly reviewed the goal and just decided it wasn't worth
doing because s-expressions were doing it better. Does that mean
another group would conclude the same? No. I'm not saying the result
is canonical. I'm just saying the result suggests there is some
validity to the notion that it's possible that, objectively, the
notations are at least just as good.
> If syntax does not matter, why early LISPERS invented the list syntax?
> I.e. writing (A B C) instead more 'pure' (A.(B.(C.NIL))) ?
(I started to write this post earlier and my machine crashed. I'm
recapping something I wrote before--I hope it was in this post and not
another. I don't mean to repeat myself.)
Because Lisp DID care about the issue of brevity, even if it dealt with
it in a different way. This contraction capability was aimed at keeping
Lisp from becoming needlessly verbose, but without losing the basic spirit
it had begun with. And, incidentally, the latter notation (except for the
fact that you usually need a space around the dots) tends to be carried
through in most modern Lisp dialects today.
Algebraic notation had going for it the notion that it was concise,
but it did it by overloading font and character position/placement and
other things to pack a lot of info into a small number of squiggles.
Lisp, by contrast, developed solutions to those same problems, but
along different lines, using technologies more appopriate to the
day--that is, to computers--rather than just to flat, static pages.
List-length abbreviation, level abbreviation, richer function and
macro abstraction than is provided in conventional math,
presentational control (pretty printers and other printer control
options), presentation abstraction (such as in LispM Dynamic Windows
and later CLIM), and so on. This community did not ignore the needs
that brevity sought; they just addressed it a different way. They
even created numerous technologies for allowing infix to play happily
without taking over and being the only way.
By contrast, the infix community just declared success and went home,
failing to address any of these other issues, even though they remained
issues.
On May 14, 9:04 am, Kent M Pitman <······@nhplace.com> wrote:
> "Juan R." <··············@canonicalscience.com> writes:
>
> (This is in response to some of Juan's questions, but most of the uses
> of "you" in here should be assumed to be the impersonal "you". I'm
> speaking like I know the person I'm talking to and what "side" of the
> argument they're on, etc. But I don't know that of him. These
> questions and responses are posed generally, just using Juan's remarks
> to focus my remarks a little. Also, I really wrote a much longer
> essay on this but I didn't like it. So I cut out about 80% of what I
> wrote, and this is the remainder. Hopefully it's still coherent even
> after massive editing...)
>
> > ... it appears to me that you refer to popularity of infix versus
> > the prefix or postfix approaches. Are you stating that unpopularity
> > of prefix is merely historical or a pure social issue?
>
> First, I'm not really concerned with whether Lisp is popular. I'm
> more concerned with whether it's good. If it's not good, it doesn't
> matter how many users use it, it won't be better. If it is good, then
> it serves those that choose to use it, however many that may be. But
> I don't have a desire to perturb how others do their work. I'm happy
> to talk to people seeking new ideas, but not to try to convince
> someone that they should be.
I agree on that popularity does not imply being good.
However, I also think that the concept of 'good' is relative. Maybe
LISP is not more popular because is not 'good' enough, using here a
definition for 'good' different from your own one.
This is something always surprised me. Some LISPERS appear to believe
that the only definition for 'good' is that they grasp. I like LISP
but I find irritant reading some guru that LISP is for "the good
programmers" and in no part the guru agree that maybe he is
considering "good programmers" are bad programmers from other's
perspective.
Once remarked that, let me remark again that my plea was not for
development of a 'popular' LISP by changing the definition of 'good'
but really by improving it.
> Beyond that, algebraic/infix notation has as its key feature "brevity"
> with all other needs (a priori intelligibility, visiblity of
> grouping, etc.) heavily subordinated. I don't see it as so
> obviously right that infix notation is best for all needs. Is it
> handy? Sometimes.
Well, I think I already remarked this several times, but I will do
again.
In no part I am stating that one would abandon the prefix syntax by an
infix one. I am clearly stating -again and again- that people would
_choose_ what syntax they prefer in basis to personal preferences and
class of problems they solve.
That is different from prefix LISP with traditional infix macro
cosmetics.
> So maybe it's an issue of resource. But if that's so, how can they
> argue that the reason that the lisp-notation people should help the
> infix people is that the lisp-notation people are too small a
> community and need the help of the outsiders. If that were so, it would
> be the lisp-notation people who were pleading with the infixers for help.
> But that isn't happening. The lisp-notation people like the lisp notation
> in part because it empowers them not to need the resources of the others.
Once remarked above you can use an all-prefix syntax if you want, I
would state now that I agree with Paul Graham (and others) when he
states that prefix does not work for large chunks of math. Graham
recognizes that after using prefix syntax during many decades he find
syntax odd for math and he (and others) want infix math for Arc (next
LISP).
Why am I perceiving (it is my impression) so one reluctance to
evolution in this newsgroup?
> Summing up, the strategy seems to be for the large community to
> convince the small community they are doing it wrong, so that the
> large community will get the benefits that the small community has.
> What's wrong with this picture?
It is much more simpler, instead splitting the world between prefix-
all-parenthesised people and infix-arithmetic people (roughly LISPERS
and the rest) I would be glad to unify both communities in a new
framework.
Maybe, it is a too idealized vision and some elitist part of the LISP
community will react fiercely to the idea. Maybe current LISP is used
as a barrier against possible contamination with the rest of the world
-some LISP guru called "the nerds"-. I do not know.
> If one believes they have The Right Paradigm, why doesn't one just run
> with it? Why convince others?
This is ironic. How many times we heard from LISP community that LISP
is The language? How many times LISPERS tried to convince the rest of
the world to switch to an all prefix full parenthesised syntax?
Are not many quotes in [http://lispers.org/] trying to convince
others?
> If you think you have a killer app idea, and that all
> it involves is taking the Lispy syntax out of Lisp, go for it.
I think that I explained several times is not that.
> Why should anyone have to agree? Anyone who thinks this is right
> and has the budget should just do it.
Again, apart from just using LISP, people at [http://lispers.org/]
want rest of people to agree with them.
I think that I cannot be criticized in that way.
> But it seems weird to go find
> someone who is a non-believer and try to convince them to do something
> they perceive as risky, and to spend their own budget to do it...
Could be someone could perceive a project of this kind as "risky"
because diffusing the barriers LISP-rest-of-the-world?
Could be someone could perceive a project of this kind as "risky"
because decades trying to convince the world that prefix LISP way was
the only one possible?
Could be someone could perceive a project of this kind as "risky"
because breaking certain pure LISP projects now in development?
I am rather realist and I am rather sure that a part of LISP community
(the 'core') will reject this kind of project. I also believe that
people at the boundary with C, Python, or Haskell will find it
interesting.
> What I have heard is for Lispers to say they took refuge in Lisp
> because it's personally empowering to them. What I have heard is that
> many of them have created special-purpose infix notations where they
> think it's useful. What I have heard is that they acknowledge
> benefits of infix, and use infix in other venues, they just mostly
> don't want it in their Lisp. What I have seen is that they have
> generously volunteered considerable time showing people who don't like
> lisp-notation how to implement infix many different ways in a way that
> is non-invasive. And yet, none of that (which wasn't required in the
> firs place) is enough for the others.
Maybe, but I see a very large history on the development of LISPs with
infix capabilities. Again I see that desire in next Arc also.
Two points:
[i] Some LISPers recognize an full infix capable LISP would be a great
thing.
[ii] That infix macros are not enough.
> > What do you think about the widespread LISP community 'dogma' that
> > prefix notation is not more popular because familiarity issues?
>
> I think there's some truth to it. In the communities where Lisp is
> taught as normal, I've seen no pushback from users that it's unusable.
> I suspect that if it were taught first, the ability to pretty-print,
> to hop around easily while editing expressions, not to make precedence
> errors, etc. would be seen as useful. So I don't think it's an
> on-its-face silly claim. Whether it's _necessarily_ true, I don't
> know or care. But it's worth observing that social issues are central
> here.
My perception of problem and conversation with mathematicians,
scientists, and programmers from other languages is that familiarity
is not the basis for rejection but limitations of the prefix notation.
We also see like natural languages are evolving outside of prefix
structures and in this same thread someone wrote about that also.
Paul Graham is one of few LISPER gurus who acknowledge _in public_
that the question of massive rejection of the all-prefix math notation
of LISP is not based in familiarity. His writing is clear and precise:
[BLOCKQUOTE
There are two possible problems with prefix notation:
that it is unfamiliar to programmers, and that it is not
dense enough. The conventional wisdom in the Lisp world
is that the first problem is the real one. I'm not so sure.
[...]
Sometimes infix syntax is easier to read. This is especially
true for math expressions. I've used Lisp my whole programming
life and I still don't find prefix math expressions natural.
]
> > If syntax does not matter, why early LISPERS invented the list syntax?
> > I.e. writing (A B C) instead more 'pure' (A.(B.(C.NIL))) ?
>
> Because Lisp DID care about the issue of brevity, even if it dealt with
> it in a different way. This contraction capability was aimed at keeping
> Lisp from becoming needlessly verbose, but without losing the basic spirit
> it had begun with. And, incidentally, the latter notation (except for the
> fact that you usually need a space around the dots) tends to be carried
> through in most modern Lisp dialects today.
First, I think that you are missing that brevity is not the only issue
which (A B C) is today preferred syntax. If brevity was the main
explanation, then it is likely that I would write something like (A B
C) and editor would automatically translate to pairs and the pairs
version of the program would be stored in disk.
But that is not happening. People write (A B C), store (A B C),
interchange (A B C) and read (A B C). Therefore, I think reason which
LISPers use list syntax is because brevity _and_ readability _and_
also disk size.
Therefore because the search for brevity, because readability, or
because some other motive syntax matters. And that was I stated before.
For the record:
On Sun, 03 Jun 2007 06:21:24 -0700, "Juan R." <··············@canonicalscience.com> said:
| ...
| In no part I am stating that one would abandon the prefix syntax by an
| infix one. I am clearly stating -again and again- that people would
| _choose_ what syntax they prefer in basis to personal preferences and
| class of problems they solve.
These would be the criteria for one who is working in isolation.
For one who has or wishes to collaborate with others, speaking the
relevant common language with its notation takes precedence.
(Here is a case study. Feynman tells the story how, in high school,
he invented new notation for some irrational operations (such as
roots and trigonometric functions), considering it superior to the
common one. He abandoned it rather soon not because he changed his
opinion on that, but because he realized that it was more important
to him that others can freely read what he wrote.)
But more importantly:
| ...
| Once remarked above you can use an all-prefix syntax if you want, I
| would state now that I agree with Paul Graham (and others) when he
| states that prefix does not work for large chunks of math. Graham
| recognizes that after using prefix syntax during many decades he find
| syntax odd for math and he (and others) want infix math for Arc (next
| LISP).
Characterizing mathematical notation only in terms of the
infix-prefix dichotomy is a vast oversimplification. Just as an
example, is the notation for integrals prefix or infix? For
definite integrals, I would say that it is "mostly prefix with a
touch of two-dimensional inficity", if I could rephrase that in a
sensible way; similarly for the big sigma notation for sums, and
others of a similar nature. (Then, even if we stayed on the
surface, there is also "suffix" notation of various kinds.)
Mathematical notation is heavily optimized for ease of manual input
(which includes conciseness) _while_ assuming a "random-access"
two-dimensional medium (such as pen and paper) allowing arbitrary
graphics; mathematical notation is not optimized for ease of
perception (which is one of the several reasons which make it hard
to train mathematicians) or of typesetting. Two things are worth
noting here:
(1) These assumptions and optimization criteria are not necessarily
the ones applicable to programming languages; in fact, they
would probably be bad choices if one would try to apply them to
the latter.
(2) The relatively recent advent of keyboards as input devices,
especially computer keyboards, with the accompanying bias
towards a one-dimensional representation based on a restricted
set of symbols, may bear a sufficiently strong influence on
mathematical notation so as to change it, but even if that
process has started, it is by no means clear what the end result
will be. (A priori, we can't exclude an increase in the share
of "preficity" in mathematical notation.)
Finally, I believe that invoking mathematics as an arbiter, as it
were, in the infix-prefix dispute, is counter-productive also
because---this is an opinion---mathematicians do not care about
infix or prefix per se, they care about expressiveness. The problem
they are solving is "produce, in writing, good abstractions out of
reality", not "decide whether infix or prefix is better".
---Vassil.
--
The truly good code is the obviously correct code.
On Jun 3, 6:19 pm, Vassil Nikolov <···············@pobox.com> wrote:
> For the record:
>
> On Sun, 03 Jun 2007 06:21:24 -0700, "Juan R." <··············@canonicalscience.com> said:
> | ...
> | In no part I am stating that one would abandon the prefix syntax by an
> | infix one. I am clearly stating -again and again- that people would
> | _choose_ what syntax they prefer in basis to personal preferences and
> | class of problems they solve.
>
> These would be the criteria for one who is working in isolation.
No really. Profiling polices, canonical machine-level representation
and conversors between syntax may guarantee communication.
> For one who has or wishes to collaborate with others, speaking the
> relevant common language with its notation takes precedence.
When I said that "people would _choose_ what syntax they prefer" I was
not stopping people from choosing some already available common
syntax.
The difference is that you can choose. Nothing impede you to work with
established conventions if you like, but you are not obligated. That
is a much, because conventions can be very hard to use in fields for
which the convention was not optimised.
In fact, I wait a truly ecology of syntaxes, with syntaxes competing
between them, and different groups generating different standards
rapidly winning over others. This is a more dynamical point of view
than usual one.
> But more importantly:
>
> | ...
> | Once remarked above you can use an all-prefix syntax if you want, I
> | would state now that I agree with Paul Graham (and others) when he
> | states that prefix does not work for large chunks of math. Graham
> | recognizes that after using prefix syntax during many decades he find
> | syntax odd for math and he (and others) want infix math for Arc (next
> | LISP).
>
> Characterizing mathematical notation only in terms of the
> infix-prefix dichotomy is a vast oversimplification.
Was not my intention. But this thread was mainly about prefix-infix
thing. Other site we could talk about rest.
> Just as an
> example, is the notation for integrals prefix or infix?
I do not know samples of infix notation for integrals. I know prefix
like in
Integral dx {x^2}
Or more usual like
Integral {x^2} dx
Maybe could be called contained notation or per-post-fix.
Once more, I am not saying that prefix people would change; I am
really saying is that a new 'LISP' were not limited to prefix syntax
would be more popular and, in my opinion, fine.
I see some LISPERs agree and I can see Graham and others taking infix
math more seriously than usual way during development of Arc language.
> For
> definite integrals, I would say that it is "mostly prefix with a
> touch of two-dimensional inficity", if I could rephrase that in a
> sensible way; similarly for the big sigma notation for sums, and
> others of a similar nature. (Then, even if we stayed on the
> surface, there is also "suffix" notation of various kinds.)
Note this argument says nothing about 99% of people (including
mathematicians) rejecting the LISP way (+ 2 6).
> Mathematical notation is heavily optimized for ease of manual input
> (which includes conciseness) _while_ assuming a "random-access"
> two-dimensional medium (such as pen and paper) allowing arbitrary
> graphics;
I do not think so. Most of current math research and typesetting is
done via computers. When mathematicians develop a new branch of maths,
which implies new notation, most of the work (if not the whole) is
done electronically.
> mathematical notation is not optimized for ease of
> perception (which is one of the several reasons which make it hard
> to train mathematicians) or of typesetting. Two things are worth
> noting here:
Probably mathematical notation is not optimised for perception. But
precisely one of criticism to LISP syntax is that its perception is
poor. That is, reason that mathematicians know notations like (+ 2 3)
but largely ignore it.
> (1) These assumptions and optimization criteria are not necessarily
> the ones applicable to programming languages; in fact, they
> would probably be bad choices if one would try to apply them to
> the latter.
I see several examples on the contrary including from people
participating in development of next LISP.
Murray Sargent (Unicode and W3C MathML) is promoting Unicode format
and a TeX-like language as representation for next generation of
programming languages.
He compares several examples of programs (in C++ if I remember
correctly) with relatively large chunks of math in traditional
programming style and in Unicode looking style.
He argues that the Unicode based programming language looks better and
I agree.
Also I read in some part of some new Fortran like language with full
formatting capabilities.
Again, people who want a more traditional approach can work with that.
Or said in other way you can write �-la-LISP [ALPHA LESS-THAN-OR-EQUAL
0] or a la Unicode [a � 0].
> (2) The relatively recent advent of keyboards as input devices,
> especially computer keyboards, with the accompanying bias
> towards a one-dimensional representation based on a restricted
> set of symbols, may bear a sufficiently strong influence on
> mathematical notation so as to change it, but even if that
> process has started, it is by no means clear what the end result
> will be. (A priori, we can't exclude an increase in the share
> of "preficity" in mathematical notation.)
The above UNICODE project including mathematically looking algorithms,
the exponential increase in usage of news symbols in both math and
sciences, and the recent STIX project for generation of a new kind of
fonts containing all new scientific mathematical and technical symbols
are not present in current fonts may well indicate just the contrary.
> Finally, I believe that invoking mathematics as an arbiter, as it
> were, in the infix-prefix dispute, is counter-productive also
> because---this is an opinion---mathematicians do not care about
> infix or prefix per se, they care about expressiveness. The problem
> they are solving is "produce, in writing, good abstractions out of
> reality", not "decide whether infix or prefix is better".
I think may be clear that mathematicians know prefix notation
(* 2 3)
since decades ago simply ignore it.
Paul Graham has a point, and at least he has been valiant enough to
recognize in public that prefix math do not work and that may be a
point on why LISP is not more popular. He argues next LISP (Arc) would
correct that.
On Prickle-Prickle, Confusion 43, 3173 YOLD, "Juan R."
<··············@canonicalscience.com> wrote:
> I do not know samples of infix notation for integrals. I know prefix
> like in
>
> Integral dx {x^2}
>
> Or more usual like
>
> Integral {x^2} dx
>
> Maybe could be called contained notation or per-post-fix.
No, it's pure prefix notation. `dx' part is not some magic closing
counterpart of integral sign, nor `indication of variable', it is a
differential of x, by which x^2 is multiplied. So, it would be simply
Integral{x^2 dx}.
Regards,
--
__ Maciek Pasternacki <·······@japhy.fnord.org> [ http://japhy.fnord.org/ ]
`| _ |_\ / { ...bibit puer, bibit canus, bibit presul et decanus,
,|{-}|}| }\/ bibit soror, bibit frater, bibit anus, bibit mater, bibit ista,
\/ |____/bibit ille, bibunt centum, bibunt mille. } ( Carmina Burana ) -><-
On Jul 8, 7:06 pm, Maciek Pasternacki <·······@japhy.fnord.org> wrote:
> On Prickle-Prickle, Confusion 43, 3173 YOLD, "Juan R."
>
> <··············@canonicalscience.com> wrote:
> > I do not know samples of infix notation for integrals. I know prefix
> > like in
>
> > Integral dx {x^2}
>
> > Or more usual like
>
> > Integral {x^2} dx
>
> > Maybe could be called contained notation or per-post-fix.
>
> No, it's pure prefix notation.
Well, no it is NOT prefix and reason for the introduction of the
explicit prefix notation version
Integral dx {x^2}
In [http://abstractmath.org/MM/MMFunctionValue.htm] the integral is
listed under "other notation styles", no under the prefix section as
you think.
> `dx' part is not some magic closing
> counterpart of integral sign, nor `indication of variable',
>From the wiki [http://en.wikipedia.org/wiki/Integral]:
"and dx can be seen as merely a notation indicating that x is the
integration variable, or as a reflection of the weights in the
"weighted sum"."
The "weighted sum" view was the original of the Riemann, but now
mathematicians define integrals from a limit procedure and the dx
reflects simply a 'dummy' variable.
> it is a
> differential of x, by which x^2 is multiplied. So, it would be simply
> Integral{x^2 dx}.
This notation is misleading, because dx is not argument of the
function or operation of integration. It may be
Integral{x^2} dx
dx is part of the whole operator or function of integration. That is
reason some people prefer the notation
Integral dx {x^2}
somewhat like sin{x^2}
Precisely this is the notation prefered in MathML. The following is
"the integral of f of x with respect to x from 0 to b."
<m:apply>
<m:int/>
<m:bvar><m:ci>x</m:ci></m:bvar>
<m:lowlimit><m:cn>0</m:cn></m:lowlimit>
<m:uplimit><m:ci>b</m:ci></m:uplimit>
<m:apply>
<m:ci type='fn'>f</m:ci>
<m:ci>x</m:ci>
</m:apply>
</m:apply>
Note like dx is separated from the integrand f.
On Prickle-Prickle, Confusion 43, 3173 YOLD, "Juan R."
<··············@canonicalscience.com> wrote:
> > > I do not know samples of infix notation for integrals. I know prefix
> > > like in
> >
> > > Integral dx {x^2}
> >
> > > Or more usual like
> >
> > > Integral {x^2} dx
> >
> > > Maybe could be called contained notation or per-post-fix.
> >
> > No, it's pure prefix notation.
>
> Well, no it is NOT prefix and reason for the introduction of the
> explicit prefix notation version
>
> Integral dx {x^2}
>
> In [http://abstractmath.org/MM/MMFunctionValue.htm] the integral is
> listed under "other notation styles", no under the prefix section as
> you think.
It refers to definite integral, and it is explained there that it's because
it denotes function of *three* variables -- so it's because of limits, not
because of magic properties of differential.
> > `dx' part is not some magic closing
> > counterpart of integral sign, nor `indication of variable',
>
> From the wiki [http://en.wikipedia.org/wiki/Integral]:
>
> "and dx can be seen as merely a notation indicating that x is the
> integration variable, or as a reflection of the weights in the
> "weighted sum"."
>
> The "weighted sum" view was the original of the Riemann, but now
> mathematicians define integrals from a limit procedure and the dx
> reflects simply a 'dummy' variable.
No, I can use full differential calculus to transform f(x)dx while
integrating. That's how integration by substitution works. So, differential
of x is part of expression being integrated, and not notation. It can be
seen as mere notation, but it just limits expressiveness for sake of students
who are not fluent in differential calculus.
And with all due respect for Wikipedians, they are much less of authority for
me than Fichtenholtz's `Differential and integral calculus' on my bookshelf
(I have only Polish version and I'm not fluent enough in English mathematical
terminology to translate appropriate passages).
I see that Wolfram's MathWorld, which is also more authoritative than
Wikipedia, doesn't tell explicitly about dx being something special (which
would be worth mentioning, since dx usually means exactly a differential of
x, so double meaning of this notation would need to be stressed), and uses
notation of Integral{dx/x}.
It is a convention for dx to `close' the expression being integrated and to
point variable with respect to which we integrate, but it's a convention that
doesn't strip differential from its meaning to make it magic part of notation.
> > it is a
> > differential of x, by which x^2 is multiplied. So, it would be simply
> > Integral{x^2 dx}.
>
> This notation is misleading, because dx is not argument of the
> function or operation of integration. It may be
>
> Integral{x^2} dx
>
> dx is part of the whole operator or function of integration.
It is not. How do you prove integration by substitution this way?
In my classes it was normal to write, e.g. (UTF-8 warning, ∫ is integral sign)
∫(xdx/x^2) = (1/2)∫(2xdx/x^2) = (1/2)∫(d(x^2)/x^2) = ln(x^2)/2 + C
which works precisely because differential is part of expression being
integrated. And it's just simple example, compared to some methods of
solving differential equations. Should I write on?
> Precisely this is the notation prefered in MathML. The following is
> "the integral of f of x with respect to x from 0 to b."
>
> <m:apply>
> <m:int/>
> <m:bvar><m:ci>x</m:ci></m:bvar>
> <m:lowlimit><m:cn>0</m:cn></m:lowlimit>
> <m:uplimit><m:ci>b</m:ci></m:uplimit>
> <m:apply>
> <m:ci type='fn'>f</m:ci>
> <m:ci>x</m:ci>
> </m:apply>
> </m:apply>
>
> Note like dx is separated from the integrand f.
And, how do I write in MathML my example above, which is perfectly valid
notation? How do you write solving separable ordinary differential
equations? Hint: they are solved by treating derivative as quotient of
differentials, separating differentials of each variable to two sides of
equal sign, and integrating both sides.
Either MathML actually supports operating on differentials under integral, ir
it is in fact broken.
Regards,
--
__ Maciek Pasternacki <·······@japhy.fnord.org> [ http://japhy.fnord.org/ ]
`| _ |_\ / { In general the programmer will always generate
,|{-}|}| }\/ the best code possible and we do not cover this further. }
\/ |____/ ( Ulrich Drepper ) -><-
Dnia 08.07.2007 Maciek Pasternacki <·······@japhy.fnord.org> napisa�/a:
> And with all due respect for Wikipedians, they are much less of authority for
> me than Fichtenholtz's `Differential and integral calculus' on my bookshelf
> (I have only Polish version and I'm not fluent enough in English mathematical
> terminology to translate appropriate passages).
It's Fichtenholz, not Fichtenholtz, should anyone want to dig 'em up. :)
--
Daniel 'Nathell' Janus, GG #1631668, ············@nathell.korpus.pl
create_initial_thread(initial_function);
lose("CATS. CATS ARE NICE.\n");
-- Steel Bank Common Lisp, sbcl/runtime/runtime.c:425
On Setting Orange, Confusion 44, 3173 YOLD, Daniel Janus
<············@nathell.korpus.pl> wrote:
> > And with all due respect for Wikipedians, they are much less of authority
> > for me than Fichtenholtz's `Differential and integral calculus' on my
> > bookshelf (I have only Polish version and I'm not fluent enough in
> > English mathematical terminology to translate appropriate passages).
>
> It's Fichtenholz, not Fichtenholtz, should anyone want to dig 'em up. :)
Yup, you're right. And, according to google, English transliteration
seems to be actually Fikhtengol'ts...
Regards,
--
__ Maciek Pasternacki <·······@japhy.fnord.org> [ http://japhy.fnord.org/ ]
`| _ |_\ / { I tell you this, no eternal reward will forgive us now
,|{-}|}| }\/ for wasting the dawn! }
\/ |____/ ( Jim Morrison ) -><-
On Jul 8, 9:15 pm, Maciek Pasternacki <·······@japhy.fnord.org> wrote:
> It refers to definite integral, and it is explained there that it's because
> it denotes function of *three* variables -- so it's because of limits, not
> because of magic properties of differential.
It also applies to indefinite integrals because of the relation
between both. The difference being that for definite integrals the
function takes just one variable instead three.
> > > `dx' part is not some magic closing
> > > counterpart of integral sign, nor `indication of variable',
Again, NO. From [2]:
{BLOCKQUOTE
the "dy" identifies y as the variable of integration. This is a
dummy variable
that gets "used up" in the integration process
}
And you can many other similar statements:
{BLOCKQUOTE
dx can be seen as merely a notation indicating that x
is the integration variable
}
{BLOCKQUOTE
dx is a notation for the variable of integration
}
Similar stuff applies to derivatives. E.g. in [2] the mathematician
carefully adds: "Here 'dy' identifies the differentiation variable".
> > From the wiki [http://en.wikipedia.org/wiki/Integral]:
>
> > "and dx can be seen as merely a notation indicating that x is the
> > integration variable, or as a reflection of the weights in the
> > "weighted sum"."
>
> > The "weighted sum" view was the original of the Riemann, but now
> > mathematicians define integrals from a limit procedure and the dx
> > reflects simply a 'dummy' variable.
>
> No, I can use full differential calculus to transform f(x)dx while
> integrating.
A lot of those 'differential' calculus transformations are unrigorous
and some give wrong answers. In fact, believing that an integral is an
infinity sum of infinitesimal elements f(x)dx is only a "Na�ve
interpretation" for mathematicians [11].
> That's how integration by substitution works. So, differential
> of x is part of expression being integrated, and not notation.
No. The dx is not part of the expression being integrated but a
notation. E.g. in " f dx" the expression being integrated is f and
only f.
Take a look to [2] where the expression to be integrated was boxed.
The same for indefinite integrals [6]. Moreover, the role of dx as
mere notational convenience is emphasized again in a clear way e.g. in
[6]: "The expression dx is short for 'with respect to x'."
Look also definition of *integrand* (i.e. the expression being
integrated) on Wolfram [8].
> And with all due respect for Wikipedians, they are much less of authority for
> me than Fichtenholtz's `Differential and integral calculus' on my bookshelf
> (I have only Polish version and I'm not fluent enough in English mathematical
> terminology to translate appropriate passages).
Then you are not arguing by comprehension but by appeal to old
'authority'.
> I see that Wolfram's MathWorld, which is also more authoritative than
> Wikipedia, doesn't tell explicitly about dx being something special (which
> would be worth mentioning, since dx usually means exactly a differential of
> x, so double meaning of this notation would need to be stressed), and uses
Well in [3] Wolfram's MathWorld agrees with me. Note as explicitely
says "integral of the function f(x)" instead something misleading like
your belief "integral of f(x) times dx".
Note also how carefully remarks that expressions like" dx" may be
understood like integral for the case f(x) = 1, i.e. " 1 dx". The
remark is understandable because the dx is pure notation and otherwise
" dx" would be not interpretable. Yes, you would think that is the
integral of "dx" but that is not right.
Similar stuff about indefinite integrals.
> notation of Integral{dx/x}.
You clearly confound notation with meaning. The correct meaning is
" {1/x}dx". "dx" is mere notation indicating the variable of
integration.
You are free to write the notation {dx/x} but you may be aware is
just a notation. Concretely the notation {dx/x} does NOT denote a
fraction like you appear to think.
> It is a convention for dx to `close' the expression being integrated and to
> point variable with respect to which we integrate, but it's a convention that
> doesn't strip differential from its meaning to make it magic part of notation.
No. There is a beatiful page "What dx Actually Means" [4] highlighting
many standard misunderstandings about calculus. The interesting part
is at the bottom, I reproduce here:
{ BLOCKQUOTE
Important Note Added by Those Wiser Than I
Since I first posted this paper, two different people have emailed
me
to tell me that Real Mathematicians don't do this. Playing with dx
in
the ways described in this paper is apparently one of those smarmy
tricks
that physicists use to give headaches to mathematicians.
I didn't even realize I was preaching something nonstandard, because
most
of my mathematical background comes from physics classes. So, be
warned.
If you are taking physics classes, the stuff in this paper will be
very
useful to you. If you are taking math classes, it may help you to
gain some
intuition, but use it cautiously: you may be expected to master more
rigorous
methods.
Now (I hope you're enjoying this as much as I am) another person
wrote,
in response to that note, saying: "I noticed a note at the bottom of
the
page on differentials, saying that Real Mathematicians don't use
differentials,
that they aren't "rigorous." In fact, a Real Mathematician, Abraham
Robinson,
in the 1960's proved a rigorous formulation of differentials-a
formulation
in which you can with full confidence do algebra with infinityly
small and
infinityly large quantities. It is a branch of mathematics known as
"Nonstandard Analysis"; it is actually used by lots of
mathematicians
because proofs are simpler and theorems less wordy in the "non-
standard"
formulation. Some people have gone through and written whole
introductory
calc texts that abandon limits altogether in favor of the much
simpler dx,
though they get very little attention. There is no shame in using
differentials."
In all fairness to my earlier critics, I should point out that the
first girl who
wrote to me told me that I was using "nonstandard analysis," which I
thought she
meant as a criticism.
}
Why do not "Real Mathematicians" play with dx in the ways described in
[4]? Easy, because there exist problems to define dx (an
infinitesimal) in a rigorous and workable way. That is reason that dx
is left as pure notational convenience. Do not confound math with
tricks.
Further comments:
[i]
In 'traditional' calculus the difference between differentials and
infinitysimals is not noticed. You can also find many courses for
enginners or physicists where differentials are directly identified
with infinitesimals. One may differentiate differentials from
infinitesimals. Mathematicians avoid to work with infinitesimals
(except in branches like nonstandard analysis), not with
differentials.
Mathematicians who thought me math used (and still use) notation D for
differentials [7] and d for integrals [9]. (Text is not in english and
the context is that of multivariable but valid for you can see
notation).
A differential df (better denoted by "Df") is a linear map (see def
7.1 on [7]) defined on ordinary numbers. This is also explained in the
Wiki but since you do not like it I avoid to cite the page.
Contrary to differentials, the infinitesimals df are not defined in
ordinary numbers and you need extensions like that by Robertson.
[ii]
His "it is actually used by lots of mathematicians" is an exageration.
Robertson non-standard analisys is largely unpopular and even rejected
by many mathematicians.
Alain Connes' evaluation of the nonstandard approach to infinitesimals
dp is as follows:
{BLOCKQUOTE
So now, if you ask a mathematician about this naive question,
he might very well answer: well, dp is a 2-form, or it's a
measure, or something like that. But then you can try to ask him
more precise questions, for instance 'what is the exponential
of -1/dp'. And then it will be hard for him to give a satisfactory
answer [...] Now the book I was reading claimed to give an answer,
and it was what is called a non standard number. So I worked on this
theory for some time, learning some logics, until eventually I
realized
there was a very bad obstruction preventing one to get concrete
answers.
A nonstandard number is some sort of chimera which is impossible to
grasp
and certainly not a concrete object".
}
If you are worried about authority issues, let me say that Connes won
the 'Nobel Prize' for mathematics, i.e. the Fields Medal.
> > > it is a
> > > differential of x, by which x^2 is multiplied. So, it would be simply
> > > Integral{x^2 dx}.
>
> > This notation is misleading, because dx is not argument of the
> > function or operation of integration. It may be
>
> > Integral{x^2} dx
>
> > dx is part of the whole operator or function of integration.
>
> It is not. How do you prove integration by substitution this way?
Mathematicians prove that not me. The proofs follow from rigorous
manipulations on the _definition_ of integral.
> In my classes it was normal to write, e.g. (UTF-8 warning, is integral sign)
>
> (xdx/x^2) = (1/2) (2xdx/x^2) = (1/2) (d(x^2)/x^2) = ln(x^2)/2 + C
>
> which works precisely because differential is part of expression being
> integrated.
Ok, in _your_ classes.
First, 'differential' (do you really mean infinitesimal here) is not
being integrated. See references cited above.
Second, In the Riemann original approach, integral are a special sum
of infinitesimals, but as said to you before that is not rigorous.
Reason which modern mathematicians work integrals in a different way,
lefting "dx" as pure notation. I explained this before you. I will do
no more.
Third, informal *tricks* based in notational similarities are often
useful. However, the problem is that can fail, specially at advanced
applications.
> And, how do I write in MathML my example above, which is perfectly valid
> notation?
You continue to confound notation with meaning. The code I wrote is
content MathML, which is aimed to encode mathematical meaning, not its
notation.
The *notation* dx/x looks like a fraction but is not a fraction. That
is because content and presentation are separated in MathML
phylosophy.
I will not write the whole code because time issues. For instance, the
rendering of a "dx/x" using fraction layout is
<mfrac>
<mrow>
<mo>ⅆ</mo>
<mi>x</mi>
</mrow>
<mi>x</mi>
</mfrac>
in presentation MathML (which captures the notation or the 'display').
Since "dx/x" is NOT a fraction the content encoding will be different
from encoding a real fraction. The code for dx(1/x) will be something
like (ignoring namespaces, attributes, and other details)
<apply><int/>
<bvar><ci>x</ci></bvar>
<apply><divide/>
<cn>1</cn>
<ci>x</ci>
</apply>
</apply>
Note AGAIN like the "dx" has absolutely no place in content code. "dx"
appears in the presentation code and in the rendering only because dx
is a mere notation indicating the variable of integration. The
expression to integrate is just (1/x). <bvar> element indicates the
variable of integration by binding it.
> How do you write solving separable ordinary differential
> equations? Hint: they are solved by treating derivative as quotient of
> differentials, separating differentials of each variable to two sides of
> equal sign, and integrating both sides.
Again you confound notation, operational ***tricks*** based in
notations, and mathematical meaning.
Specially miselading is your claim one can treat derivative as
quotient of 'differentials' (i.e. infinitysimals). Something like dy/
dx is mere notation (Leibniz notation).
>From [12]:
{BLOCKQUOTE
However, if we wish to obtain a clear grasp of the meaning of the
differential calculus, we must beware of regarding the derivative as
the quotient of two quantities which are actually infinityly small.
[...]
Such a conception of the derivative is incompatible with the clarity
of ideas demanded in mathematics; in fact, it is altogether
meaningless. [...]
in the early days of the differential calculus, even Leibnitz himself
was capable of combining these vague mystical ideas with a thoroughly
clear understanding of the limiting process. It is true that this fog,
which surrounded the foundations of the new science, did not prevent
Leibnitz or his great successors from finding the right path. But this
does not release us from the duty of avoiding every such hazy idea in
our building-up of the differential and integral calculus.
However, the notation of Leibnitz is not merely attractive in itself,
but is actually of great flexibility and the greatest use. The reason
is that we can deal in many calculations and formal transformations
with the symbols dy and dx in exactly the same way as if they were
ordinary numbers.
}
Effectively, in many occasions working dy/dx as a real fraction gives
right results but [i] it is a trick (i.e. the real reason which
procedure often works can be seen from the actual theory), [ii]
sometimes the trick fails and gives wrong answsers (the actual theory
also says when). Example?
Take differential dF = (F/x) dx + (F/t) dt
You would divide both sides by dt
(dF/dt) = (F/x) (dx/dt) + (F/t)
and next, "treating derivative as quotient of differentials", you
would obtain
(d/dt)F = (F/x) (d/dt)x + (F/t) 'standard'
But your 'derivation' will be mathematically invalid. In fact, it is
nonsensical.
The correct expression (see e.g. eq. 24 on [10]) is
(d/dt)f = (F/x) (d/dt)x + (F/t) 'new'
where f is different from F.
The 'standard' formulae (you can find in many textbooks of science) is
incorrect and gives wrong answers for cases where the difference
between f and F is noticeable.
The 'new' formula has interesting applications in electrodynamics.
> Either MathML actually supports operating on differentials under integral, ir
> it is in fact broken.
You are going too far... It is so 'broken' that Mathematica exports
and imports it in both presentation and content flawors. E.g. you can
write type Integrate [1/x, x] in Mathematica 6 and integrate the
expression or export it to MathML.
I will not reply more. This is largely off-topic and this is not a
summer course on calculus.
[1] http://abstractmath.org/MM/MMFunctionValue.htm
[2] http://www.math.vt.edu/people/quinn/calc_refs/int_note.pdf
[3] http://mathworld.wolfram.com/Integral.html
[4] http://www4.ncsu.edu/unity/lockers/users/f/felder/public/kenny/papers/dx.html
[5] http://mathworld.wolfram.com/Calculus.html
[6] http://people.hofstra.edu/Stefan_Waner/RealWorld/Calcsumm6.html
[7] http://webs.uvigo.es/matematicas/campus_vigo/cursosAA-BB/Quimicas1/material/tema7.pdf
[8] http://mathworld.wolfram.com/Integrand.html
[9] http://webs.uvigo.es/matematicas/campus_vigo/cursosAA-BB/Quimicas2/resumes/integraismultiples.pdf
[10] Andrew E. Chubykalo, Rolando A. Flores and Juan A. Perez. On an
ambiguity in the concept of partial and total derivatives in classical
analysis. (June 16, 2006) arXiv:math.CA/9906079 v1.
[11] http://kr.cs.ait.ac.th/~radok/math/mat6/calc2.htm#2.1.3
Extensions, Notation. Fundamental Rules:
[12] http://kr.cs.ait.ac.th/~radok/math/mat6/calc2.htm#2.3.7 The
Derivative and the Difference Quotient
On Sat, 21 Jul 2007 09:37:56 -0700
"Juan R." <··············@canonicalscience.com> wrote:
> I will not reply more. This is largely off-topic and this is not a
> summer course on calculus.
ACK. I only wanted to thank you for explaining this in such detail. I'm
convinced now, and I'm really grateful that you spent your time on writing
this to me.
Regards,
--
__ Maciek Pasternacki <·······@japhy.fnord.org> [ http://japhy.fnord.org/ ]
`| _ |_\ / { ...Read some Kerouac and it put me on the tracks
,|{-}|}| }\/ to burn a little brighter now... }
\/ |____/ ( Fish ) -><-
Juan R. wrote:
> Why am I perceiving (it is my impression) so one reluctance to
> evolution in this newsgroup?
You're asking the missing link why he isn't human. Programmers evolve from
this group onto c.l.functional.
--
Dr Jon D Harrop, Flying Frog Consultancy
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/?usenet
In article <························@ptn-nntp-reader02.plus.net>,
Jon Harrop <···@ffconsultancy.com> wrote:
> Juan R. wrote:
> > Why am I perceiving (it is my impression) so one reluctance to
> > evolution in this newsgroup?
>
> You're asking the missing link why he isn't human. Programmers evolve from
> this group onto c.l.functional.
\|||/
(o o)
|~~~~ooO~~(_)~~~~~~~|
| Please |
| don't feed the |
| TROLL! |
'~~~~~~~~~~~~~~Ooo~~'
|__|__|
|| ||
ooO Ooo
--
http://lispm.dyndns.org
On Jun 3, 7:12 pm, Jon Harrop <····@ffconsultancy.com> wrote:
> Juan R. wrote:
> > Why am I perceiving (it is my impression) so one reluctance to
> > evolution in this newsgroup?
>
> You're asking the missing link why he isn't human. Programmers evolve from
> this group onto c.l.functional.
Is your thought related to that belief that "LISP is a local maximum
in landscape of programming languages" i heard so often?
And is people who evolves outside of LISP those do not believing LISP
was a maximum but it can be improved in a number of ways?
From: Kent M Pitman
Subject: Re: Any macro for inserting math "normally"
Date:
Message-ID: <u4pln2i17.fsf@nhplace.com>
"Juan R." <··············@canonicalscience.com> writes:
> I agree on that popularity does not imply being good.
>
> However, I also think that the concept of 'good' is relative. Maybe
> LISP is not more popular because is not 'good' enough, using here a
> definition for 'good' different from your own one.
I do not disagree LISP might be doing the wrong thing, if what one
means by "might" is "has a non-zero probability of being so". Then
again, if that's all you mean, it's a weak claim. Might Lisp be more
popular if it used square brackets instead of parens? Maybe, too.
One can speculate all day on all manner of maybes. Talk is cheap.
I have not forbidden you, nor am I capable of doing so if I wanted to,
from trying the experiment. What I have done is spoken about the
several ways the experiment has happened in history and how it hasn't
(yet) had the effect you expect. I have talked about reasons that
might be. But you're welcome to ignore all of that.
Here's an important thing I believe, and you're welcome to ignore me
on this, too, but it will do you and others well to understand this:
If someone makes a maintained implementation and enters the
marketplace, betting their very livelihood on their beliefs, I trust
certain things that those people say a lot. What I trust is not that
they are right because might well not be right. What I trust is that
when they say they think they are right, they would not be lying and
would not be deliberately overlooking something because it was
convenient. What's generally convenient is to make money and, more
generally, to be successful. (In this regard, I include those who
make free software on the assumption that the revenue from that
software will pay for the meals on their table, and I do not include
those who make free software "for the good of mankind" because they
have enough left over from growing corn or manufacturing tables or
whatever pays their bills to play with Lisp. That does not make them
bad people. It does mean, for the purposes of this remark, that they
are not betting their livelihood on the outcome of their best
decisions.)
You seem to believe with utter certainty that this would grow the
market. Here's my belief, and I think most economists will back me
up: If you know a surefire, zero-risk way to grow a market, dive in
and do it. Because such situations are rare and valuable and not to
be overlooked. If you can articulate your case so clearly, talk to a
banker, and I'm sure they'll lend you the money. Bankers love zero
risk and high return and would love to hear you. If you really
thought you were for sure right, why not mortgage your house and all
that you own to prove you were right?
But if you find reason to hesitate in taking that action, and you feel
a need to ask others to take that action for you, then I perceive that
you see risk you are not acknowledging.
And once you see that risk, and you understand the stakes involved,
you'll perhaps respect the decisions better.
Incidentally, before the days of free software, you could more easily
make the case that it was hard for you to try this experiment. That's
not so any longer. You can do an experiment cheaper because you don't
have to start from zero. Heck, you don't even have to call the result
Lisp. (Many have suggested that's the key to riches, too.)
I'm not saying I wouldn't look at the result. Maybe I'll be part of
your new user community. I don't think others are insisting they will
stubbornly refuse to use your new Lisp either. People may refuse, but
won't necessarily stubbornly refuse. They may just decide it doesn't
work for them. That's for you to manage. That's the issue of a free
market. You're welcome to try but no one is required to care.
But the test of whether you are right is your willingness to take the
risk of setting up the experiment and then seeing how it plays out.
The test is not making a verbal case and asserting the obvious
rightness of your case without such a test.
> This is something always surprised me. Some LISPERS appear to believe
> that the only definition for 'good' is that they grasp.
Nothing could be farther from the truth.
They experiment with things all the time. But they choose what they
experiment with, and you're asking to choose for them.
Everyone will be interested to watch your experiment.
> I like LISP
> but I find irritant reading some guru
I don't like the word guru any more than dogma. I don't know who it
applies to but it sounds like someone who has the annoited right to be
correct. I have no idea if it applies to me, though some have done it
(and I cringe when they do exactly because I consider it an exercise
in hubris to step into such trappings). But to the extent that it
even might apply to me, I want to respond by saying that none of what
I've said, nor of what I generally say, is to be accepted just because
of what I say, except perhaps that when I give an account of what I
remember happened in the past, you'll have to take that it is, at
least, my personal subjective view where I can't offer better
evidence. Often I cannot prove all of my recollections, so rather
than asking you to distrust those, I suggest you ALSO ask the opinions
of others and then merge or select among them. This is pretty much
how any court operates: there's a notion of "best evidence", and you
should ask for best evidence. Sometimes such evidence will be objective
and sometimes not. But certainly when someone offers you a claim about
goodness (as I have not, but you have, as I see it here, ironically),
the goodness should be looked at critically.
> that LISP is for "the good programmers"
I'm not sure I've never heard anyone seriously make that claim. I
have sometimes heard people observe that because it doesn't provide
"training wheels", and because it uses a different development style
than many are taught in school, it tends to select a certain group
that may be above average. I don't know that anyone has said this was
by design as much as by effect.
> and in no part the guru agree
Absent a name, this can't be rebutted. Cite the specific situations
since now you're making a universal quantification across an unknown
set.
> that maybe he is
> considering "good programmers" are bad programmers from other's
> perspective.
It is certainly true that the notion of Good and Bad in programming are
sometimes objectively measurable (as "good engineering" is measurable) and
sometimes only subjectively measurable (as "good art" is not measurable).
But regardless, when you're talking about a broad class of
unidentified souls refusing to agree or disagree with a vague claim, I
doubt you're right. Unless you mean that broad class to be,
trivially, the set of people selected to make my claim true.
> Once remarked that, let me remark again that my plea was not for
> development of a 'popular' LISP by changing the definition of 'good'
> but really by improving it.
What is really improving and not is subjective. That doesn't make it
bad, but these words, as a matter of objective fact, have no
testability and are therefore really not rebuttable (even if I could
figure out your point here). Why not just do the experiment and show
the results.
> > Beyond that, algebraic/infix notation has as its key feature "brevity"
> > with all other needs (a priori intelligibility, visiblity of
> > grouping, etc.) heavily subordinated. I don't see it as so
> > obviously right that infix notation is best for all needs. Is it
> > handy? Sometimes.
>
> Well, I think I already remarked this several times, but I will do
> again.
>
> In no part I am stating that one would abandon the prefix syntax by an
> infix one. I am clearly stating -again and again- that people would
> _choose_ what syntax they prefer in basis to personal preferences and
> class of problems they solve.
The devil is in the details, and you're not doing the details. How would
they choose. What specific syntax do you propose? How will programs access
it? How will they know when they are and are not using it? How will it
interact with setting up readmacros? How will it interact with the readtable?
How will it interact with the printer? If you haven't heard it here, people
are asking you for details, and when they (certainly when I) ask for details,
we aren't trying to shut you up, just saying that you're being so inartciulate
about it that you don't even seem to realize the set of questions you need
to answer to have made a coherent suggestion. You could perhaps answer them.
You just haven't. The exercise of making the implementation would help you
answer them.
> That is different from prefix LISP with traditional infix macro
> cosmetics.
Do you use readmacros? Do you understand that those of us who are confused
are partly trying to understand when this is in play and not? I and others
use specialized syntax all the time, and you can't just change one detail
without saying how the consequences of your changes filter through. That's
not me constraining you--that's me telling you how the universe works.
It reminds me of people asking to extend EQUAL. You can make your own
EQUAL, but you can't extend EQUAL. EQUAL is already a total function.
It has meaning on all types. People who suggest extending it are
saying they don't understand they are changing something, probably
because they don't value what they are changing. It could be argued
to be ok to change it, but you can't change it without acknowledging
the effect of doing so. You can't claim it's wholly upward compatible
when it's not.
> > So maybe it's an issue of resource. But if that's so, how can they
> > argue that the reason that the lisp-notation people should help the
> > infix people is that the lisp-notation people are too small a
> > community and need the help of the outsiders. If that were so, it would
> > be the lisp-notation people who were pleading with the infixers for help.
> > But that isn't happening. The lisp-notation people like the lisp notation
> > in part because it empowers them not to need the resources of the others.
>
> Once remarked above you can use an all-prefix syntax if you want, I
> would state now that I agree with Paul Graham (and others) when he
> states that prefix does not work for large chunks of math. Graham
> recognizes that after using prefix syntax during many decades he find
> syntax odd for math and he (and others) want infix math for Arc (next
> LISP).
>
> Why am I perceiving (it is my impression) so one reluctance to
> evolution in this newsgroup?
You're observing a reluctance to call something evolution when it has
not yet occurred. Make it happen. Then we'll talk about it. Or if
you want us to talk about a vision, articulate the vision. But,
please, don't talk about the fact that you have a vision and simply
expect us to believe your vision works, without saying the details.
> > Summing up, the strategy seems to be for the large community to
> > convince the small community they are doing it wrong, so that the
> > large community will get the benefits that the small community has.
> > What's wrong with this picture?
>
> It is much more simpler, instead splitting the world between prefix-
> all-parenthesised people and infix-arithmetic people (roughly LISPERS
> and the rest) I would be glad to unify both communities in a new
> framework.
This is like saying you want to unify everyone under one church by
simply eliminating the others.
Unification comes from understanding what people value, and then seeking
to construct a framework that simultaneously supports both values.
You're asking for infix, and no one is saying it's bad. But you haven't
done the legwork of understanding the other community. So you're just
asserting it's wrong and that it's stubborn for being different.
This long rebuttal of my message has focused on your feeling constrained
when no one has constrained you. But it's short on technical details.
> Maybe, it is a too idealized vision and some elitist
This is ad hominem again. I'm trying to largely ignore it, so as not to
escalate it, but I do feel a need to point it out.
> part of the LISP
> community will react fiercely to the idea.
I assume people will self-label as elitist if they disagree? Could we
just leave the labels out, please? Good ideas will stand on their own.
> Maybe current LISP is used
> as a barrier against possible contamination with the rest of the world
> -some LISP guru called "the nerds"-. I do not know.
People have opined a great many things about how communities react,
but they are all after-the-fact ways, not planned. See my discussion
of the way markets work at top of this message. But I can tell you
with reasonable personal certainty (that you can believe or not) that
a claim in a design committee meeting that "maybe if we do X, it will
keep the language from being contaminated" would have been laughed out
of the room.
I cite as objective evidence the myriad X3J13 proposals attached to
the HypeSpec, none of which cite a reason for adopting the change
based on "social separation" nor anything like it.
In fact, it might be possible, with a bit of digging, to find an ANSI
rule against such an exclusionary approach even if it were possible.
> > If one believes they have The Right Paradigm, why doesn't one just run
> > with it? Why convince others?
>
> This is ironic. How many times we heard from LISP community that LISP
> is The language?
Source? It's probably true that people proud of their community will
use such statements regardless. (Most people will cite their country,
their soccer or bowling team, etc. as The team. Marketing will
generally cite its product as The product.) All that says is that
they've worked hard to improve on what came before. Such improvement
is subjective, but certainly no one tries to NOT improve. So why
wouldn't they use such language?
And yet, does this translate to no sports player ever studying another
team's plays to improve? To no one ever offering a comparative class
in political systems? To no one ever studying new approaches to
building or marketing products?
One learns to hear and understand such remarks in context.
In Logic, one learns that a single conflicting statement makes the
entire system bankrupt. The world, at least that world we are capable
of discussing, is full of contradictions. So either it is bankrupt
from the outset, or we have to learn to be tolerant of the fact that
people will use flowery language without meaning to melt the system down.
> How many times LISPERS tried to convince the rest of
> the world to switch to an all prefix full parenthesised syntax?
I'm not sure what this means or why it's relevant? People try to
convince me that their favorite car is really good, too. That I
should watch their favorite TV show? What conclusions do I draw from
those behaviors, other than that someone, somewhere is happy and wants
to share that happiness. I'm not sure that's a statement of design.
> Are not many quotes in [http://lispers.org/] trying to convince
> others?
Perhaps they are. What would that prove?
[I had some responses to your message beyond here, but both your text and
my responses seemed increasingly off topic, so I've opted for stopping here.]
Kent M Pitman wrote:
> "Juan R." <··············@canonicalscience.com> writes:
>
>
>>I agree on that popularity does not imply being good.
>>
>>However, I also think that the concept of 'good' is relative. Maybe
>>LISP is not more popular because is not 'good' enough, using here a
>>definition for 'good' different from your own one.
>
>
> I do not disagree LISP might be doing the wrong thing, if what one
> means by "might" is "has a non-zero probability of being so". Then
> again, if that's all you mean, it's a weak claim. Might Lisp be more
> popular if it used square brackets instead of parens? Maybe, too.
Oh, god, I played with that, impossible to read. Of course I did not
give it the two-four weeks it took for (these) to disappear, but then
(these) did not look so horrid at first.
> One can speculate all day on all manner of maybes. Talk is cheap.
And Juan is a Certfied Bozo, so I am not sure why anyone would bother.
hth, kt
On Jun 5, 5:32 am, Kent M Pitman <······@nhplace.com> wrote:
> I do not disagree LISP might be doing the wrong thing, if what one
> means by "might" is "has a non-zero probability of being so". Then
> again, if that's all you mean, it's a weak claim.
We know that LISP, unlike other very popular languages, choose the
prefix way. We also know that prefix notation is often cited as one of
weakness of LISP. We also know that Graham has recognized in public
that the problem of the prefix notation is not lack of familiarity but
that the notation is odd. Nothing of this may be weak.
In fact, you may know very well that an infix LISP has been one of
dreams of the LISP community. The number of projects tried to develop
a powerful LISP with a more 'conventional' syntax is huge so you can
grasp the advantages of LISP with advantages of conventional syntaxes.
All projects I know failed by some or other reason and I suspect that
recent Arc proposal (next LISP) will fail also in that goal.
I believe that failure may be based in all those 'infix' LISPs were
based in 'cosmetic' syntax layers, therefore the weakness of the
prefix notation was not eliminated but 'camouflaged'.
> Might Lisp be more
> popular if it used square brackets instead of parens? Maybe, too.
> One can speculate all day on all manner of maybes. Talk is cheap.
[i] I think that question was being addressed was beyond your trivial
comment.
[ii] Do you believe that the generalized avoid of parentheses for
grouping code in the landscape of computer languages was a random
choice? Or do you believe that lack of popularity of (...) versus
{...} has some footing on readability issues?
> I have not forbidden you, nor am I capable of doing so if I wanted to,
> from trying the experiment. What I have done is spoken about the
> several ways the experiment has happened in history and how it hasn't
> (yet) had the effect you expect. I have talked about reasons that
> might be. But you're welcome to ignore all of that.
Well, I think that I already explained I believe was the reason for
failure of those experiments (really projects). Above I did again.
> You seem to believe with utter certainty that this would grow the
> market. Here's my belief, and I think most economists will back me
> up: If you know a surefire, zero-risk way to grow a market, dive in
> and do it. Because such situations are rare and valuable and not to
> be overlooked. If you can articulate your case so clearly, talk to a
> banker, and I'm sure they'll lend you the money. Bankers love zero
> risk and high return and would love to hear you. If you really
> thought you were for sure right, why not mortgage your house and all
> that you own to prove you were right?
The world is not about certainty but about probabilities. You
recommended me a reading before, please let me recommend you now the
book _The End of Certainty_ by Nobel winner Ilya Prigogine.
> But if you find reason to hesitate in taking that action, and you feel
> a need to ask others to take that action for you, then I perceive that
> you see risk you are not acknowledging.
Did I ask you for money? No, true?
If you perceive this project as risky for your own interests you would
ignore. If you perceive like contrary to your economical goals then
you will obligated to battle against it.
Most other people will ignore it and some few, I wait, welcome
interested in a project of this kind.
I am proposing here an idea and receiving feedback. I am also battling
the traditional "prefix notation of LISP is good but is not popular
because rest of the world lack familiarity" heard so often in this
community with a more accurate "the world reject prefix notation of
LISP because is not good enough".
> > This is something always surprised me. Some LISPERS appear to believe
> > that the only definition for 'good' is that they grasp.
>
> Nothing could be farther from the truth.
Sorry but I did not invented "The language God would have used to
implement the Universe", "The greatest single programming language
ever designed" and similar quotes reported at http://lispers.org/
E.g. Paul Graham is popularising next LISP (Arc) as "being designed
for the good programmers".
The problem, as I stated before, is that in no part of his discourse
Graham exposes the definition for "good". Maybe others consider poor
Graham calls "good".
This arrogance and elitism very well characterizes a part of the LISP
community.
> > I like LISP
> > but I find irritant reading some guru
>
> I don't like the word guru any more than dogma. I don't know who it
> applies to but it sounds like someone who has the annoited right to be
> correct. I have no idea if it applies to me,
No, I am not applying the word to you. There is a proud guru in this
newsgroup which knows everything. I was thinking in him and others.
> > that LISP is for "the good programmers"
>
> I'm not sure I've never heard anyone seriously make that claim. I
Let me extract large quotation from [http://www.paulgraham.com/
arcll1.html]:
[BLOCKQUOTE
3. A Language for Good Programmers
- Target user: opposite of Java.
- Programmable programming language.
- By default, allow.
- The language I wish someone would make for me.
- Brevity (what you like about abstraction)
Java was, as Gosling says in the first Java white paper, designed for
average programmers. It's a perfectly legitimate goal to design a
language for average programmers. (Or for that matter for small
children, like Logo.) But it is also a legitimate, and very different,
goal to design a language for good programmers.
Languages designed for average programmers have to put safety first.
Expert programmers, on the other hand, care only about power, and are
going to be annoyed with any language that gets in their way in the
name of safety. You see this difference in any tool, from cars to
dishwashers.
I don't know if anyone has consciously designed a language for good
programmers before. There have been several languages that were in
effect designed for good programmers, because good programmers
designed them for their own use. C, Lisp, and Smalltalk all came about
this way.
In some ways it makes the problem easier when you can assume the user
is a good programmer. Language designers often find themselves
worrying about the mess users might make if they were allowed to do
such-and-such. Once you assume the user is a good programmer, you
automatically have the answer to any such question: let the user do
whatever he wants.
Lisp has always been way down that end of the continuum. John Foderaro
called it "the programmable programming language", because there is so
much the programmer can change. Arc aims to maximize this aspect of
Lisp. Instead of assuming that we know what's good for the programmer
to be allowed to get his hands on, we assume that the programmer will
want to do things we never even imagined, and so will need to be able
to get his hands on everything.
]
I do not know if that is serious enough for you.
Note: I have read in other sites LISPERs arguing that LISP is for good
programmers and the average quality of LISP programmers is better than
in other languages. I never see data supporting that kind of
affirmations.
> The devil is in the details, and you're not doing the details. How would
> they choose. What specific syntax do you propose? How will programs access
> it? How will they know when they are and are not using it? How will it
> interact with setting up readmacros? How will it interact with the readtable?
> How will it interact with the printer? If you haven't heard it here, people
> are asking you for details, and when they (certainly when I) ask for details,
> we aren't trying to shut you up, just saying that you're being so inartciulate
> about it that you don't even seem to realize the set of questions you need
> to answer to have made a coherent suggestion. You could perhaps answer them.
> You just haven't. The exercise of making the implementation would help you
> answer them.
You are right, I am not going to discuss details here, but because of
two reasons:
[i] I lack time enough for detailed discussions now.
[ii] I do not consider newsgroup may be correct place. I would like a
more formal discussion over a basic proposal in paper.
> > It is much more simpler, instead splitting the world between prefix-
> > all-parenthesised people and infix-arithmetic people (roughly LISPERS
> > and the rest) I would be glad to unify both communities in a new
> > framework.
>
> This is like saying you want to unify everyone under one church by
> simply eliminating the others.
If you think that, either you did not read I wrote or you misread me.
In a personal note, it is also kidding you decide to remark about that
when a part of LISP community is notorious in trying "to unify
everyone else under one church" that of LISP of course. Is not a part
of LISP community notorious by trying to convince anyone that LISP is
the only language. Did not never heard the term "LISP zealot" before?
I did not write stuff like "[...] is written in Lisp, which is the
only computer language that is beautiful."
> Unification comes from understanding what people value, and then seeking
> to construct a framework that simultaneously supports both values.
Exact. No division but sum.
> You're asking for infix, and no one is saying it's bad. But you haven't
> done the legwork of understanding the other community. So you're just
> asserting it's wrong and that it's stubborn for being different.
If you think that, either you did not read I wrote or you misread me.
Next a concise listing of my main points:
[i] Most of people dislikes prefix notation. It is not a question of
familiarity but that prefix notation is not readable for large chunks
of math (as Graham also agrees).
[ii] Instead trying to convince rest of the world to switch to prefix,
i.e. trying to adapt people to LISP, try to adapt LISP to the world.
That does not mean switch from prefix to infix, which appears to be
you understood, but to *extended* LISP from prefix alone to prefix
more infix more postfix.
[iii] The prefix notation has limits: topological, expressiveness,
human readability, and in some cases of parsing benchmarks.
[iv] Generate an adaptable extensible language. Let people to choose.
Some people will prefer write something like [a + 2] where others will
prefer (+ a 2). Do NOT obligate people to use either.
> > This is ironic. How many times we heard from LISP community that LISP
> > is The language?
>
> Source?
This newsgroup, webpage from associations of users as lispers.org, the
wiki article on LISP and others. On the wiki you can find very
arrogant thoughts in the style of
"LISP being the most powerful and cleanest of languages" by Richard
Stallman
"the greatest single programming language ever designed" by Alan Kay
"[...] is written in Lisp, which is the only computer language that is
beautiful." by Neal Stephenson.
> It's probably true that people proud of their community will
> use such statements regardless. (Most people will cite their country,
> their soccer or bowling team, etc. as The team. Marketing will
> generally cite its product as The product.) All that says is that
> they've worked hard to improve on what came before. Such improvement
> is subjective, but certainly no one tries to NOT improve. So why
> wouldn't they use such language?
If you read i wrote carefully, you would understand that was not my
point.
"Juan R." <··············@canonicalscience.com> writes:
> On Apr 28, 6:21 pm, Kent M Pitman <······@nhplace.com> wrote:
>> I've been recently reading Ayn Rand's book The Fountainhead (a book I
>> strongly recommend, by the way
>
>> Summing up: Is infix desired by me? No. Is it by some? Yes.
>
> "Some" means a 90% of programming world maybe?
I'd like to second Kent's recommendation.
On May 14, 7:47 pm, Lars Brinkhoff <·········@nocrew.org> wrote:
> "Juan R." <··············@canonicalscience.com> writes:
> > On Apr 28, 6:21 pm, Kent M Pitman <······@nhplace.com> wrote:
> >> I've been recently reading Ayn Rand's book The Fountainhead (a book I
> >> strongly recommend, by the way
>
> >> Summing up: Is infix desired by me? No. Is it by some? Yes.
>
> > "Some" means a 90% of programming world maybe?
>
> I'd like to second Kent's recommendation.
How will that reading change figures?
In article <·············@nhplace.com>,
Kent M Pitman <······@nhplace.com> wrote:
> Tamas <······@gmail.com> writes:
>
> > Frankly, I can't see the point of this ongoing discussion. People who
> > like prefix have Lisp. So do people who would prefer infix but are
> > willing to put up with prefix because of the advantages Lisp offers.
> > People who hate prefix so much that they won't use Lisp have other
> > languages to choose from, or can try to invent a language as powerful
> > as Lisp with infix syntax (but I would be surprised to see that).
>
> You're making and immediately mixing several assumptions.
>
> First, people are not of one mind. People use one notation for one thing
> and another for another. It's why LOOP and FORMAT have special languages
> all their own. It's why regular expressions have a language of their own.
> It's why filenames and URLs have a language of their own.
>
> Second, people are not islands unto themselves never talking to others.
> This is the age of mix and match, cut and paste, etc. People don't make
> things from scratch--they share them. And one barrier to sharing is the
> transformation of syntax. It's painful, and it introduces error. If
> someone shares a formula with you, it's nice to keep it in the form they
> gave you so (a) it's easier and less error-prone to drop in place,
> and (b) it's easily validated by someone who's primary skill is math, since
> it's in the language of math.
>
> Third, you're failing to acknowledge that Lisp has neatly crafted a
> separation between its surface reprsentation as text and its underlying
> representation as s-expression that makes it ideally able to support both
> notations with a minimum of impact on shared programs... very unlike other
> languages which can talk about one another only by writing parsers because
> they have no notion of what a parsed program tree would look like.
>
> Fourth, not all people value (and devalue) the same things in Lisp.
> Knowing someone likes Lisp is not a proof they like everything in it,
> any more than you can say that electing George Bush was a claim that
> everyone backed every one of his policies 100%. And so, not everyone
> who likes Lisp likes it because of how it makes you write math.
>
> Historically, btw, Interlisp, long ago, had infix math built in. I
> think it used DWIM to figure out when you were doing it--I'm not sure
> i was specially notated when you were doing it and when not.
> Symbolics Lisp had it, too; but the characters it used were special
> characters not in the ASCII set. Sharpsign Altmode (which looked kind
> of like a diamond, and which appeared on the Symbolics keyboard as
> Shift-Symbol-Escape) up to the next Altmode was parsed infix. MACLISP
> had CGOL, written by Vaughan Pratt, which offered a full infix version
> of the MACLISP language. It's a recurring theme, the wanting of infix
> in Lisp. It's not for everyone. But it does not brand you an outsider
> and is not something you're required to give up as part of the price
> of inclusion.
>
> Early Dylan, when it was still being defined at Apple, was probably
> the best job of an infix Lisp, because it actually operated in dual
> mode. (I think Dylan went rapidly downhill when it decided it could go
> all the way in infix alone. The mindset that resulted from saying it
> was ok, and even desirable, to sacrifice the Lisp community in the
> hopes that it would endear them to the C++ crowd was not one that led
> toward a good place.)
Btw., thanks for all your interesting postings recently here on
comp.lang.lisp .
--
http://lispm.dyndns.org
On 8 Apr, 04:19, "Tamas" <······@gmail.com> wrote:
> I don't think that anybody questions the usefulness of infix notation
> in general. It is certainly great for science and math, even though
> most of the time the precise notation is not completely defined, but
> context helps people cope with that.
I don't think it's fair to attach the "ambiguity" label to the infix
notation per se. If you use a fully parenthesised infix notation, it's
as correct as prefix: "(2 + (4 * 5))" is as unambiguous as "(+ 2 (* 4
5))".
Neither notation is restricted to binary operators: "(2 + (4 * 5) +
7)"
is the same as "(+ 2 (* 4 5) 7)". The repetition of "+" can be
condired a weakness, but actually improves the readability of math
expressions, which is what infix is for [see my previous post].
Writing different symbols by mistake, as in "(2 + 3 - 5)", can be
easily
caught by the compiler.
All the ambiguity blame infix gets is because it tends to be used in a
non-fully-parenthesised form, with operator precedence rules "2+3*4".
Criticizing a notation for being hackable (the safety vs. length
trade-off is choosable by the user) is not very lispy imho.
I think most people would agree that both infix and prefix notations
have areas of superiority. The problem is to make them work together
in the same language: allowing the user to express the same in two
ways necessarily bloats the code. The textual and mental cost of
switching notation in lisp is usually high enough to stick to prefix
even with simple math expressions. (But I'd really welcome somebody
prove me wrong in this case.)
Piotr
"Piotr" <···············@gmail.com> writes:
> On 8 Apr, 04:19, "Tamas" <······@gmail.com> wrote:
>> I don't think that anybody questions the usefulness of infix notation
>> in general. It is certainly great for science and math, even though
>> most of the time the precise notation is not completely defined, but
>> context helps people cope with that.
>
> I don't think it's fair to attach the "ambiguity" label to the infix
> notation per se. If you use a fully parenthesised infix notation, it's
> as correct as prefix: "(2 + (4 * 5))" is as unambiguous as "(+ 2 (* 4
> 5))".
> Neither notation is restricted to binary operators: "(2 + (4 * 5) +
> 7)"
> is the same as "(+ 2 (* 4 5) 7)". The repetition of "+" can be
> condired a weakness, but actually improves the readability of math
> expressions, which is what infix is for [see my previous post].
> Writing different symbols by mistake, as in "(2 + 3 - 5)", can be
> easily
> caught by the compiler.
No, you don't write x f y f z for f(x,y,z).
x + y + z is a shorthand for either (x + y) + z or x + (y + z) since
we're lucky here to have an associative operation.
Note that in computers, + is NOT associative, in general.
If (x + y) overflows (the memory or the register size, depending on
the language), while x + (y + z) doesn't, the meaning in a computer
of x + y + z becomes ambiguous. (And note that CLHS doesn't specify
the order in which the sums are computed by CL:+).
Once again, mathematicians get by using ambiguous notations because
their audience is other mathematicans you can resolve the ambiguities
meaningfully.
--
__Pascal Bourguignon__
http://www.informatimago.com
http://pjb.ogamita.org
On 9 Apr, 10:13, Pascal Bourguignon <····@informatimago.com> wrote:
> No, you don't write x f y f z for f(x,y,z).
No, you don't, but you can. The only point I wanted to make is that
fully parenthesised infix is capable of handling non-binary operators
in an unambiguous (although maybe weird-looking) way. I'm not
suggesting anybody should use this notation.
> x + y + z is a shorthand for either (x + y) + z or x + (y + z) since
> we're lucky here to have an associative operation.
>
> Note that in computers, + is NOT associative, in general.
>
> If (x + y) overflows (the memory or the register size, depending on
> the language), while x + (y + z) doesn't, the meaning in a computer
> of x + y + z becomes ambiguous. (And note that CLHS doesn't specify
> the order in which the sums are computed by CL:+).
That's exactly why I insisted on interpreting x+y+z as a single
function invocation (+ x y z), not as (x+y)+z or x+(y+z). Again, this
is very non-standard, so probably we should stick to binary
operators in infix.
Piotr
From: Richard M Kreuter
Subject: Re: Any macro for inserting math "normally"
Date:
Message-ID: <87ejmtttf9.fsf@progn.net>
Pascal Bourguignon <···@informatimago.com> writes:
> No, you don't write x f y f z for f(x,y,z).
Yes, but see how much clearer programs would be if all non-unary
operators were infix in this way...
(defun prefixify-expression (expression)
(if (consp expression)
(if (< (length expression) 3)
(mapcar 'prefixify-expression expression)
(loop
with operator = (second expression)
for (arg . rest) on expression by #'cddr
collect (prefixify-expression arg) into args
if (or (null rest) (not (eql (first rest) operator)))
return (return (cons operator args))))
expression))
(defmacro infix-eval (expr)
`(eval ,(prefixify-expression expr)))
(defmacro while (var form &body body)
`(do ((,var ,form ,form))
((null ,var))
,@body))
(defmacro bind (var form &body body)
`(let ((,var ,form))
,@body))
(infix-eval
(stream bind (open "/etc/passwd") bind
((line while (stream read-line nil) while
(name bind (line subseq 0 subseq (#\: position line)) bind
(shell bind
(line
subseq (1+ (#\: position line
position :from-end
position t)))
bind
(t format "User: ~A~%Shell: ~A~%~%"
format name
format shell))))
unwind-protect
(close stream))))
Clearly an improvement over those unreadable prefix expressions.
--
RmK
On Apr 10, 12:16 am, Richard M Kreuter <·······@progn.net> wrote:
> Pascal Bourguignon <····@informatimago.com> writes:
> > No, you don't write x f y f z for f(x,y,z).
>
> Yes, but see how much clearer programs would be if all non-unary
> operators were infix in this way...
<snip>
> (infix-eval
> (stream bind (open "/etc/passwd") bind
> ((line while (stream read-line nil) while
> (name bind (line subseq 0 subseq (#\: position line)) bind
> (shell bind
> (line
> subseq (1+ (#\: position line
> position :from-end
> position t)))
> bind
> (t format "User: ~A~%Shell: ~A~%~%"
> format name
> format shell))))
> unwind-protect
> (close stream))))
>
> Clearly an improvement over those unreadable prefix expressions.
>
This is what is called a Straw Man argument. You show a particularly
stupid example of the argument, show that it is obviously stupid,
therefore the argument is stupid, QED.
Personally, my argument for infix is to PUT IT IN MODERATION. For
simple maths like foo + bar * nitz, infix rules. Translating that
into prefix notation takes more thought-cycles than I care to put in.
This is why my infix macro does *not* stupidly expect all forms within
it to be infix. It analyzes the code to check which forms have an
operator at the second position, and only translates those forms from
infix to prefix.
The argument is this:
1. Most of the easily found and understood descriptions of
practical algorithms are targeted to C and similar infixed languages.
Often, the infix notation is used for mathematical computations.
2. Translating infix notation to prefix notation takes some time
for most Lisp newbies.
3. The translation from infix notation to prefix notation, as shown
by RmK, is trivially programmable by an expert.
THEREFORE:
4. For an expert to help newbies, the expert can write a simple
tool/macro to translate infix to prefix from within the program code.
QED
Notes:
Note the qualification "easily found and understood". Yes, I know
there are algorithm descriptions that use sigma and pi-notation, which
are prefix. They're not as easy to find and understand as "a1 + a2 +
a3 ..." for most people.
On Tue, 10 Apr 2007 05:01:13 +0200, Alan Manuel K. Gloria
<········@gmail.com> wrote:
>
> The argument is this:
> 1. Most of the easily found and understood descriptions of
> practical algorithms are targeted to C and similar infixed languages.
> Often, the infix notation is used for mathematical computations.
> 2. Translating infix notation to prefix notation takes some time
> for most Lisp newbies.
> 3. The translation from infix notation to prefix notation, as shown
> by RmK, is trivially programmable by an expert.
> THEREFORE:
> 4. For an expert to help newbies, the expert can write a simple
> tool/macro to translate infix to prefix from within the program code.
> QED
>
> Notes:
> Note the qualification "easily found and understood". Yes, I know
> there are algorithm descriptions that use sigma and pi-notation, which
> are prefix. They're not as easy to find and understand as "a1 + a2 +
> a3 ..." for most people.
>
>
So use (infix->prefix "expression") to translate it.
Then paste the result in. Thus the newbie learns how it should look
and the resulting code is pure Lisp..
http://folk.uio.no/jornv/infpre/infpre.html
(It took me 10 seconds to google this one up)
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
"John Thingstad" <··············@chello.no> writes:
> So use (infix->prefix "expression") to translate it.
> Then paste the result in. Thus the newbie learns how it should look
> and the resulting code is pure Lisp..
> http://folk.uio.no/jornv/infpre/infpre.html
> (It took me 10 seconds to google this one up)
Sorry, but this is far from being a replacement to Mark Kantrowitz' code
(and, unfortunately, neither is Frank's infix version). There is a reason
for Kantrowitz' code being much more involved.
E.g., Kantrowitz code handles expressions like "2+3*4/5^x", "1.5e2*10 +
cos(x)", "f(x,y)", "a[i,j,k]" and many more.
Nicolas
From: Richard M Kreuter
Subject: Re: Any macro for inserting math "normally"
Date:
Message-ID: <877isktgzk.fsf@progn.net>
"Alan Manuel K. Gloria" <········@gmail.com> writes:
> On Apr 10, 12:16 am, Richard M Kreuter <·······@progn.net> wrote:
>> Pascal Bourguignon <····@informatimago.com> writes:
>> > No, you don't write x f y f z for f(x,y,z).
>>
>> Yes, but see how much clearer programs would be if all non-unary
>> operators were infix in this way...
<snip>
> This is what is called a Straw Man argument.
No it isn't. An argument is a connected series of statements intended
to establish a proposition. That article was a mere contradiction,
i.e., simply the automatic gainsaying of what the previous article had
said, not an argument.
--
RmK
On Apr 8, 5:19 am, "Tamas" <······@gmail.com> wrote:
> Hi Juan,
>
> I don't think that anybody questions the usefulness of infix notation
> in general. It is certainly great for science and math, even though
> most of the time the precise notation is not completely defined, but
> context helps people cope with that. For example, if you check the
> Comprehensive LaTeX Symbol List, you will see zillions of symbols,
> most of them with multiple meanings in different fields, precedence
> rules are certainly not defined for all of them etc. But that's OK:
> most science and math papers provide the context where users can
> figure it out. Only most. Recently I have seen a paper where the
> author thought it would be clever to use ab/cd for (ab)/(cd), and it
> took me quite a bit of frustration to figure out what he meant (it is
> not usual for people to use this notation in economics). Or, in
> probability theory, some people like to use the expectations operator
> without parentheses, and the precedence is often unclear: is Efg=E(fg)
> or fEg? People write the latter to avoid the ambiguity. but again,
> with more complicated formulas it is not so obvious what to do. Some
> measure theory books get into the "I'm gonna clean up the notation
> once and for all" mindset, and a few even manage to do this
> consistently _inside the book_ (where they only have to deal with a
> subset of math) but cease to be applicable outside it.
Hi,
I think that one would not mix concepts of infix with those of
precedence and grouping. The LISP (* (+ 2 8) 3) is infix [[2 + 8] * 3]
whereas being (2 + 8 * 3) for a language with L2R precedence rules.
> When we program computers, it is up to the machine to interpret the
> code so it can't figure out what the notation means by using context.
> Of course it is perfectly possible to define unambiguous infix
> notation, the trouble is, that with many symbols one has to remember
> the rules are.
No trouble when the syntax is infix without using precedence rules (or
using only those you predefined and are familiar with).
> Personally, when I program C, I just follow the advice
> of Practical C Programming by Steve Oualline: remember that * binds
> tighter than +, and use parentheses for everything else. And I really
> hate it when people rely on precedence for anything else, because I
> have to look it up, I just simply can't make myself memorize the
> rules. The alternative is using a lot of parentheses, but then I
> would prefer my parentheses to be intelligible at a glance. Lisp
> helps with that (C-M-q rocks ;-).
About parentheses, an infix notation can help to reduce needed number
of parentheses a lot of under certain circumstances. This could be
used for avoiding one of common criticism to LISP/Scheme.
In knowledge representation, one gets a reduction from 10 to 4
brackets using infix for a very common formal construct on science and
engineering:
[[A B / A D] = C B]
(= (/ (A B) (A D)) (C B))
Notice that the optimisation on number of parentheses (LISP needs more
than double) is based in topological properties of the infix position.
No precedence rules or assumptions were used!
Of course, if you like precedence you could define your own syntax
with precedence rules you like. Some people would like something as
A B / A D = C B
Others would hate it!
For stuff like (+ 2 (- 5 4)) there is no gain: [2 + [5 - 4]].
On 7 Apr 2007 04:27:37 -0700, "Juan R."
<··············@canonicalscience.com> wrote:
>
>I know of mathematicians writting programs and they make no mistakes.
>In fact, i know of mathematicians who generated algorithms with no
>counterpart on LISP community.
>
Really? In 25 years, I haven't met a single individual who can write
a non-trivial program with "no mistakes". You must know some truly
exceptional people.
George
--
for email reply remove "/" from address
On Apr 8, 9:04 am, George Neuner <·········@comcast.net> wrote:
> On 7 Apr 2007 04:27:37 -0700, "Juan R."
>
> <··············@canonicalscience.com> wrote:
>
> >I know of mathematicians writting programs and they make no mistakes.
> >In fact, i know of mathematicians who generated algorithms with no
> >counterpart on LISP community.
>
> Really?
I did not mean they make none mistake. I did mean programs written by
those mathematicians are not wrong (they contain no mistakes) in the
sense of precedence rules and non-lispy syntax of the previous message
by Andy Freeman when he said, "When mathematicians write for
computers, they make precedence errors".
I.e. my reply to Freeman would have been "I know of mathematicians
writing programs and they make no precedence mistakes".
> In 25 years, I haven't met a single individual who can write
> a non-trivial program with "no mistakes". You must know some truly
> exceptional people.
Once I have explained my point, let me add that some of mathematicians
I had in my mind, when replying to the other poster, got a Nobel Prize
by works on computation. I do not know if you consider Nobel winners
exceptional enough people.
On 14 Apr 2007 04:41:09 -0700, "Juan R."
<··············@canonicalscience.com> wrote:
>On Apr 8, 9:04 am, George Neuner <·········@comcast.net> wrote:
>> On 7 Apr 2007 04:27:37 -0700, "Juan R."
>>
>> <··············@canonicalscience.com> wrote:
>>
>> >I know of mathematicians writting programs and they make no mistakes.
>> >In fact, i know of mathematicians who generated algorithms with no
>> >counterpart on LISP community.
>>
>> Really?
>
>I did not mean they make none mistake. I did mean programs written by
>those mathematicians are not wrong (they contain no mistakes) in the
>sense of precedence rules and non-lispy syntax of the previous message
>by Andy Freeman when he said, "When mathematicians write for
>computers, they make precedence errors".
>
>I.e. my reply to Freeman would have been "I know of mathematicians
>writing programs and they make no precedence mistakes".
Every practical program diverges in some way from its specification
and therefore every program contains at least one bug. Programs
written by mathematicians are not excepted.
It may be that mathematicians are more likely to be aware of
arithmetic precedence - but I doubt that gives them any edge when
programming because most languages have additional precedence rules
which have no counterpart in mathematics.
>> In 25 years, I haven't met a single individual who can write
>> a non-trivial program with "no mistakes". You must know some truly
>> exceptional people.
>
>Once I have explained my point, let me add that some of mathematicians
>I had in my mind, when replying to the other poster, got a Nobel Prize
>by works on computation. I do not know if you consider Nobel winners
>exceptional enough people.
I am not particularly impressed by prizes - most are politically
motivated rather than merit based. I've met geniuses that need a
servant to dress them and tie their shoes. I've also met excellent
programmers who make no claim to genius but nonetheless produce
extraordinary programs through care and diligence.
George
--
for email reply remove "/" from address
On Apr 15, 12:21 am, George Neuner <·········@comcast.net> wrote:
> >I did not mean they make none mistake. I did mean programs written by
> >those mathematicians are not wrong (they contain no mistakes) in the
> >sense of precedence rules and non-lispy syntax of the previous message
> >by Andy Freeman when he said, "When mathematicians write for
> >computers, they make precedence errors".
>
> >I.e. my reply to Freeman would have been "I know of mathematicians
> >writing programs and they make no precedence mistakes".
>
> Every practical program diverges in some way from its specification
> and therefore every program contains at least one bug. Programs
> written by mathematicians are not excepted.
Again, Freeman said "When mathematicians write for computers, they
make precedence errors". That is not true, in general.
There exist mathematicians writting programs without using LISP syntax
and they are not doing precedence errors as a general rule: computers
evaluate the program perfectly (which, again, no implies program was
error-free or cannot be improved).
On Apr 15, 12:21 am, George Neuner <·········@comcast.net> wrote:
>
> >I.e. my reply to Freeman would have been "I know of mathematicians
> >writing programs and they make no precedence mistakes".
>
> Every practical program diverges in some way from its specification
> and therefore every program contains at least one bug. Programs
> written by mathematicians are not excepted.
Again, I was replying to Freeman's when said that mathematicians were
doing precedence mistakes. I know programs without those precedence
mistakes, which does not imply programs are bug-free or cannot be
improved.
On Apr 14, 4:41 am, "Juan R." <··············@canonicalscience.com>
wrote:
> I.e. my reply to Freeman would have been "I know of mathematicians
> writing programs and they make no precedence mistakes".
That is an extraordinary claim. How about something approximating
supporting evidence? (It turns out that I've worked on programs
written
by a Nobel prize winner who deserved it.)
Is it a claim about the majority of mathematicians or that there exist
mathematicians for which it is true? (I know a programmer who doesn't
seem to make precedence mistakes, but he's so far off the charts in
enough ways that it is absurd to design anything with him in mind.)
And, is it a claim about the final version of their programs or the
initial version and all intermediates? It is possible to end up
with a program that doesn't contain precedence mistakes. But, if it
costs more to get there than the savings from using precedence,
as I claim that it does, using precedence is a mistake.
On Apr 16, 6:59 pm, "Andy Freeman" <······@earthlink.net> wrote:
> On Apr 14, 4:41 am, "Juan R." <··············@canonicalscience.com>
> wrote:
>
> > I.e. my reply to Freeman would have been "I know of mathematicians
> > writing programs and they make no precedence mistakes".
>
> That is an extraordinary claim.
No, it is very ordinary one. An example of very extraordinary claims
are your
> Mathematicians write for other mathematicians. They don't have to get
> it correct because readers make the same mistakes.
and
> When mathematicians write for computers, they make precedence errors.
> If that's acceptable to you, feel free to use an input format that
> uses
As remarked before, it is not true that _any_ mathematician was doing
precedence errors and it is not true that _any_ reader is doing them.
Of course, can exist specific cases where precedence mistakes are
done, but I said nothing about that.
> How about something approximating
> supporting evidence?
Do you mean kind of evidence you provided for your absolute remarks?
If not, then take algorithms published in scientific journals. does
any mathematician non-LISP program contain mistakes?
> Is it a claim about the majority of mathematicians or that there exist
> mathematicians for which it is true?
Latter, was mayority, minority, or other.
> And, is it a claim about the final version of their programs or the
> initial version and all intermediates? It is possible to end up
> with a program that doesn't contain precedence mistakes.
Ah, now the possibility mathematicians can write programs without
precedence mistakes turned real.
> But, if it
> costs more to get there than the savings from using precedence,
> as I claim that it does, using precedence is a mistake.
Left that to be decided by the programmer.
On Apr 21, 4:47 am, "Juan R." <··············@canonicalscience.com>
wrote:
> On Apr 16, 6:59 pm, "Andy Freeman" <······@earthlink.net> wrote:
> If not, then take algorithms published in scientific journals. does
> any mathematician non-LISP program contain mistakes?
Most journals of algorithms have an errata section. Moreover, such
programs are a "final" result. They didn't start out correct.
> > And, is it a claim about the final version of their programs or the
> > initial version and all intermediates? It is possible to end up
> > with a program that doesn't contain precedence mistakes.
>
> Ah, now the possibility mathematicians can write programs without
> precedence mistakes turned real.
Not in a form that supports the argument.
There are expressions that don't contain precedence mistakes.
However, an untested and/or unverified set of expressions written by
humans is likely to have precedence mistakes.
If you're cut&paste from things that have not been mechanically
tested, you're likely to run into such mistakes. If you're cut&paste
from things that were were not mechanically tested that were written
with a different precedence scheme or from programs that have a
different precedence scheme than the one that you're using to
interpret them, you will run into precedence mistakes. (If precedence
is so natural, why isn't there universal agreement?)
Cost always matters. Mistakes, and eliminating them, cost something.
If you feel that the benefits of using precedence exceeds the costs of
the mistakes that precedence allows, go for it.
On Apr 23, 5:20 pm, Andy Freeman <······@earthlink.net> wrote:
> On Apr 21, 4:47 am, "Juan R." <··············@canonicalscience.com>
> wrote:
>
> > On Apr 16, 6:59 pm, "Andy Freeman" <······@earthlink.net> wrote:
> > If not, then take algorithms published in scientific journals. does
> > any mathematician non-LISP program contain mistakes?
>
> Most journals of algorithms have an errata section. Moreover, such
> programs are a "final" result. They didn't start out correct.
Nothing of this supports your previous claim about _any_ mathematician
or reader _doing_ precedence mistakes.
And again your "They didn't start out correct" is a too general
statement i do not accept.
> There are expressions that don't contain precedence mistakes.
> However, an untested and/or unverified set of expressions written by
> humans is likely to have precedence mistakes.
That argument can be inverted against LISP fully parenthesised syntax.
"However, an untested and/or unverified set of S-expressions written
by humans is likely to have matching brackets mistakes, specially for
deep levels of nesting ))))))))))))))."
Yes, a LISP aware editor can warn you from missed ")" but I think that
does not LISP prefix syntax so _superior_ that anyone was using it,
no?
> If you're cut&paste from things that have not been mechanically
> tested, you're likely to run into such mistakes. If you're cut&paste
> from things that were were not mechanically tested that were written
> with a different precedence scheme or from programs that have a
> different precedence scheme than the one that you're using to
> interpret them, you will run into precedence mistakes. (If precedence
> is so natural, why isn't there universal agreement?)
Where did I say precedence was natural?
And, is there universal agreement in the S-expr world?
> Cost always matters. Mistakes, and eliminating them, cost something.
> If you feel that the benefits of using precedence exceeds the costs of
> the mistakes that precedence allows, go for it.
I am not a fan of precedence and I, personally, prefer fully
parenthesised syntax but will less parentheses.
That is different from 'obligating' anyone to use a syntax of that
kind. I see natural someone prefer to write E = m * c ^ 2 whereas
others prefer [E = [m * [c ^ 2]]], whereas other like (= E (* m (^ c
2))).
Contrary to certain LISP gurus I prefer inform people of advantages
disadvantages of each one letting them to choose they prefer in basis
to personal preferences and kind of problems they work.
My personal preference, by order is
[E = [m * [c ^ 2]]]
E = m * c ^ 2
(= E (* m (^ c 2))).
Many people agree in this order and even wait some people to prefer
something like E=m*c^2 (e.g. TeX users).
Something I learn during development of CanonML is that you cannot do
a syntax for everyone; therefore, I focused in a syntax for 'machine'
and leave anyone to choose the syntax [s]he want.
From: Kent M Pitman
Subject: Re: Any macro for inserting math "normally"
Date:
Message-ID: <uslak8ldx.fsf@nhplace.com>
"Juan R." <··············@canonicalscience.com> writes:
> On Apr 23, 5:20 pm, Andy Freeman <······@earthlink.net> wrote:
> > On Apr 21, 4:47 am, "Juan R." <··············@canonicalscience.com>
> > wrote:
> >
> > > On Apr 16, 6:59 pm, "Andy Freeman" <······@earthlink.net> wrote:
> > > If not, then take algorithms published in scientific journals. does
> > > any mathematician non-LISP program contain mistakes?
> >
> > Most journals of algorithms have an errata section. Moreover, such
> > programs are a "final" result. They didn't start out correct.
>
> Nothing of this supports your previous claim about _any_ mathematician
> or reader _doing_ precedence mistakes.
>
> And again your "They didn't start out correct" is a too general
> statement i do not accept.
It think he thinks it's so obvious as to require no proof.
Consider that at least some of math is spoken aloud from one person
to another. I say to someone these words:
DID YOU KNOW THAT X PLUS ONE SQUARED EQUALS X SQUARED PLUS TWO X PLUS ONE?
I have never in my life heard anyone say:
DID YOU KNOW THAT OPEN-PAREN X PLUS ONE CLOSE-PAREN SQUARED EQUALS
X SQUARED PLUS TWO X PLUS ONE?
As a consequence of the omitted parens, one must infer them. This means
that new and surprising information can never be transmitted reliably
in audio because it requires either a baroque form of speaking or else
a knowledge in advance of the truth of what you expect to hear in order
to resolve the parens. The following are possible interpretations of the
first if you don't know the truth of the matter and you just infer parens
by guesswork:
x+1^2=x^2+2*x+1
(x+1)^2=x^2+2*x+1
x+1^2=x^2+2*(x+1)
I think it's as unsupportable claim that people never speak these things
aloud. I can tell you that when I discovered this truth empirically in
8th grade by finding patterns in numbers and I went excitedly to my teacher
to tell her that "I had learned that if know the square of x, I can predict
the that it will be 2x+1 [already an opportunity for misunderstanding, she
could have heard 2*(x+1)]" she replied [in audio], not understanding my
excitement after weeks of work, "Oh, that's just a special case of
a plus b squared equals a squared plus 2 a b plus b squared." I can tell
you I had never seen that relation before, and while I memorized it and
later had to reconstruct it, it was at risk of being mistransmitted.
(It took me still even longer because I didn't initially see the relation
because I'd worked it out for known values and I wasn't sure what the
geometric interpretation of the b was for a while...)
My point is not that I was a skilled mathematician then, nor perhaps
even now. My point is that people definitely do say formulas back and
forth out loud. And my further point is that it is definitely not
always clear what they are saying. And further point still is that
precedence issues are responsible.
It's also completely clear that since the precedence rules differ from
accountant's calculators to TI calculators, there is an opportunity to
misunderstand what rules are in play, even among experienced users. And
this must also cause problems.
And some infix languages allow you to change precedence dynamically.
Vaughan Pratt's CGOL allowed you to do this, and (since I worked down
the hall from him back then), I asked him about what would happen if
people DID do this. He admitted it would make the language nearly
unintelligible and that he hoped no one would do that on the
predefined operators because it would make it ultra hard to read. He
admitted the feature was good for language extension but should
probably be used sparingly. But surely it must follow from the
possibility of such confusion that it happens, given a statistically
large sample, and the fact that people are not exactly known for
perfect communication. (Nearly all sitcoms are based on the routine
misunderstanding of people's intent, poor communication skils, etc. I
don't assume mathematicians to be immune.)
Ambiguity of notation is also an issue. Some people don't want
big-sigma (summation sign) to have parens after it, and yet it's hard
to add one to the result of such a thing without it. So I suspect
some people think SUM x^2 + 1 means that the SUM is tightly bound to
x^2 and some thing it spans the +1. Maybe I'm wrong that this is
always resolved uniformly, but I bet not. (Unlike integrals, there is
no bracketing dx at the end to tell you you're done.) Product signs
with big-PI have the same problem.
It's hard to tell the difference visually between a right-subscript
and a left superscript, too, absent baselines.
A
A look a lot like B if you don't see the baseline.
B
This is not a binding power issue, but it is an issue where
(LEFT-SUPERSCRIPT B A) and (RIGHT-SUBSCRIPT A B) are unambiguous
and are an objectively superior notation for avoiding confusion.
And there are people who are commercial proofreaders, and yet
publications of all kinds still get printed with typos. I type homonym
typos all the time, because my brain hears what I want to type and
retypes it. I don't speak parens out loud when I think, so when I read
algebraic text, I'm open to making errors that can, if traced back, be
due to precedence, since [I allege] soudalikes are high-probability
typos, and since I've demonstrated above that soundalikes create an
equivalence class that spans semnatically different elements.
So the more outlandish claim, that no person ever makes this error, is
the one in seeming need of support. I take it as given that the
default situation is that the error does happen.
> > There are expressions that don't contain precedence mistakes.
> > However, an untested and/or unverified set of expressions written by
> > humans is likely to have precedence mistakes.
>
> That argument can be inverted against LISP fully parenthesised syntax.
I'm open to hear such an argument, just for fun.
I'm not saying Lisp code is error free. Far from it.
I'm just curious how Lisp has precedence mistakes.
I'm not saying Lisp is objectively better. I'm saying that this is a
conscious trade-off to end a certain class of errors, and it comes with
conscious cost (more parens, placed differently). But I'm also observing
that the "cost" comes with helpful ability to have tools (flashing parens,
auto-indentation) that help you to know whether you've got the balance
right...
Lisp's notation is less concise, but we choose that notation as ultimately
a good trade, and I don't think we deny it.
> "However, an untested and/or unverified set of S-expressions written
> by humans is likely to have matching brackets mistakes, specially for
> deep levels of nesting ))))))))))))))."
Not with good automatic tools. I understand they used to see this
back in the 1960's before good text editors came along. Even TECO,
which was not display based, had paren balancing tools and tools for
hopping over balanced sets. I saw some amazing code written with a
TECO editor (for MACSYMA) that never had a line break. TECO-based
Emacs already had flashing parens and indentation control early on, in
the 1970's. Paren errors are quite uncommon with good tools. Of
course, one can always exist on teaching Lisp with bad tools. I'm not
sure what the shows, though.
> Yes, a LISP aware editor can warn you from missed ")" but I think that
> does not LISP prefix syntax so _superior_ that anyone was using it,
> no?
I think there is one more missing or misplaced word here than I can
work through, so I don't know what point you meant to make here.
> > If you're cut&paste from things that have not been mechanically
> > tested, you're likely to run into such mistakes. If you're cut&paste
> > from things that were were not mechanically tested that were written
> > with a different precedence scheme or from programs that have a
> > different precedence scheme than the one that you're using to
> > interpret them, you will run into precedence mistakes. (If precedence
> > is so natural, why isn't there universal agreement?)
>
> Where did I say precedence was natural?
>
> And, is there universal agreement in the S-expr world?
I think the point Andy was trying to make is that the internal
representation was suitably canonical
> > Cost always matters. Mistakes, and eliminating them, cost something.
> > If you feel that the benefits of using precedence exceeds the costs of
> > the mistakes that precedence allows, go for it.
>
> I am not a fan of precedence and I, personally, prefer fully
> parenthesised syntax but will less parentheses.
>
> That is different from 'obligating' anyone to use a syntax of that
> kind. I see natural someone prefer to write E = m * c ^ 2 whereas
> others prefer [E = [m * [c ^ 2]]], whereas other like (= E (* m (^ c
> 2))).
If you do what you suggest, which is a legitimate thing to want, you
need to:
* Know that you can no longer have help from the many emacs commands
that do "forward expression" since now you have to have a "forward
sum", "forward product", "forwad exponentiation", "forward function
call", etc. You also need to further undersatnd that to jump over
f( a + b * c ) + x + y
and end up after the x, you can't just do some command twice, but you
have to do "forward function call" followed by a different command,
requiring different keystrokes "forward sum". Or you can treat these
as just tokenss and then define that to get past to after the x, you
have to do c-u 1 0 m-f because all you have are word motion commands.
* Know that you will no longer be able to grab an expression from the
keyboard in emacs using control-meta-k and then drop it down elsewhere.
Instead, you'll have to take your fingers off the keys, drag with the
mouse, hope you've marked a bounded expression correctly (I do this
daily because I work with symbolic algebra code and I allege this is
a routine source of potential error for me--maybe you're better at it),
and then grab the expression with no syntactic error checking.
* Write parsers that would otherwise be unnecessary, or load them if
someone else has written them.
* Explain how Lisp knows when to apply one set of rules and not another.
(This can be explained, it's just extra burden. LOOP does it, for
example, but no one ever cites LOOP as an easy to understand syntax.)
> Contrary to certain LISP gurus I prefer inform people of advantages
> disadvantages of each one letting them to choose they prefer in basis
> to personal preferences and kind of problems they work.
>
> My personal preference, by order is
>
> [E = [m * [c ^ 2]]]
>
> E = m * c ^ 2
>
> (= E (* m (^ c 2))).
>
> Many people agree in this order and even wait some people to prefer
> something like E=m*c^2 (e.g. TeX users).
>
> Something I learn during development of CanonML is that you cannot do
> a syntax for everyone; therefore, I focused in a syntax for 'machine'
> and leave anyone to choose the syntax [s]he want.
Except that, since you mention ML, that language has a STRONG bias for
syntaxes that are symmetric, because dispatching is so hard for nary
operators. It tends to apply extreme pressure on people to believe that
+ and * are binary operations, rather than nary operations. This makes
it hard to write code manipulation algorithms that exploit associativity
and commutativity.
Maybe your experience is different than mine. But I battle against this
all the time, and I program routinely for work in a variant of ML
(that uses more of a Haskell syntax). I find it holds me back and risks
misleading people into confusing syntax issues with semantics issues
because of the tight interaction of syntax and semantics in parsed languages.
Your mileage may, of course, vary. I'm not saying you can't have
another point fo view. I'm just trying to establish that this is just
a reasoned choice and that the reasons are not silly. I'm not saying
other needs aren't there, I'm saying we chose to go for particular
values, and to tolerate alternate values any time we could. While
probably no language can tolerate all values equally, other languages
seem to me to go much less far in their attempt to tolerate and success
in tolerating alternate values.
In most other languages, there wouldn't even be the syntactic opportunity
to criticize the language or lobby for change. It would be like spouting
nonsense to suggest a change, since many other languages offer little more
THAN syntax. One is so tired once one gets done accommodating the syntax,
they don't add much meat on the language in terms of functionality... at
least by Lisp standards. Such is my feeling anyway. Other points of view
welcome.
For an interesting talk by Gerald Sussman on the ambiguity of
'standard mathematical notation', there is an amusing video from
Danfest2004 (http://www.cs.indiana.edu/dfried_celebration.html)
about calculus and mechanics, among other things. It was here
that I realised that Scheme has implicit currying when defining
functions -- (define ((sum x) y) ...)
http://video.google.com/videoplay?docid=-2726904509434151616&hl=en
(is case anyone missed it)
szergling <···············@gmail.com> wrote:
+---------------
| For an interesting talk by Gerald Sussman on the ambiguity of
| 'standard mathematical notation', there is an amusing video from
| Danfest2004 (http://www.cs.indiana.edu/dfried_celebration.html)
| about calculus and mechanics, among other things. It was here
| that I realised that Scheme has implicit currying when defining
| functions -- (define ((sum x) y) ...)
+---------------
Except that it doesn't, at least not any of the "standardized"
versions up through R6RS. In R6RS (and earlier), DEFINE has only
two forms, a "primitive" form:
(DEFINE var value) ; though VALUE may be a LAMBDA expr.
and a "convenience" form[1] defined in terms of the first [where
"FORMALS..." can be an improper list, the last symbol being a &REST
arg in the CL sense]:
(DEFINE (func formals...) body)
==> (DEFINE func (LAMBDA (formals...) body))
See <http://www.r6rs.org/document/html/r6rs-Z-H-12.html#node_sec_9.2>
I suspect Sussman may have been using his own personal
experimental/extended version of Scheme in that talk.
-Rob
[1] Well, plus one more variant of the "convenience" form
in the case of a single &REST arg:
(DEFINE (func . arg) body) ==> (DEFINE func (LAMBDA arg body))
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
On Apr 29, 4:11 pm, ····@rpw3.org (Rob Warnock) wrote:
...
> versions up through R6RS. In R6RS (and earlier), DEFINE has only
> two forms, a "primitive" form:
>
> (DEFINE var value) ; though VALUE may be a LAMBDA expr.
>
> and a "convenience" form[1] defined in terms of the first [where
> "FORMALS..." can be an improper list, the last symbol being a &REST
> arg in the CL sense]:
>
> (DEFINE (func formals...) body)
> ==> (DEFINE func (LAMBDA (formals...) body))
>
> See <http://www.r6rs.org/document/html/r6rs-Z-H-12.html#node_sec_9.2>
>
> I suspect Sussman may have been using his own personal
> experimental/extended version of Scheme in that talk.
>
Right. He doesn't need an experimental/extended Scheme though, quite a
few vanilla Schemes seem to have it (though I have never seen code
written that way). I initially tested it on a Scheme (probably
mzscheme and elk), and when it worked, I didn't check the standard
(what little Scheme code I write, I don't even try to make portable,
so I tended to ignore RnRS standards... no disrespect to the Scheme
standard, but it is no CommonLisp).
szergling <···············@gmail.com> wrote:
+---------------
| ····@rpw3.org (Rob Warnock) wrote:
| > I suspect Sussman may have been using his own personal
| > experimental/extended version of Scheme in that talk.
|
| Right. He doesn't need an experimental/extended Scheme though, quite a
| few vanilla Schemes seem to have it (though I have never seen code
| written that way). I initially tested it on a Scheme (probably
| mzscheme and elk), and when it worked, I didn't check the standard...
+---------------
Uh... AFAIK, MzScheme never supported "structured" LAMBDAs or
DEFINEs, e.g.:
mz> (define ((foo x) y)
(+ x y))
define: bad identifier at: (foo x) in: (define ((foo x) y) (+ x y))
mz>
But even a very old Elk-3.0 seems to:
elk> (define ((foo x) y)
(+ x y))
foo
elk> (foo 37)
#[compound value]
elk> ((foo 37) 3)
40
elk>
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
On Apr 28, 7:22 pm, Kent M Pitman <······@nhplace.com> wrote:
> It think he thinks it's so obvious as to require no proof.
D'alembert considered _then_ so obvious Newton was wrong as to require
no proof...
> Consider that at least some of math is spoken aloud from one person
> to another. I say to someone these words:
>
> DID YOU KNOW THAT X PLUS ONE SQUARED EQUALS X
> SQUARED PLUS TWO X PLUS ONE?
>
> I have never in my life heard anyone say:
>
> DID YOU KNOW THAT OPEN-PAREN X PLUS ONE CLOSE-PAREN
> SQUARED EQUALS X SQUARED PLUS TWO X PLUS ONE?
>
> As a consequence of the omitted parens, one must infer them. This means
> that new and surprising information can never be transmitted reliably
> in audio because it requires either a baroque form of speaking or else
> a knowledge in advance of the truth of what you expect to hear in order
> to resolve the parens.
I do not agree. Information can be still transmitted. It is only when
that information may be processed that the processor (human or not)
may contain information enough about the syntax and codification used
or even about semantics associated if the processor may extract
meanings from it.
But were not my remarks. My remarks in this thread were an extensible
unambiguous language does _not_ need to be prefix. Which, of course,
does not imply you could not work in a prefix way if you desire.
> The following are possible interpretations of the
> first if you don't know the truth of the matter and you just infer parens
> by guesswork:
>
> x+1^2=x^2+2*x+1
> (x+1)^2=x^2+2*x+1
> x+1^2=x^2+2*(x+1)
I am doing an effort and I did not remember any classroom with
problems about precedence when teacher spoken maths. Yes, maybe in one
or two occasions some formula could be ambiguous and disambiguation
was needed but not _any_ formulae.
Also once again, one would not confound 'arithmetic' syntax with infix
syntax.
About your spoken math, people I know uses pauses, e.g:
DID YOU KNOW THAT [pause] X PLUS ONE [pause] SQUARED...
I know a bit the topic of spoken math, specially related to
accessibility of math online. My knowledge is minimal but I never read
a paper or tutorial recommending a LISP prefix style for spoken math.
For example I never heard something like lispy:
OPEN-PAREN EQUALS OPEN-PAREN SQUARED OPEN-PAREN PLUS X ONE CLOSE-PAREN
CLOSE-PAREN OPEN-PAREN PLUS OPEN-PAREN SQUARED X CLOSE-PAREN OPEN-
PAREN TIMES TWO X CLOSE-PAREN ONE CLOSE-PAREN
It appears that, also in spoken math, the prefix notation is _not good
enough_ to grasp more attention from the World.
> It's also completely clear that since the precedence rules differ from
> accountant's calculators to TI calculators, there is an opportunity to
> misunderstand what rules are in play, even among experienced users. And
> this must also cause problems.
No really. That can be solved or almost solved via profiling.
> Ambiguity of notation is also an issue.
I would remark again precedence and infix are two different topics
would be not mixed during discussion.
> Some people don't want
> big-sigma (summation sign) to have parens after it, and yet it's hard
> to add one to the result of such a thing without it. So I suspect
> some people think SUM x^2 + 1 means that the SUM is tightly bound to
> x^2 and some thing it spans the +1. Maybe I'm wrong that this is
> always resolved uniformly, but I bet not. (Unlike integrals, there is
> no bracketing dx at the end to tell you you're done.) Product signs
> with big-PI have the same problem.
Maybe you are right. I do not remember me reading a scientific paper
and asking where finishes a sum or a product.
> So the more outlandish claim, that no person ever makes this error, is
> the one in seeming need of support. I take it as given that the
> default situation is that the error does happen.
Hum, some confusion here. I never said, nor even suggested, that no
people makes mistakes.
> > > However, an untested and/or unverified set of expressions written by
> > > humans is likely to have precedence mistakes.
>
> > That argument can be inverted against LISP fully parenthesised syntax.
>
> I'm open to hear such an argument, just for fun.
>
> I'm not saying Lisp code is error free. Far from it.
>
> I'm just curious how Lisp has precedence mistakes.
By discontinuing my post, you generated ambiguity :-)
I was ***not*** stating that LISP can have precedence mistakes. The
part following was:
> > "However, an untested and/or unverified set of S-expressions written
> > by humans is likely to have matching brackets mistakes, specially for
> > deep levels of nesting ))))))))))))))."
I was really stating in that post is that _any_ untested and/or
unverified set of expressions written by humans can contain errors.
> > "However, an untested and/or unverified set of S-expressions written
> > by humans is likely to have matching brackets mistakes, specially for
> > deep levels of nesting ))))))))))))))."
>
> Not with good automatic tools.
Sure, but the poster I was replying was about "untested and/or
unverified set of S-expressions written by humans", no about using
"automatic tools".
You cannot critize other syntaxes because errors can be generated by
humans when writing the code whereas claiming usage of special editors
at the LISP hand. That is a biased comparison.
I have read similar biased comparisons when critizing Python syntax
becoming from some LISPERS at this newsgroup.
> > And, is there universal agreement in the S-expr world?
>
> I think the point Andy was trying to make is that the internal
> representation was suitably canonical
Do you mean any s-expr can be posted here will be unambiguously
interpreted?
Maybe, that is universal agreement on data structures in the S-expr
world?
Or maybe cut&paste between different LISP dialects is error-free
because "the internal representation is canonical"?
> > Something I learn during development of CanonML is that you cannot do
> > a syntax for everyone; therefore, I focused in a syntax for 'machine'
> > and leave anyone to choose the syntax [s]he want.
>
> Except that, since you mention ML, that language has a STRONG bias for
> syntaxes that are symmetric, because dispatching is so hard for nary
> operators. It tends to apply extreme pressure on people to believe that
> + and * are binary operations, rather than nary operations. This makes
> it hard to write code manipulation algorithms that exploit associativity
> and commutativity.
Except that you are confused.
Originally CanonML was strongly based in SXML, which is based in
Scheme, not in ML!!
You confusion is about the acronym ML. ML in S(cheme)XML means Markup
Language. Therefore in original unfinished project CanonML the ML did
mean Markup Language.
Next, CanonML program was extended and modified, the name remained
because popularity issues, except _now_ ML means Meta Language.
On Apr 28, 6:35 am, "Juan R." <··············@canonicalscience.com>
wrote:
> On Apr 23, 5:20 pm, Andy Freeman <······@earthlink.net> wrote:
> > Most journals of algorithms have an errata section. Moreover, such
> > programs are a "final" result. They didn't start out correct.
>
> Nothing of this supports your previous claim about _any_ mathematician
> or reader _doing_ precedence mistakes.
Sure it does. Precedence mistakes happen. The more one works on
removing them, the fewer that there will be. At some point, one may
even remove all of them from a given piece of work. However, that
removal has costs. (Note that much of that effort is wasted on
formula that are correct.)
> "However, an untested and/or unverified set of S-expressions written
> by humans is likely to have matching brackets mistakes, specially for
> deep levels of nesting ))))))))))))))."
>
> Yes, a LISP aware editor can warn you from missed ")" but I think that
> does not LISP prefix syntax so _superior_ that anyone was using it,
> no?
Huh?
Omitting a closing parentheses is a syntax error. We're not
discussing syntax errors - they can be detected for both lisp and
infix. We're discussing a class of semantic errors that is impossible
with lisp and happens "often enough" with infix.
> And, is there universal agreement in the S-expr world?
There is universal agreement on the parsing->semantics. There are
differences in operator semantics, but that's no different than the
different possible definitions of "+'" (or "add"), regardless of the
syntax.
> Contrary to certain LISP gurus I prefer inform people of advantages
> disadvantages of each one letting them to choose they prefer in basis
> to personal preferences and kind of problems they work.
There's nothing in this thread that indicates that.
WRT "certain lisp gurus", it would be nice if you could provide a
checkable cite instead of an untestable claim. After all, none of the
folks who have significant experience in the lisp world are familiar
with such folk.
> Something I learn during development of CanonML is that you cannot do
> a syntax for everyone; therefore, I focused in a syntax for 'machine'
> and leave anyone to choose the syntax [s]he want.
In other words, you made it so that everyone had to learn every else's
preference. That sure enables communication and reuse.
On 6 Apr 2007 14:28:23 -0700, "Andy Freeman" <······@earthlink.net> said:
| On Apr 6, 5:05 am, "Juan R." <··············@canonicalscience.com>
| wrote:
|| ...
|| Lisp syntax has been known for decades and its impact on mathematics,
|| science, and engineering is epsilon (when epsilon tends to zero).
| None of those domains have to work with the wide variety of operators
| that programmers deal with every day. (Note that even programming
| languages with infix operators only use them for a small fraction of
| the operations.)
| And, programming isn't math.
Indeed.
Mathematical notation is inherently two-dimensional, and
mathematicians want it that way, even though there is a formally
equivalent one-dimensional representation of each mathematical
formula. One consequence is that the infix-prefix distinction does
not apply to mathematical notation in general, at least not in the
same way as it applies to programming language notation.
Furthermore, through the use of multiple alphabets, fonts, faces,
etc. as well as "diacritics", multi-character identifiers are an
exception much more than the rule in mathematical notation, as
opposed to programming language notation (even though there are a
few important exceptions, such as the names of the trigonometric
functions; and in any case the (average, maximum, etc.) length of
identifiers in mathematical notation is nowhere near that in
programming languages). That, too, has a bearing on the structural
aspect of what makes a good notation.
By the time Lisp came into being, mathematical notation had already
reached maturity and stability. It had been in a state of flux
several centuries ago, when it was possible for something to have a
significant impact on mathematical notation; it is not impossible,
of course, that the advent of computer peripherals causes another
state of flux, but I would not venture a opinion in that respect.
---Vassil.
--
The truly good code is the obviously correct code.
On Apr 7, 4:27 am, "Juan R." <··············@canonicalscience.com>
wrote:
> On Apr 6, 11:28 pm, "Andy Freeman" <······@earthlink.net> wrote:
> > In all but the latter case, it's as I wrote, math-trained humans
> > writing for math-trained humans. They make and correct for the
> > same mistakes.
>
> Are LISPERs error-free?
Not at all. Lispers are quite human. Lispers make precedence
mistakes
when they use precedence. They don't make precedence mistakes when
they
don't use precedence.
> I have worked on science, math, language, and computers and everyone
> care about 'strict correctness'.
Are precedence mistakes possible in your domain? If they are not, why
not? (I ask because precedence mistakes happen in every other
domain.)
If they are possible, how are you going to deal with them?
From: Michael Fleming
Subject: Re: Any macro for inserting math "normally"
Date:
Message-ID: <Zu_Rh.9808$op4.6254@trnddc08>
Juan R. wrote:
>
> But the important point is another. Language of math is optimised for
> communication. Products are a shorthand for sums, I write [5 * 7]
> instead the large [5 + 5 + 5 + 5 + 5 + 5 + 5].
Then what is [5 * 0] shorthand for?
mlf
Some entity, AKA Michael Fleming <·····@pacbell.net>,
wrote this mindboggling stuff:
(selectively-snipped-or-not-p)
> Then what is [5 * 0] shorthand for?
42
or any other arbiraty value within your universe.
cor
--
A well regulated free and independent internet-militia, being necessary
to the security of a free and independent internet community,
the right of the people to keep, develop, use and exchange any free software
or information thereof, shall not be infringed. http://www.thefreeworld.net
On Apr 8, 6:31 am, Cor Gest <····@clsnet.nl> wrote:
> Some entity, AKA Michael Fleming <····@pacbell.net>,
> wrote this mindboggling stuff:
> (selectively-snipped-or-not-p)
>
> > Then what is [5 * 0] shorthand for?
>
> 42
> or any other arbiraty value within your universe.
>
> cor
>
x * 0 = 0 is necessary not arbitrary if you want to be able to
decompose multiplication.
Otherwise, what is x * (0 + 0 + 0)?
(x * 0) + (x * 0) +(x * 0) or just (x * 0)?
Some entity, AKA "Chris Russell" <·····················@gmail.com>,
wrote this mindboggling stuff:
(selectively-snipped-or-not-p)
> > > Then what is [5 * 0] shorthand for?
> > 42
> > or any other arbiraty value within your universe.
> x * 0 = 0 is necessary not arbitrary if you want to be able to
> decompose multiplication.
> Otherwise, what is x * (0 + 0 + 0)?
> (x * 0) + (x * 0) +(x * 0) or just (x * 0)?
only if the value of 0 is not 8.4 ;-)
cor
--
A well regulated free and independent internet-militia, being necessary
to the security of a free and independent internet community,
the right of the people to keep, develop, use and exchange any free software
or information thereof, shall not be infringed. http://www.thefreeworld.net
On Apr 8, 6:48 am, Michael Fleming <····@pacbell.net> wrote:
> Juan R. wrote:
>
> > But the important point is another. Language of math is optimised for
> > communication. Products are a shorthand for sums, I write [5 * 7]
> > instead the large [5 + 5 + 5 + 5 + 5 + 5 + 5].
>
> Then what is [5 * 0] shorthand for?
I think would be [0 + 0 + 0 + 0 + 0].
Multiplication is usually defined as shorthand for repeated summation,
somewhat as exponentiation is for repeated multiplication.
[2 ^ 5] = [2 * 2 * 2 * 2 * 2]
On 14 Apr 2007 04:36:13 -0700, "Juan R."
<··············@canonicalscience.com> wrote:
>On Apr 8, 6:48 am, Michael Fleming <····@pacbell.net> wrote:
>> Juan R. wrote:
>>
>> > But the important point is another. Language of math is optimised for
>> > communication. Products are a shorthand for sums, I write [5 * 7]
>> > instead the large [5 + 5 + 5 + 5 + 5 + 5 + 5].
>>
>> Then what is [5 * 0] shorthand for?
>
>I think would be [0 + 0 + 0 + 0 + 0].
Which of the following is [5 * 7] shorthand for?
(a) [5 + 5 + 5 + 5 + 5 + 5 + 5]
(b) [7 + 7 + 7 + 7 + 7]
Your first statement above says (a).
Your second statement above implies (b).
"Both" is not a good answer.
What is [0 * 0] shorthand for?
___________________
Real email address:
(substitute ··@ #\+ (substitute #\s #\! "u!enet001+nomi!tech.com"))
On Apr 14, 2:18 pm, Simon Katz <·······@nomistech.com> wrote:
> On 14 Apr 2007 04:36:13 -0700, "Juan R."
>
> <··············@canonicalscience.com> wrote:
> >On Apr 8, 6:48 am, Michael Fleming <····@pacbell.net> wrote:
> >> Juan R. wrote:
>
> >> > But the important point is another. Language of math is optimised for
> >> > communication. Products are a shorthand for sums, I write [5 * 7]
> >> > instead the large [5 + 5 + 5 + 5 + 5 + 5 + 5].
>
> >> Then what is [5 * 0] shorthand for?
>
> >I think would be [0 + 0 + 0 + 0 + 0].
>
> Which of the following is [5 * 7] shorthand for?
> (a) [5 + 5 + 5 + 5 + 5 + 5 + 5]
> (b) [7 + 7 + 7 + 7 + 7]
> Your first statement above says (a).
> Your second statement above implies (b).
> "Both" is not a good answer.
Both is an excellent reply because commutativity. Look for the example
[4 * 7] in the wiki article [1]
> What is [0 * 0] shorthand for?
Ok, I can also play to that funy game!
Look the definition of multiplication on [1]
[a * n] = [a + ··· + a]
\_________/
n times
then
[0 * 0] = [0 + ··· + 0]
\_________/
0 times
Now, seriously. Initially multiplication was invented as shorthand for
repeated sums. Instead writting [3 + 3 + 3 + 3 + 3 + 3] someone
decided to write [3 * 6]. The same for exponentiation [2].
The zero is special and really there is no gain or economy on writting
symbols for [0 * 0].
However, that implies nothing for original purposes of multiplication
as discussed above. Also [1] division was invented as inverse of
multiplication and that does not mean that division by zero was
defined.
With identical purposes (shortand) were invented adittion and
tetration [3]
[1] http://en.wikipedia.org/wiki/Multiplication
[2] http://en.wikipedia.org/wiki/Exponentiation
[3] http://en.wikipedia.org/wiki/Tetration
From: Michael Fleming
Subject: Re: Any macro for inserting math "normally"
Date:
Message-ID: <NUjUh.612$0S1.340@trnddc01>
Juan R. wrote:
> On Apr 14, 2:18 pm, Simon Katz <·······@nomistech.com> wrote:
>
>>On 14 Apr 2007 04:36:13 -0700, "Juan R."
>>
>><··············@canonicalscience.com> wrote:
>>
>>>On Apr 8, 6:48 am, Michael Fleming <····@pacbell.net> wrote:
>>>
>>>>Juan R. wrote:
>>
>>>>>But the important point is another. Language of math is optimised for
>>>>>communication. Products are a shorthand for sums, I write [5 * 7]
>>>>>instead the large [5 + 5 + 5 + 5 + 5 + 5 + 5].
>>
>>>>Then what is [5 * 0] shorthand for?
>>
>>>I think would be [0 + 0 + 0 + 0 + 0].
>>
>>Which of the following is [5 * 7] shorthand for?
>>(a) [5 + 5 + 5 + 5 + 5 + 5 + 5]
>>(b) [7 + 7 + 7 + 7 + 7]
>>Your first statement above says (a).
>>Your second statement above implies (b).
>>"Both" is not a good answer.
>
>
> Both is an excellent reply because commutativity. Look for the example
> [4 * 7] in the wiki article [1]
>
>
>>What is [0 * 0] shorthand for?
>
>
> Ok, I can also play to that funy game!
>
> Look the definition of multiplication on [1]
>
> [a * n] = [a + ��� + a]
> \_________/
> n times
>
> then
>
> [0 * 0] = [0 + ��� + 0]
> \_________/
> 0 times
>
> Now, seriously. Initially multiplication was invented as shorthand for
> repeated sums. Instead writting [3 + 3 + 3 + 3 + 3 + 3] someone
> decided to write [3 * 6]. The same for exponentiation [2].
>
> The zero is special and really there is no gain or economy on writting
> symbols for [0 * 0].
So zero is special. If you come across [0*0] your simple shorthand
scheme fails and you have to DEFINE [0*0] to equal zero. That one act
makes it a new operation, not a shorthand for anything.
If you exclude zero, you can write a program that will expand [a*b] into
a series of additions, but if you include zero you are out of luck.
Your program doesn't write 0 for some products involving zero, it does
nothing.
Multiplication by zero has a problem similar to division by zero. It's
undefined, in your shorthand system. You can't get around [0*0] by
appealing to commutativity because it won't work either way, and yet it
is well-formed.
Michael
> However, that implies nothing for original purposes of multiplication
> as discussed above. Also [1] division was invented as inverse of
> multiplication and that does not mean that division by zero was
> defined.
>
> With identical purposes (shortand) were invented adittion and
> tetration [3]
>
> [1] http://en.wikipedia.org/wiki/Multiplication
>
> [2] http://en.wikipedia.org/wiki/Exponentiation
>
> [3] http://en.wikipedia.org/wiki/Tetration
>
On Apr 15, 8:48 am, Michael Fleming <····@pacbell.net> wrote:
> > The zero is special and really there is no gain or economy on writting
> > symbols for [0 * 0].
>
> So zero is special.
Yes, it always was.
> If you come across [0*0] your simple shorthand
> scheme fails and you have to DEFINE [0*0] to equal zero. That one act
> makes it a new operation, not a shorthand for anything.
An exception does not invalidate a general rule, simply is a exception
to the rule. I.e. the rule does not apply to the exception.
I already explained that products were invented as shorthand for
repeated sums. In fact, that is the definition of product. Instead
writting [2 + 2 + 2 + 2 + 2 + 2] one writes [2 * 6]. That is a
shorthand.
No one does not need to define [0 * 0] in a different way as you say.
The product [0 * 0] is defined in exactly the same way that other
products: i.e. again its is a repeated sum. Now however it is the zero
times sum of zero, and now there is no net gain economy in writtings
the SYMBOLS.
> Multiplication by zero has a problem similar to division by zero. It's
> undefined, in your shorthand system. You can't get around [0*0] by
> appealing to commutativity because it won't work either way, and yet it
> is well-formed.
It is not my shorthand system; it is the definition, follow the links.
And no multiplication by zero is not undefined.
I think you missed the part when i said
> However, that implies nothing for original purposes of multiplication
> as discussed above. Also [1] division was invented as inverse of
> multiplication and that does not mean that division by zero was
> defined.
>
> With identical purposes (shortand) were invented adittion and
> tetration [3]
> > [1] http://en.wikipedia.org/wiki/Multiplication
>
> > [2] http://en.wikipedia.org/wiki/Exponentiation
>
> > [3] http://en.wikipedia.org/wiki/Tetration
"Juan R." <··············@canonicalscience.com> writes:
> On Apr 15, 8:48 am, Michael Fleming <····@pacbell.net> wrote:
>
>> > The zero is special and really there is no gain or economy on writting
>> > symbols for [0 * 0].
>>
>> So zero is special.
>
> Yes, it always was.
>
>> If you come across [0*0] your simple shorthand
>> scheme fails and you have to DEFINE [0*0] to equal zero. That one act
>> makes it a new operation, not a shorthand for anything.
>
> An exception does not invalidate a general rule, simply is a exception
> to the rule. I.e. the rule does not apply to the exception.
>
> I already explained that products were invented as shorthand for
> repeated sums. In fact, that is the definition of product. Instead
> writting [2 + 2 + 2 + 2 + 2 + 2] one writes [2 * 6]. That is a
> shorthand.
This is the naive explaination. It works when you play with little
cubes. But maths weren't invented for toddlers playing with little
cubes. It was invented for serrious problems, like ownership of land
in the Nile valley.
When you have a continuous surface, it's harder to explain how you'd
start from x meters and sum them y times to get z square-meters!
(think 21.345 m times 12.743 m, how do you sum 0.743 times a number of
little cube?)
> No one does not need to define [0 * 0] in a different way as you say.
> The product [0 * 0] is defined in exactly the same way that other
> products: i.e. again its is a repeated sum. Now however it is the zero
> times sum of zero, and now there is no net gain economy in writtings
> the SYMBOLS.
When you play with little cubes, and you don't sum any cube, you
don't do anything and you're left with no cube, which happens to be
what we call zero cubes. All right.
But if you don't do anything in a formal system, you get this:
Yes, nothing. This is quite different than multiplying 0 by 0, and
getting:
0
There's a conscious and explicit specification for + and * in CLHS to
produce 0 and 1. It is quite different than producing NIL or the
result of (VALUES), that is nothing.
--
__Pascal Bourguignon__
On Apr 16, 5:57 am, Pascal Bourguignon <····@informatimago.com> wrote:
> > I already explained that products were invented as shorthand for
> > repeated sums. In fact, that is the definition of product. Instead
> > writting [2 + 2 + 2 + 2 + 2 + 2] one writes [2 * 6]. That is a
> > shorthand.
>
> This is the naive explaination. It works when you play with little
> cubes. But maths weren't invented for toddlers playing with little
> cubes. It was invented for serrious problems, like ownership of land
> in the Nile valley.
>
> When you have a continuous surface, it's harder to explain how you'd
> start from x meters and sum them y times to get z square-meters!
> (think 21.345 m times 12.743 m, how do you sum 0.743 times a number of
> little cube?)
You appear to think that numbers were invented at once. I thought that
historical route had been successive extension of the concept of
number from non-abstract trivial count operation:
1 cube, 2 cubes, 3 cubes, 4 cubes, 5 cubes...
then sums [1 + 2], [3 + 5]...
next differences as inverse of sums; if [3 + 5] --> 8 then [8 - 5] --
> 3
I believe zero was introduced at this stage, e.g. [6 - 6] --> 0
Then did appear a problem. What does mean the operation [5 - 8]?
Mathematicians solved by introducing negative numbers -1, -2, -3...
Next multiplications of naturals as repeated sums, [2 * 5] --> [2 + 2
+ 2 + 2 + 2].
After division as the inverse operation; if [2 * 4] --> 8 then [8 /
4] --> 2.
Then did appear another problem. What does mean [8 / 3]? This cannot
replied using above numbers because is neither 2 nor 3. Mathematicians
introduced rationals, e.g. your 0.743 living somewhere between 0 and
1.
Next exponentiations of naturals as repeated multiplications, [2 ^ 3]
--> [2 * 2 * 2].
After roots as the inverse operation; if [2 ^ 2] --> 4 then [SQRT 4]
--> 2.
Remember we introduced negative numbers before, which introduces now a
new problem, what does mean [SQRT -3]? Then mathematicians introduced
imaginary numbers and associated complex.
Notice that with each new extension of the concept of number you may
generalize the definitions for the operations. For example initially
you begin with [2 * 4], [1 * 3], [5 * 7]... but after you also define
[i * 3], [-2 * 8], [6 * 4/3]... and you lose original simplicity and
motivations.
With each new extension mathematics is more and more abstract, this is
reason understanding the sum 0.743 times a number of little cube is
not so easy as understanding the sum of three cubes. But _originally_
[2 * 8] was introduced in mathematics because anyone considered that
[2 + 2 + 2 + 2 + 2 + 2 + 2 + 2] was little practical.
Scientific notation was invented by shorthand motives also. In science
and engineering, very large or very small quantitities appear often.
Instead writing a six and twenty zeros, someone invented notation [6 *
[10 ^ 20]].
Of course, once invented 'that', now you are free to write [4 * [10 ^
3.5]] if you want, because maths rules leave you to do that.
You can become angry because now 3.5 means that you add three zeros
more a half of a zero to the four. This is hard to explain how one may
add a half of a zero, but remember _original_ motivation: shorthand.
On Sat, 14 Apr 2007 14:18:37 +0200, Simon Katz <·······@nomistech.com>
wrote:
> On 14 Apr 2007 04:36:13 -0700, "Juan R."
> <··············@canonicalscience.com> wrote:
>
>> On Apr 8, 6:48 am, Michael Fleming <····@pacbell.net> wrote:
>>> Juan R. wrote:
>>>
>>> > But the important point is another. Language of math is optimised for
>>> > communication. Products are a shorthand for sums, I write [5 * 7]
>>> > instead the large [5 + 5 + 5 + 5 + 5 + 5 + 5].
>>>
>>> Then what is [5 * 0] shorthand for?
>>
>> I think would be [0 + 0 + 0 + 0 + 0].
>
> Which of the following is [5 * 7] shorthand for?
> (a) [5 + 5 + 5 + 5 + 5 + 5 + 5]
> (b) [7 + 7 + 7 + 7 + 7]
> Your first statement above says (a).
> Your second statement above implies (b).
> "Both" is not a good answer.
>
> What is [0 * 0] shorthand for?
>
> ___________________
> Real email address:
> (substitute ··@ #\+ (substitute #\s #\! "u!enet001+nomi!tech.com"))
Notation should be read from left to right unless otherwise spesified.
5 * 7 thus means 7 + 7 + 7 + 7 + 7
In the case of this algebra it is commutative so it dosn't matter. (a * b
= b * a)
Now if A and B are matrixes which are not commutative
A * B =/= B * A and it MUST be read from left to right.
On the whole you might as well get used to b)
The exception is 5 ^ 7 = 5 * 5 * 5 * 5 * 5 * 5 * 5
But that is mostly due to the odd syntactic convention when converting
the expression to ASCII.
what is -2^3? well -2^3 = (- (expt 2 3)) = -8 not (expt -2 3) = 8
so thinking left to right saves you here.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
On 31 Mar, 13:12, "Juan R." <··············@canonicalscience.com>
wrote:
> On Mar 26, 8:20 pm, "Alex Mizrahi" <········@users.sourceforge.net>
> wrote:
>
> > are you sure you'd like to use more 'ambiquous' infix math notation with all
> > those operator priorities instead of straightforward lisp syntax? :)
>
> If it is so straightforward like you claim, why do mathematicians
> reject it masively?
I think [1] makes an interesting point: while the prefix notation is
clearly superior for 2d display of programs and other tree-like
structures, it might not be the best for handling relatively short,
one-lines formulas.
2d layout example (from [1]):
(/ (* (- 2 3)
(+ 4 1))
(+ 11 3))
1d layout examples (also from [1]):
(/ (* (- 2 3) (+ 4 1)) (+ 11 3))
((2 - 3) * (4 + 1)) / (11 + 3)
As far as 1d layouts are concerned, the infix notation looks much
better to me. Greater general familiary with infix than with prefix
is, I think, only part of the explanation.
Infix is better because operands are closer to their operators: for
any expression (such as "3" or "(4 + 1)" or "(11 + 3)") finding the
corresponding operator (here "-" or "*" or "/") is easy: it is just
the closest operator to the expression. Left/right ambiguity is
easily resolved by taking the direction with the smaller number of
consecutive parentheses (for "* (4+1)) /" you have only one for "*"
and two for "/", so "*" wins).
In the prefix notation, the operator can be miles away from its
operands (for example "(/ ... (+ 11 3))"). In order to find it, you
you have to scan over entire groups of expressions, doing mental
parenthesis balancing in the process. This is much more difficult and
unnatural for the human brain than comparing the number of
_consecutive_ parenthesis on the left and right (eg. "(4 + 1)" has "("
on the left, and "))" on the right). This is because comparing "("
with "))" can be done by simple visual pattern matching, something our
brains are excellent at.
Why finding operators from expressions (and not vice versa) is so
important? Because expressions are complicated; finding them requires
parenthesis balancing whatever syntax you use. Operators are simple
symbols/words, which can be easily recognized by visual pattern
matching.
To sum up, I believe infix notation has objective advantages over
prefix for 1-line expressions. For longer expressions, 2d-layout is
clearly superior as it solves all above problems, and has other
advantages such as being homogenous, versatile, and not limited to
binary operators.
The same goes for operator priorities in infix ("4+3*2" vs "4+(3*2)"):
they are useful for very short expressions, but they are a
maintenance nightmare for anything longer.
Last point: in lisp, using infix for short expressions, does not
violate homogeneity any more than the "loop" macro does. It's just
another microlanguage. It has the same issues as other microlanguages
do: it is intended to be, well, micro, and you need to explicitly
request it (by writing "(nfx 3 + 4)" or similar). I think for
programs doing a lot of scientific math, it's worth it.
Piotr
[1] http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/msg01619.html
On Mar 31, 7:34 pm, "Piotr" <···············@gmail.com> wrote:
> I think [1] makes an interesting point: while the prefix notation is
> clearly superior for 2d display of programs and other tree-like
> structures, it might not be the best for handling relatively short,
> one-lines formulas.
I am not sure about this.
> As far as 1d layouts are concerned, the infix notation looks much
> better to me. Greater general familiary with infix than with prefix
> is, I think, only part of the explanation.
Paul Graham states that, whereas using LISP for math during his entire
life, he still find uncomfortable with the syntax and wait infix math
for next LISP. Therefore familiarity is not the point.
> Infix is better because operands are closer to their operators: for
> any expression (such as "3" or "(4 + 1)" or "(11 + 3)") finding the
> corresponding operator (here "-" or "*" or "/") is easy: it is just
> the closest operator to the expression. Left/right ambiguity is
> easily resolved by taking the direction with the smaller number of
> consecutive parentheses (for "* (4+1)) /" you have only one for "*"
> and two for "/", so "*" wins).
The infix operator presents several advantages. It splits space doing
easier the visual identification of operands (easy to read) minimizing
number of parentheses (optimisation). Compare typical science equation
structure (e.g. Schrödinger, chemical kinetics, statistical mechanics,
epidemiology...)
[[ r / t] = L r]
with LISPs
(= (/ (quote ( r)) (quote ( t))) (quote (L r)))
(= (/ '( r) '( t)) '(L r))
2D-layouts do not improve much
(=
(/
'( r)
'( t))
'(L r))
Notice that infix notation did not assume any precedence rules. The
reduction from 16 parentheses to 4 brackets is based in topological
properties of the infix.
> In the prefix notation, the operator can be miles away from its
> operands (for example "(/ ... (+ 11 3))"). In order to find it, you
> you have to scan over entire groups of expressions, doing mental
> parenthesis balancing in the process. This is much more difficult and
> unnatural for the human brain than comparing the number of
> _consecutive_ parenthesis on the left and right (eg. "(4 + 1)" has "("
> on the left, and "))" on the right). This is because comparing "("
> with "))" can be done by simple visual pattern matching, something our
> brains are excellent at.
Easiness and preference of infix notation may be also related to
language processing on brain. Languages over entire world developed
like [Juan loves Patri] instead lispy (loves Juan Patri).
> Why finding operators from expressions (and not vice versa) is so
> important? Because expressions are complicated; finding them requires
> parenthesis balancing whatever syntax you use. Operators are simple
> symbols/words, which can be easily recognized by visual pattern
> matching.
>
> To sum up, I believe infix notation has objective advantages over
> prefix for 1-line expressions. For longer expressions, 2d-layout is
> clearly superior as it solves all above problems, and has other
> advantages such as being homogenous, versatile, and not limited to
> binary operators.
>
> The same goes for operator priorities in infix ("4+3*2" vs "4+(3*2)"):
> they are useful for very short expressions, but they are a
> maintenance nightmare for anything longer.
Well, but one can design a syntax where author can choose in basis to
personal preferences and specifics of his|her work instead forcing an
all-prefix syntax 90% of people reject.
> Last point: in lisp, using infix for short expressions, does not
> violate homogeneity any more than the "loop" macro does. It's just
> another microlanguage. It has the same issues as other microlanguages
> do: it is intended to be, well, micro, and you need to explicitly
> request it (by writing "(nfx 3 + 4)" or similar). I think for
> programs doing a lot of scientific math, it's worth it.
LISP reading macros are a kind of superficial cosmetic can generate
more problems, obligating to use the default prefix full parenthesised
syntax. It is usually believed that infix-syntax macros are for
novices.
That we need is LISP expressiveness power and simplicity without the
known theoretical and usability constraints have been relegating LISP
to the role of unconventional language.
> [1]http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/msg01619.html
"Juan R." <··············@canonicalscience.com> writes:
>> Infix is better because operands are closer to their operators: for
>> any expression (such as "3" or "(4 + 1)" or "(11 + 3)") finding the
>> corresponding operator (here "-" or "*" or "/") is easy: it is just
>> the closest operator to the expression. Left/right ambiguity is
>> easily resolved by taking the direction with the smaller number of
>> consecutive parentheses (for "* (4+1)) /" you have only one for "*"
>> and two for "/", so "*" wins).
>
> The infix operator presents several advantages. It splits space doing
> easier the visual identification of operands (easy to read) minimizing
> number of parentheses (optimisation). Compare typical science equation
> structure (e.g. Schr�dinger, chemical kinetics, statistical mechanics,
> epidemiology...)
>
> [[ r / t] = L r]
>
> with LISPs
>
> (= (/ (quote ( r)) (quote ( t))) (quote (L r)))
>
> (= (/ '( r) '( t)) '(L r))
>
> 2D-layouts do not improve much
>
> (=
> (/
> '( r)
> '( t))
> '(L r))
>
Why the quotes?
[[ r / t] = L r]
is transcribed as:
(= (/ r t) (L r))
--
__Pascal Bourguignon__
http://www.informatimago.com
http://pjb.ogamita.org
On Apr 6, 5:08 am, "Juan R." <··············@canonicalscience.com>
wrote:
> ...
> Easiness and preference of infix notation may be also related to
> language processing on brain. Languages over entire world developed
> like [Juan loves Patri] instead lispy (loves Juan Patri).
Well... It's more about what you're used to. From Wikipedia:
Quote:
Verb Subject Object (VSO) is a term in linguistic typology. It
represents one type of languages when classifying languages according
to the sequence of these constitutents in neutral expressions: Ate Sam
oranges. The word order roughly corresponds to the order of symbols in
(non-reverse) Polish notation or the S-expressions of the Lisp
programming language.
Examples of languages with VSO word order include the Gaelic branch of
the Celtic language family (namely Irish, Scottish Gaelic and Manx),
related Brythonic languages; Welsh, Cornish and Breton, Ancient
Egyptian, Aramaic, Biblical Hebrew, Pangasinan, Phoenician, Canaanite,
Ge'ez, Classic Maya, Tagalog, Hawaiian, Māori, and Tongan.
Unquote.
On Apr 16, 2:12 am, "rxfelix" <······@felix.org> wrote:
> On Apr 6, 5:08 am, "Juan R." <··············@canonicalscience.com>
> wrote:
>
> > ...
> > Easiness and preference of infix notation may be also related to
> > language processing on brain. Languages over entire world developed
> > like [Juan loves Patri] instead lispy (loves Juan Patri).
>
> Well... It's more about what you're used to. From Wikipedia:
>
> Quote:
> Verb Subject Object (VSO) is a term in linguistic typology. It
> represents one type of languages when classifying languages according
> to the sequence of these constitutents in neutral expressions: Ate Sam
> oranges. The word order roughly corresponds to the order of symbols in
> (non-reverse) Polish notation or the S-expressions of the Lisp
> programming language.
>
> Examples of languages with VSO word order include the Gaelic branch of
> the Celtic language family (namely Irish, Scottish Gaelic and Manx),
> related Brythonic languages; Welsh, Cornish and Breton, Ancient
> Egyptian, Aramaic, Biblical Hebrew, Pangasinan, Phoenician, Canaanite,
> Ge'ez, Classic Maya, Tagalog, Hawaiian, Māori, and Tongan.
> Unquote.
Thanks by additional information and your useful corrections.
Now a few questions. How many of those are modern languages? Ancient
Egyptian, Aramaic, Biblical Hebrew, and Classic Maya do not appear to
be modern. I think that Breton, Hawaiian, and Māori may be in some
local use but I am not sure.
What is the ratio [VSO / non-VSO]? 0.2 maybe?
The article on SVO says that English evolved from languages with
certain VSO structures. The same article adds:
[BLOCKQUOTE
for example in the case of reported speech, e.g. "Oranges," said
Sam,
although such usage is itself in decline in favour of SVO Sam said
"Oranges."
]
Which has a weak relation I said before about evolution of languages
and declining of prefix.
On Apr 21, 7:20 pm, "Juan R." <··············@canonicalscience.com>
wrote:
> On Apr 16, 2:12 am, "rxfelix" <······@felix.org> wrote:
>
>
>
> > On Apr 6, 5:08 am, "Juan R." <··············@canonicalscience.com>
> > wrote:
>
> > > ...
> > > Easiness and preference of infix notation may be also related to
> > > language processing on brain. Languages over entire world developed
> > > like [Juan loves Patri] instead lispy (loves Juan Patri).
>
> > Well... It's more about what you're used to. From Wikipedia:
>
> > Quote:
> > Verb Subject Object (VSO) is a term in linguistic typology. It
> > represents one type of languages when classifying languages according
> > to the sequence of these constitutents in neutral expressions: Ate Sam
> > oranges. The word order roughly corresponds to the order of symbols in
> > (non-reverse) Polish notation or the S-expressions of the Lisp
> > programming language.
>
> > Examples of languages with VSO word order include the Gaelic branch of
> > the Celtic language family (namely Irish, Scottish Gaelic and Manx),
> > related Brythonic languages; Welsh, Cornish and Breton, Ancient
> > Egyptian, Aramaic, Biblical Hebrew, Pangasinan, Phoenician, Canaanite,
> > Ge'ez, Classic Maya, Tagalog, Hawaiian, Māori, and Tongan.
> > Unquote.
>
> Thanks by additional information and your useful corrections.
>
> Now a few questions. How many of those are modern languages? Ancient
> Egyptian, Aramaic, Biblical Hebrew, and Classic Maya do not appear to
> be modern. I think that Breton, Hawaiian, and Māori may be in some
> local use but I am not sure.
My native Tagalog language (and possibly the related Visayan
languages, I think, which are derived from either Malay or Indonesian)
has a VSO form. For instance, I can say "Nag-aral ako ng Lisp", where
"nag-aral" is the past tense of "aral" or study/learn, "ako" is the
singular self pronoun like "I", and "ng" is an overloaded connector,
used to specify either that the nonpersonal noun after it is the
target (which may be either the subject or object, based on position
in sentence), or that it is the owner of the previous noun. However,
the language does have an SVO form that feels (to me, and native
speakers I think) hacked into the language, "Ako ay nagaral ng Lisp",
where "ay" signifies that form and separates the subject from the
verb. I have this vague feeling the SVO form was hacked into the
language by the Spaniards who did much of the teaching (!!) of the
language in the 16th-19th century.
On Apr 29, 5:34 am, "Alan Manuel K. Gloria" <········@gmail.com>
wrote:
> My native Tagalog language (and possibly the related Visayan
> languages, I think, which are derived from either Malay or Indonesian)
> has a VSO form. For instance, I can say "Nag-aral ako ng Lisp", where
> "nag-aral" is the past tense of "aral" or study/learn, "ako" is the
> singular self pronoun like "I", and "ng" is an overloaded connector,
> used to specify either that the nonpersonal noun after it is the
> target (which may be either the subject or object, based on position
> in sentence), or that it is the owner of the previous noun. However,
> the language does have an SVO form that feels (to me, and native
> speakers I think) hacked into the language, "Ako ay nagaral ng Lisp",
> where "ay" signifies that form and separates the subject from the
> verb. I have this vague feeling the SVO form was hacked into the
> language by the Spaniards who did much of the teaching (!!) of the
> language in the 16th-19th century.
Thanks by useful additional data.
Do you believe that an infix LISP (leaving also to work in a pure
prefix way if desired) would be more useful than current all-prefix
LISP?
I am not stating development of a LISP where infix was introduced at
one price macros and other interesting stuff is eliminated from the
language _a la_ Python, but a new language with all the power of
current LISP but without oddities of all prefix approach.
·················@gmail.com wrote:
> Does somebody knows about some macro for putting math traditionally
> you know : 2 + 3 / (5 * 7 ). instead of (/ (+ 2 3) (* 5 7))
> I've tried to make something while reading On lisp but problems seems
> taff one.
I've implemented a macro for this some time ago:
http://groups.google.com/group/comp.lang.lisp/msg/09563f6e0f0e604e
--
Frank Buss, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
On Apr 9, 5:31 am, Frank Buss <····@frank-buss.de> wrote:
> ·················@gmail.com wrote:
> > Does somebody knows about some macro for putting math traditionally
> > you know : 2 + 3 / (5 * 7 ). instead of (/ (+ 2 3) (* 5 7))
> > I've tried to make something while reading On lisp but problems seems
> > taff one.
>
> I've implemented a macro for this some time ago:
>
> http://groups.google.com/group/comp.lang.lisp/msg/09563f6e0f0e604e
>
> --
> Frank Buss, ····@frank-buss.dehttp://www.frank-buss.de,http://www.it4-systems.de
I always preferred doing things in-language, rather than parsing
strings. I like the way Lisp represents code using a relatively easy-
to-hack data structure, and try to take advantage of this each time I
use Lisp. My approach (on Lavigne's page) happens to be to hack
together the prefixed form from a list of expressions in an infix
format.