The Concepts and Confusions of Prefix, Infix, Postfix and Fully
Functional Notations
Xah Lee, 2006-03-15
[This articles explains away the confusion of common terms for
notation systems used in computer languages: prefix, infix, postfix,
algebraic, functional. These notation's relation to the concept of
operators. These are explained using examples from LISP, Mathematica,
and imperative languages. Then, it discuss some problems of purely
nested notation.]
In LISP languages, they use a notation like “(+ 1 2)” to mean “1+2”.
Likewise, they write “(if test this that)” to mean “if (test) {this}
else {that}”. LISP codes are all of the form “(a b c ...)”, where the
a b c themselves may also be of that form. There is a wide
misunderstanding that this notation being “prefix notation”. In this
article, i'll give some general overview of the meanings of Algebraic
Notation and prefix, infix, postfix notations, and explain how LISP
notation is a Functional Notation and is not a so-called prefix
notation or algebraic notation.
The math notation we encounter in school, such as “1+2”, is called
Infix Algebraic Notation. Algebraic notations have the concept of
operators, meaning, symbols placed around arguments. In algebraic
infix notation, different symbols have different stickiness levels
defined for them. e.g. “3+2*5>7” means “(3+(2*5))>7”. The stickiness
of operator symbols is normally called “Operator Precedence”. It is
done by giving a order specification for the symbols, or equivalently,
give each symbol a integer index, so that for example if we have
“a⊗b⊙c”, we can unambiguously understand it to mean one of “(a⊗b)⊙c”
or “a⊗(b⊙c)”.
In a algebraic postfix notation known as Polish Notation, there needs
not to have the concept of Operator Precedence. For example, the infix
notation “(3+(2*5))>7” is written as “3 2 5 * + 7 >”, where the
operation simply evaluates from left to right. Similarly, for a prefix
notation syntax, the evaluation goes from right to left, as in “> 7 +
* 5 2 3”.
While functional notations, do not employ the concept of Operators,
because there is no operators. Everything is a syntactically a
“function”, written as f(a,b,c...). For example, the same expression
above is written as “>( +(3, *(2,5)), 7)” or “greaterThan( plus(3,
times(2,5)), 7)”.
For lisps in particular, their fully functional notation is
historically termed sexp (short for S-Expression, where S stands for
Symbolic). It is sometimes known as Fully Parenthesized Notation. For
example, in lisp it would be (f a b c ...). In the above example it
is: “(> (+ 3 (* 2 5)) 7)”.
The common concepts of “prefix, postfix, infix” are notions in
algebraic notations only. Because in Full Functional Notation, there
are no operators, therefore no positioning to talk about. A Function's
arguments are simply explicitly written out inside a pair of enclosing
delimiters.
Another way to see that lisp notation are not “pre” anything, is by
realizing that the “head” f in (f a b c) can be defined to be placed
anywhere. e.g. (a b c f) or even (a f b c), and its syntax syntactical
remains the same. In the language Mathematica, f(a b c) would be
written as f[a,b,c] where the argument enclosure symbols is the square
bracket instead of parenthesis, and argument separator is comma
instead of space, and the function symbol (aka “head”) is placed in
outside and in front of the argument enclosure symbols.
The reason for the misconception that lisp notations are “prefix” is
because the “head” appears as the first element in the enclosed
parenthesis. Such use of the term “prefix” is a confusion engenderer
because the significance of the term lies in algebraic notation
systems that involves the concept of operators.
A side note: the terminology “Algebraic” Notation is a misnomer. It
seems to imply that such notations have something to do with the
branch of math called algebra while other notation systems do not. The
reason the name Algebraic Notation is used because when the science of
algebra was young, around 1700s mathematicians are dealing with
equations using symbols like “+ × =” written out similar to the way we
use them today. This is before the activities of systematic
investigation into notation systems as necessitated in the studies of
logic in 1800s or computer languages in 1900s. So, when notation
systems are actually invented, the conventional way of infixing “+ ×
=” became known as algebraic because that's what people think of when
seeing them.
--------
This post is part of a 3-part exposition:
“The Concepts and Confusions of Prefix, Infix, Postfix and Fully
Functional Notations”,
“Prefix, Infix, Postfix notations in Mathematica”,
“How Purely Nested Notation Limits The Language's Utility”,
available at:
http://xahlee.org/UnixResource_dir/writ/notations.html
Xah
···@xahlee.org
∑ http://xahlee.org/
From: Larry Clapp
Subject: Re: The Concepts and Confusions of Prefix, Infix, Postfix and Fully Functional Notations
Date:
Message-ID: <slrnf58s8k.45o.larry@theclapp.ddts.net>
["Followup-To:" header set to comp.lang.lisp.]
On 2007-05-23, Xah Lee <···@xahlee.org> wrote:
> The Concepts and Confusions of Prefix, Infix, Postfix and Fully
> Functional Notations
>
> Xah Lee, 2006-03-15
Xah, why do you post year-old essays to newsgroups that couldn't care
less about them?
From: Ari Johnson
Subject: Re: The Concepts and Confusions of Prefix, Infix, Postfix and Fully Functional Notations
Date:
Message-ID: <m2myzvbcfe.fsf@hermes.theari.com>
Larry Clapp <·····@theclapp.org> writes:
> ["Followup-To:" header set to comp.lang.lisp.]
>
> On 2007-05-23, Xah Lee <···@xahlee.org> wrote:
>> The Concepts and Confusions of Prefix, Infix, Postfix and Fully
>> Functional Notations
>>
>> Xah Lee, 2006-03-15
>
> Xah, why do you post year-old essays to newsgroups that couldn't care
> less about them?
You'll notice that he posted the same thing earlier this month. I
think he must have reposted it when he noticed that he hadn't
cross-posted to enough irrelevant newsgroups.
From: Markus E Leypold
Subject: Re: The Concepts and Confusions of Prefix, Infix, Postfix and Fully Functional Notations
Date:
Message-ID: <1oveejxwke.fsf@hod.lan.m-e-leypold.de>
> On 2007-05-23, Xah Lee <···@xahlee.org> wrote:
>> The Concepts and Confusions of Prefix, Infix, Postfix and Fully
>> Functional Notations
>>
>> Xah Lee, 2006-03-15
>
> Xah, why do you post year-old essays to newsgroups that couldn't care
> less about them?
And even more to the point -- why does he post now again the same
drivel he already posted on the 9th of May 2007? And will we now
treated to repeats of his garbage every 2 weeks?
The answer to your question is very simple: Xah Lee is a troll.
Regards -- Markus
Markus E Leypold wrote:
> The answer to your question is very simple: Xah Lee is a troll.
In this context, I believe he is marketing/advertising himself as a
consultant and some kind of vampiric man-whore according to this page:
http://xahlee.org/PageTwo_dir/Personal_dir/xah.html
"... I'm technically American. Love me and I can make you American."
Xah is perhaps the world's first person to claim to be both a Lisp
programmer and "strong at siring". :-)
Anyway, are there any libraries to do hardware accelerated vector graphics
in Perl, Python, Lisp, Java or any functional language (except OCaml and F#
and excluding WPF and Silverlight)?
--
Dr Jon D Harrop, Flying Frog Consultancy
The F#.NET Journal
http://www.ffconsultancy.com/products/fsharp_journal/?u7
From: Ville Oikarinen
Subject: 3D libraries (was The Concepts and Confusions of Prefix, Infix, Postfix and Fully Functional Notations)
Date:
Message-ID: <Pine.LNX.4.56L0.0705290853090.15650@localhost>
On Tue, 29 May 2007, Jon Harrop wrote:
> Anyway, are there any libraries to do hardware accelerated vector graphics
> in Perl, Python, Lisp, Java or any functional language (except OCaml and F#
> and excluding WPF and Silverlight)?
I believe there are OpenGL bindings for quite many languages, here are two
for java:
https://jogl.dev.java.net/
http://www.lwjgl.org/
- Ville Oikarinen
From: Ulf Wiger
Subject: Re: The Concepts and Confusions of Prefix, Infix, Postfix and Fully Functional Notations
Date:
Message-ID: <xczsl9gj8lm.fsf@cbe.ericsson.se>
>>>>> "Jon" == Jon Harrop <···@ffconsultancy.com> writes:
Jon> Anyway, are there any libraries to do hardware accelerated
Jon> vector graphics in Perl, Python, Lisp, Java or any functional
Jon> language (except OCaml and F# and excluding WPF and
Jon> Silverlight)?
I guess the OpenGL binding for Erlang qualifies. The best
exhibit of this would be Wings3D, an Open Source 3D
graphics modeller, written in Erlang, and with quite a
large user base.
http://www.wings3d.com
BR,
Ulf W
--
Ulf Wiger, Senior Specialist,
/ / / Architecture & Design of Carrier-Class Software
/ / / Team Leader, Software Characteristics
/ / / Ericsson AB, IMS Gateways
From: Tony Finch
Subject: vector graphics bindings, was Re: The Concepts and Confusions of Prefix, Infix, Postfix and Fully Functional Notations
Date:
Message-ID: <2uc*jQWLr@news.chiark.greenend.org.uk>
Jon Harrop <···@ffconsultancy.com> wrote:
>
>Anyway, are there any libraries to do hardware accelerated vector graphics
>in Perl, Python, Lisp, Java or any functional language (except OCaml and F#
>and excluding WPF and Silverlight)?
http://www.cairographics.org/bindings/
That covers all the languages you named, plus O'Caml and Haskell.
Tony.
--
f.a.n.finch <···@dotat.at> http://dotat.at/
GERMAN BIGHT: NORTH BECOMING CYCLONIC 4 OR 5, THEN WEST 5 OR 6. MODERATE OR
ROUGH. RAIN OR DRIZZLE. MODERATE OR GOOD, OCCASIONALLY POOR.
On Wed, 23 May 2007, Larry Clapp wrote:
> ["Followup-To:" header set to comp.lang.lisp.]
>
> On 2007-05-23, Xah Lee <···@xahlee.org> wrote:
> > The Concepts and Confusions of Prefix, Infix, Postfix and Fully
> > Functional Notations
> >
> > Xah Lee, 2006-03-15
>
> Xah, why do you post year-old essays to newsgroups that couldn't care
> less about them?
Maybe he wants to attract google spiders?
- Ville Oikarinen
Prefix, Infix, Postfix notations in Mathematica
2000-02-21, 2007-05
[In the following essay, I discuss prefix, infix, postfix notations
and Mathematica's syntax for them. The full HTML formatted article is
available at:
http://xahlee.org/UnixResource_dir/writ/notations.html
]
THE HEAD OF EXPRESSIONS
Lisp's nested parenthesis syntax is a Functional Notation. It has the
general form of “(f a b ...)” where any of the symbols inside the
matching parenthesis may again be that form. For example, here's a
typical code from Emacs Lisp.
; Recursively apply (f x i), where i is the ith element in the list
li.
; For example, (fold f x '(1 2)) computes (f (f x 1) 2)
(defun fold (f x li)
(let ((li2 li) (ele) (x2 x))
(while (setq ele (pop li2))
(setq x2 (funcall f x2 ele))
)
x2
)
)
Vast majority of computer languages, interpret source code in a one-
dimensional, linear nature. Namely, from left to right, line by line,
as in written text. (Examples of computer languages's source code that
are not linear in nature, are spread sheets, cellular automata,
graphical programing languages) For languages that interprets source
code linearly, the logics of their syntax necessarily have a
hierarchical structure (i.e. tree). The lisp's notation, is the most
effective in visually showing the logics of the syntax. This is
because, a function and its arguments, are simply laid out inside a
parenthesis. The level of nesting corresponds to the “precedence” in
evaluating the expression.
The first element inside the matching parenthesis, is called the
“head” of the expression. For example, in “(f a b)”, the “f” is the
head. The head is a function, and the rest of the symbols inside the
matching parenthesis are its arguments.
The head of lisp's notation needs not to be defined as the first
element inside the parenthesis. For example, we can define the “head”
to be the last element inside the parenthesis. So, we write “(arg1
arg2 ... f)” instead of the usual “(f arg1 arg2 ...)” and its
syntactical analysis remains unchanged. Like wise, you can move the
head outside of the parenthesis.
In Mathematica, the head is placed in front of the parenthesis, and
square brackets are used instead of parenthesis for the enclosing
delimiter. For example, lisp's “(f a b c)” is syntactically equivalent
to Mathematica's “f[a,b,c]”. Other examples: “(sin θ)” vs “Sin[θ]”,
“(map f list)” vs “Map[f,list]”. Placing the head in front of the
matching bracket makes the notation more familiar, because it is a
conventional math notation.
However, there is a disadvantage in moving the head of a expression
from inside the matching bracket to outside. Namely: The nesting of
the matching delimiters, no longer corresponds to the logics of the
syntax, when the head is itself a compound expression.
For example, suppose Reflection(vectorV,pointP) is function that
returns a function f, such that f(graphicsData) will reflect the
graphicsData along a line passing pointP and parallel to vectorV. In
lisp, we would write “((Reflection vectorV pointP) graphicsData)”. In
Mathematica, we would write “Reflection[vectorV,pointP]
[graphicsData]”. In lisp's version, the nesting corresponds to the
logics of the evaluation. In the Mathematica's form, that is no longer
so.
For another example, suppose Deriv is a function that takes a function
f and returns a function g (the derivative of f), and we want to apply
g to a variable x. In lisp, we would write “((Deriv f) x)”. In
Mathematica, we would write “Deriv[f][x]”. In lisp's version, the
nesting corresponds to the logics of the evaluation. In the
Mathematica's form, the logics of the evaluation no longer corresponds
to the nesting level, because now the head is outside of the enclosing
delimiters, so the head of expressions no longer nests.
PREFIX, POSTFIX, INFIX
A prefix notation in Mathematica is represented as ··@arg”.
Essentially, a prefix notation in this context limits it to uses for
functions on only one argument. For example: ··@·@·@c” is equivalent
to “f[a[b[c]]]” or in lispy “(f (a (b c)))”. Mathematica also offers a
postfix notation using the operator “//”. For example, “c//b//a//f” is
syntactically equivalent to “f[a[b[c]]]”. (unix's pipe “|” syntax, is
a form of postfix notation. e.g. “c | b | a | f”).
For example, “Sin[List[1,2,3]]” can be written in postfix as
“List[1,2,3]//Sin”, or prefix ····@List[1,2,3]”. (by the way, they are
semantically equivalent to “Map[Sin, List[1,2,3]]” in Mathematica) For
infix notation, the function symbol is placed between its arguments.
In Mathematica, the generic form for infix notation is by sandwiching
the tilde symbol around the function name. e.g.
“Join[List[1,2],List[3,4]]” is syntactically equivalent to “List[1,2]
~Join~ List[3,4]”.
In Mathematica, there is quite a lot syntax variations beside the
above mentioned systematic constructs. For example, Plus[a,b,c] can be
written as “a+b+c”, “Plus[a+b,c]”, “Plus[Plus[a,b],c]”, or “(a
+b)~Plus~c”. “List[a,b,c]” can be written as “{a,b,c}”, and
“Map[f,List[a,b,c]]” can be written as “f ·@ {a,b,c}”.
The gist being that certain functions are given a special syntactical
construct to emulate the irregular and inefficient but nevertheless
well-understood conventional notations. Also, it reduces the use of
deep nesting that is difficult to type and manage. For example, the
“Plus” function is given a operator “+”, so that Plus[3,4] can be
written with the more familiar “3+4”. The “List” function is given a
syntax construct of “{}”, so that, List[3,4] can be more easily
written as “{3,4}”. The boolean “And” function is given the operator
“&&”, so that And[a,b] can be written with the more familiar and
convenient “a && b”. Combining all these types of syntax variations,
it can make the source code easier to read than a purely nested
structure. For example, common math expressions such as “3+2*5>7”
don't have to be written as “Greater[Plus[3,Times[2,5]],7]” or the
lispy “(> (+ 3 (* 2 5)) 7)”.
C and Perl
When we say that C is a infix notation language, the term “infix
notation” is used loosely for convenience of description. C and other
language's syntaxes derived from it (e.g. C++, Java, Perl,
Javascript...) are not based on a notation system, but takes the
approach of a ad hoc syntax soup. Things like “i++”, “++i”, “for(;;)
{}”, “while(){}”, 0x123, “sprint(...%s...,...)”, ... are syntax
whimsies.
As a side note, the Perl mongers are proud of their slogan of “There
Are More Than One Way To Do It” in their gazillion ad hoc syntax
sugars but unaware that in functional languages (such as Mathematica,
Haskell, Lisp) that there are consistent and generalized constructs
that can generate far more syntax variations than the ad hoc
inflexible Perl both in theory AND in practice. (in lisp, its power of
syntax variation comes in the guise of macros.) And, more importantly,
Perlers clamor about Perl's “expressiveness” more or less on the
syntax level but don't realize that semantic expressibility is far
more important.
Xah
···@xahlee.org
∑ http://xahlee.org/
Twisted wrote:
> On Jun 8, 7:30 pm, "Jürgen Exner" <········@hotmail.com> wrote:
>> ······@gmail.com wrote:
>>
>> [nothing relevant to Perl]
>
> Perl?? Perl is even less relevant to Java than the original post,
> which admittedly has some connection to pretty much all programming
> languages. (Perl, on the other hand, has no connection to any known
> programming language. ;) In particular, Perl code looks more like line
> noise than like code from any known programming language. ;))
Hmm - I know of APL and SNOBOL.
--
Lew
On Jun 9, 6:49 am, Lew <····@noemail.lewscanon.com> wrote:
> > In particular, Perl code looks more like line
> > noise than like code from any known programming language. ;))
>
> Hmm - I know of APL and SNOBOL.
>
> --
> Lew
TECO editor commands. I don't have direct experience with TECO, but
I've heard that a common diversion was to type random characters on
the command line, and see what the editor would do.
-- Paul
From: Kent M Pitman
Subject: Re: The Concepts and Confusions of Prefix, Infix, Postfix and Fully Functional Notations
Date:
Message-ID: <ud504hok7.fsf@nhplace.com>
[ comp.lang.lisp only on this reply.
http://www.nhplace.com/kent/PFAQ/cross-posting.html ]
Paul McGuire <·····@austin.rr.com> writes:
> On Jun 9, 6:49 am, Lew <····@noemail.lewscanon.com> wrote:
> > > In particular, Perl code looks more like line
> > > noise than like code from any known programming language. ;))
> >
> > Hmm - I know of APL and SNOBOL.
> >
> > --
> > Lew
>
> TECO editor commands. I don't have direct experience with TECO, but
> I've heard that a common diversion was to type random characters on
> the command line, and see what the editor would do.
Enter MythBusters mode...
Not that I ever saw. It was a common fantasy of people who didn't know
how TECO works. I'm sure the same is true of APL and other "line noise"
languages.
In TECO, the tokens were semantic elements. It's like saying that
something like a Chinese ideogram, because it's atomic and not
decomposed into letters, is something you could just randomly arrange
to make words. Well, sure. People have done that with English, too.
(If you've never tried m-x dissociated-press in emacs [an idea that is
not new to emacs but that, like m-x doctor copies an older idea from
older systems, incidentally], you might try that. Scrambling tokens
in random ways is sometimes fun.) But I daresay the practice is no more
common in TECO than in English or C++.
It's pretty dull, actually, because once you understand that "every token
is a word", that doesn't imply a lot more excitement in rearranging than
in English where you quickly learn that "every word is a word". Does that
make you want to rush out and rearrange them? :)
A better analogy might be instruction set byte codes. It's certainly
true that every integer is an instruction to do, but little fun is
gained by permuting integers randomly and seeing what instructions you
get. You quickly get lost in combinatorics, repetitions, and uselessness.
Finding palindromes or anagrams or other things like that is fun. (My
personal favorite is "enraged" and "angered" which are not only
anagrams but synonyms). But finding those is not an exercise
manipulating randomness as much as patience.
And besides, when we used languages like TECO, it was a luxury to have
interactive machine access at all. Often we had to wait for terminal
access. And TECO was not WYSIWYG because it was worried that was too
much computational overhead. So spending time on combinatorics was
not the name of the game.
Yes, this isn't the TECO newsgroup, so maybe it doesn't warrant
discussion. Too many newsgroups were cross-posted on the original and
I'm not about to join that fray. But I'll bring it back to LISP by
saying that perpetuating myths is often more fun than learning the
truth. People do that with LISP all the time, pretending we're
compilerless, missing important datatypes, etc. I like to imagine us
a culture that cares about keeping the record straight, so let's at least
know the truth among ourselves.
> Paul McGuire <····@austin.rr.com> writes:
> > TECO editor commands. I don't have direct experience with TECO, but
> > I've heard that a common diversion was to type random characters on
> > the command line, and see what the editor would do.
>
On Jun 9, 1:15 pm, Kent M Pitman <······@nhplace.com> wrote:
>
> Enter MythBusters mode...
>
> Not that I ever saw. It was a common fantasy of people who didn't know
> how TECO works. I'm sure the same is true of APL and other "line noise"
> languages.
>
> In TECO, the tokens were semantic elements.
I've never actually seen it either, but in a conversation once Yekta
Gürsel mentioned that his name wasn't too interesting to type into
TECO because the Y command just started reading all the subsequent
characters into the buffer.
From: Thomas A. Russ
Subject: Re: The Concepts and Confusions of Prefix, Infix, Postfix and Fully Functional Notations
Date:
Message-ID: <ymid502s4sh.fsf@sevak.isi.edu>
Sorry, I couldn't resist...
Kent M Pitman <······@nhplace.com> writes:
> It's pretty dull, actually, because once you understand that "every token
> is a word", that doesn't imply a lot more excitement in rearranging than
> in English where you quickly learn that "every word is a word". Does that
> make you want to rush out and rearrange them? :)
Doesn't imply a lot more excitement in rearranging than in English where
you quickly learn that "every word", that "every token ish where you
quickly learn that "every word is a word". Does that make you want to
rush ou understand that doesn't imply a learrant to rush out a word".
--
Thomas A. Russ, USC/Information Sciences Institute
From: Larry Clapp
Subject: Re: The Concepts and Confusions of Prefix, Infix, Postfix and Fully Functional Notations
Date:
Message-ID: <slrnf6revq.caa.larry@theclapp.ddts.net>
On 2007-06-11, Thomas A. Russ <···@sevak.isi.edu> wrote:
> Sorry, I couldn't resist...
Next time ... try harder. ;)
From: BCB
Subject: Re: The Concepts and Confusions of Prefix, Infix, Postfix and Fully Functional Notations
Date:
Message-ID: <0uHai.176367$nh4.13819@newsfe20.lga>
"Paul McGuire" <·····@austin.rr.com> wrote in message
·····························@g4g2000hsf.googlegroups.com...
> On Jun 9, 6:49 am, Lew <····@noemail.lewscanon.com> wrote:
>> > In particular, Perl code looks more like line
>> > noise than like code from any known programming language. ;))
>>
>> Hmm - I know of APL and SNOBOL.
>>
>> --
>> Lew
>
> TECO editor commands. I don't have direct experience with TECO, but
> I've heard that a common diversion was to type random characters on
> the command line, and see what the editor would do.
>
> -- Paul
>
J
http://www.jsoftware.com/
On Jun 9, 8:21 pm, "BCB" <····@undisclosedlocation.net> wrote:
> "Paul McGuire" <····@austin.rr.com> wrote in message
>
> ·····························@g4g2000hsf.googlegroups.com...
>
> > On Jun 9, 6:49 am, Lew <····@noemail.lewscanon.com> wrote:
> >> > In particular, Perl code looks more like line
> >> > noise than like code from any known programming language. ;))
>
> >> Hmm - I know of APL and SNOBOL.
>
> >> --
> >> Lew
>
> > TECO editor commands. I don't have direct experience with TECO, but
> > I've heard that a common diversion was to type random characters on
> > the command line, and see what the editor would do.
>
> > -- Paul
>
> J
>
> http://www.jsoftware.com/
Oh come on! Toy languages (such as any set of editor commands) and
joke languages (ala Intercal) don't count, even if they are
technically Turing-complete. ;)
Nor does anything that was designed for the every-character-at-a-
premium punch-card era, particularly if it is, or rhymes with,
"COBOL".
Those have excuses, like it's a joke or it's a constrained
environment. Perl, unfortunately, has no such excuses. If there were
such a thing as "embedded Perl", I'd have to hesitate here, but since
there isn't...
From: Larry Elmore
Subject: Re: The Concepts and Confusions of Prefix, Infix, Postfix and Fully Functional Notations
Date:
Message-ID: <0G_ai.1970$xg4.809@trnddc08>
Twisted wrote:
> On Jun 9, 8:21 pm, "BCB" <····@undisclosedlocation.net> wrote:
>> "Paul McGuire" <····@austin.rr.com> wrote in message
>>
>> ·····························@g4g2000hsf.googlegroups.com...
>>
>>> On Jun 9, 6:49 am, Lew <····@noemail.lewscanon.com> wrote:
>>>>> In particular, Perl code looks more like line
>>>>> noise than like code from any known programming language. ;))
>>>> Hmm - I know of APL and SNOBOL.
>>>> --
>>>> Lew
>>> TECO editor commands. I don't have direct experience with TECO, but
>>> I've heard that a common diversion was to type random characters on
>>> the command line, and see what the editor would do.
>>> -- Paul
>> J
>>
>> http://www.jsoftware.com/
>
> Oh come on! Toy languages (such as any set of editor commands) and
> joke languages (ala Intercal) don't count, even if they are
> technically Turing-complete. ;)
>
> Nor does anything that was designed for the every-character-at-a-
> premium punch-card era, particularly if it is, or rhymes with,
> "COBOL".
>
> Those have excuses, like it's a joke or it's a constrained
> environment. Perl, unfortunately, has no such excuses. If there were
> such a thing as "embedded Perl", I'd have to hesitate here, but since
> there isn't...
Neither APL nor Snobol nor J are toy or joke languages.
On Jun 10, 3:11 pm, Larry Elmore <········@verizon.spammenot.net>
wrote:
> Twisted wrote:
> > On Jun 9, 8:21 pm, "BCB" <····@undisclosedlocation.net> wrote:
> >> "Paul McGuire" <····@austin.rr.com> wrote in message
>
> >>·····························@g4g2000hsf.googlegroups.com...
>
> >>> On Jun 9, 6:49 am, Lew <····@noemail.lewscanon.com> wrote:
> >>>>> In particular, Perl code looks more like line
> >>>>> noise than like code from any known programming language. ;))
> >>>> Hmm - I know of APL and SNOBOL.
> >>>> --
> >>>> Lew
> >>> TECO editor commands. I don't have direct experience with TECO, but
> >>> I've heard that a common diversion was to type random characters on
> >>> the command line, and see what the editor would do.
> >>> -- Paul
> >> J
>
> >>http://www.jsoftware.com/
>
> > Oh come on! Toy languages (such as any set of editor commands) and
> > joke languages (ala Intercal) don't count, even if they are
> > technically Turing-complete. ;)
>
> > Nor does anything that was designed for the every-character-at-a-
> > premium punch-card era, particularly if it is, or rhymes with,
> > "COBOL".
>
> > Those have excuses, like it's a joke or it's a constrained
> > environment. Perl, unfortunately, has no such excuses. If there were
> > such a thing as "embedded Perl", I'd have to hesitate here, but since
> > there isn't...
>
> Neither APL nor Snobol nor J are toy or joke languages.
I'd like register my agreement. SNOBOL was a very sophisticated
language and way ahead of its time in many ways. While it's not
really used anymore, SNOBOL's legacy does live on in languages that
are in wide use.
APL and it's successors (including J & K) are neither toys nor extinct
relics. APL is still used in a variety of applications. The price of
the last airline ticket you bought was probably determined by a yield
management application written in APL. K was created in 1993 and Kx
systems has built an incredibly valuable company on top of it.
APL's terseness has more to do with the Iverson's notational goals
than economy with characters related to punchcards. In fact, the
dominant languages of the punchcard era (COBOL & FORTRAN) are both
pretty verbose.
Lastly, ITS Teco wasn't a joke or toy language either.. It was
psychotically terse and virtually impenetrable to later review. But
it wasn't a toy. When I learned to use EMACS, it was still
implemented in ITS Teco.
From: Mark Hoemmen
Subject: Re: The Concepts and Confusions of Prefix, Infix, Postfix and Fully Functional Notations
Date:
Message-ID: <f4i5rj$243h$1@geode.berkeley.edu>
Reilly wrote:
> APL and it's successors (including J & K) are neither toys nor extinct
> relics. APL is still used in a variety of applications. The price of
> the last airline ticket you bought was probably determined by a yield
> management application written in APL. K was created in 1993 and Kx
> systems has built an incredibly valuable company on top of it.
APL also had indirect (or even direct, in some cases) influence on other
languages' operations involving vectors or collections. For instance,
SGI's extensions to the C++ STL include an "iota" function which does
pretty much what APL's iota function does. Matlab probably takes a lot
of cues from APL too.
What's with all the cross-posting? ;-P
mfh
Twisted wrote:
>> Oh come on! Toy languages (such as any set of editor commands) and
>> joke languages (ala Intercal) don't count, even if they are
>> technically Turing-complete. ;)
>>
>> Nor does anything that was designed for the every-character-at-a-
>> premium punch-card era, particularly if it is, or rhymes with,
>> "COBOL".
>>
>> Those have excuses, like it's a joke or it's a constrained
>> environment. Perl, unfortunately, has no such excuses. If there were
>> such a thing as "embedded Perl", I'd have to hesitate here, but since
>> there isn't...
Larry Elmore wrote:
> Neither APL nor Snobol nor J are toy or joke languages.
Indeed. One wonders where Perl would be if Snobol hadn't preceded it.
--
Lew
From: BCB
Subject: Re: The Concepts and Confusions of Prefix, Infix, Postfix and Fully Functional Notations
Date:
Message-ID: <X_0bi.22045$6z4.11682@newsfe19.lga>
<snip>
>
> Neither APL nor Snobol nor J are toy or joke languages
I wholeheartedly agree, and did not mean to imply as much in my original
post, in which my intent was to emphasize the fact that, until you learn the
language, a J program /does/ resemble line noise! :-)
On Jun 10, 8:50 pm, "BCB" <····@undisclosedlocation.net> wrote:
> I wholeheartedly agree, and did not mean to imply as much in my original
> post, in which my intent was to emphasize the fact that, until you learn the
> language, a J program /does/ resemble line noise! :-)
Eh. This isn't right. The whole discussion was supposed to have died
after the original Perl joke, certainly after the subsequent exclusion
of joke and toy languages. I think I made it clear also that an
editor's command set, Turing-complete though it may be, constitutes a
toy language. Anyway I amend the original claim to cover joke
languages, toy languages, and any write-only languages that
mysteriously aren't considered to fall into either of the former two
categories. After all, you can't really take a language seriously if
it's either impossible to write unmaintainable code in it OR
impossible to write maintainable code in it. The one is necessarily
trivial, and the other unsuitable for anything serious, except as a
machine-compiled intermediate format or a mechanism for assuring job
security.
From: Joachim Durchholz
Subject: Re: The Concepts and Confusions of Prefix, Infix, Postfix and Fully Functional Notations
Date:
Message-ID: <f4iqmk$u64$1@online.de>
Twisted schrieb:
> After all, you can't really take a language seriously if
> it's either impossible to write unmaintainable code in it
That's true for any language.
Substitute "not straightforward" for "impossible", and you have a
condition that actually distinguishes languages.
> OR impossible to write maintainable code in it.
It is possible to write maintainable Perl.
It's just too easy to write unmaintainable Perl.
Also, a Perl "golfer" and an intermediate Perl programmer will have
quite different ideas about what idioms should be considered
maintainable. (I consider Perl's mantra of "many ways to express it" to
be a weakness, not a strength, since it lengthens the learning curve
considerably and doesn't buy much. YMMV.)
Regards,
Jo
On Jun 11, 2:42 am, Joachim Durchholz <····@durchholz.org> wrote:
> It is possible to write maintainable Perl.
Interesting (spoken in the tone of someone hearing about a purported
sighting of Bigfoot, or maybe a UFO).
Still, extraordinary claims require extraordinary evidence. (And no, a
fuzzy picture of something that might be a giant serpent-like thing in
the loch, or equivalent, does not constitute "extraordinary
evidence".)
From: Joachim Durchholz
Subject: Re: The Concepts and Confusions of Prefix, Infix, Postfix and Fully Functional Notations
Date:
Message-ID: <f4iuse$3hl$1@online.de>
Twisted schrieb:
> On Jun 11, 2:42 am, Joachim Durchholz <····@durchholz.org> wrote:
>> It is possible to write maintainable Perl.
>
> Interesting (spoken in the tone of someone hearing about a purported
> sighting of Bigfoot, or maybe a UFO).
>
> Still, extraordinary claims require extraordinary evidence. (And no, a
> fuzzy picture of something that might be a giant serpent-like thing in
> the loch, or equivalent, does not constitute "extraordinary
> evidence".)
There's enough Perl code around. Including some that's been reported as
maintainable and well-maintained.
I haven't looked too deeply into it, but what I have seen from e.g.
Webmin looked quite clear and straightforward to me. (Real Programmers
can write Fortran code in any language - and they can write Pascal code
in any language...)
Perl code *can* resemble line noise. I don't like the language. I think
Larry and the Perl community have been getting some priorities very
wrong over time (and other things very right as well: take a look at the
regex redesign for Perl 6, for example - it's all shades of grey, not
black-and-white).
Regards,
Jo
On Jun 11, 8:02 am, Twisted <··········@gmail.com> wrote:
> On Jun 11, 2:42 am, Joachim Durchholz <····@durchholz.org> wrote:
>
> > It is possible to write maintainable Perl.
>
> Interesting (spoken in the tone of someone hearing about a purported
> sighting of Bigfoot, or maybe a UFO).
>
I think it's just obvious that this is the case. What would *stop*
you writing maintainable Perl?
On Jun 11, 5:36 pm, Tim Bradshaw <··········@tfeb.org> wrote:
> I think it's just obvious that this is the case. What would *stop*
> you writing maintainable Perl?
For starters, the fact that there are about six zillion obscure
operators represented by punctuation marks, instead of a dozen or so.
More generally, the fact that it comes out looking like modem barf,
and modem barf is unmaintainable. ;)
From: Joachim Durchholz
Subject: Re: The Concepts and Confusions of Prefix, Infix, Postfix and Fully Functional Notations
Date:
Message-ID: <f4lj0r$ccb$1@online.de>
Twisted schrieb:
> On Jun 11, 5:36 pm, Tim Bradshaw <··········@tfeb.org> wrote:
>> I think it's just obvious that this is the case. What would *stop*
>> you writing maintainable Perl?
>
> For starters, the fact that there are about six zillion obscure
> operators represented by punctuation marks, instead of a dozen or so.
> More generally, the fact that it comes out looking like modem barf,
> and modem barf is unmaintainable. ;)
You can write Perl that uses just a dozen or so punctuation marks, so
that doesn't stop you (or anybody else) from writing maintainable Perl.
You haven't looked into the Webmin code that I gave for an example, have
you? You'd have seen code that's quite far from line noise. (But
sticking with prejudice can be more fun, I know...)
If anything, the real criticism is that it's easy to write
unmaintainable Perl, so there's too much of unmaintainable Perl around.
The other criticism is that Perl's learning curve is needlessly
prolonged because you need time to pick up all those idioms that are
possible - nice for those who're doing Perl and just Perl, horror for
those who usually work in other languages.
I don't know of any other serious design flaws in the language, given
its design goals. (When designing a scripting/glue language today, I'd
set up slightly different design goals, of course. Perl is far from the
optimum that should be used today, its main merits are its ubiquity and
completeness, not the language qualities.)
Regards,
Jo
From: Daniel Barlow
Subject: Re: The Concepts and Confusions of Prefix, Infix, Postfix and Fully Functional Notations
Date:
Message-ID: <1181614274.14141.0@proxy02.news.clara.net>
Tim Bradshaw wrote:
> I think it's just obvious that this is the case. What would *stop*
> you writing maintainable Perl?
A grudge against humanity, usually
-dan
On Jun 11, 11:36 pm, Tim Bradshaw <··········@tfeb.org> wrote:
> On Jun 11, 8:02 am, Twisted <··········@gmail.com> wrote:
>
> > On Jun 11, 2:42 am, Joachim Durchholz <····@durchholz.org> wrote:
>
> > > It is possible to write maintainable Perl.
>
> > Interesting (spoken in the tone of someone hearing about a purported
> > sighting of Bigfoot, or maybe a UFO).
>
> I think it's just obvious that this is the case. What would *stop*
> you writing maintainable Perl?
The constantly shifting target of a language. Hell, even the parser
has changed over time. Fortunately this seems to have been solved by
Perl 6 [*].
[*] Stopping work on Perl 5 to focus on the probably never-to-be Perl
6 brought a surprising stability to the language.
From: Peter J. Holzer
Subject: Re: The Concepts and Confusions of Prefix, Infix, Postfix and Fully Functional Notations
Date:
Message-ID: <slrnf7893i.2aq.hjp-usenet2@zeno.hjp.at>
["Followup-To:" header set to comp.lang.perl.misc.]
On 2007-06-12 08:15, Thomas F. Burdick <········@gmail.com> wrote:
> On Jun 11, 11:36 pm, Tim Bradshaw <··········@tfeb.org> wrote:
>> On Jun 11, 8:02 am, Twisted <··········@gmail.com> wrote:
>>
>> > On Jun 11, 2:42 am, Joachim Durchholz <····@durchholz.org> wrote:
>>
>> > > It is possible to write maintainable Perl.
>>
>> > Interesting (spoken in the tone of someone hearing about a purported
>> > sighting of Bigfoot, or maybe a UFO).
>>
>> I think it's just obvious that this is the case. What would *stop*
>> you writing maintainable Perl?
>
> The constantly shifting target of a language. Hell, even the parser
> has changed over time.
As with any other language I know, too (well, maybe cobol hasn't changed
in the last 10 years - I haven't looked lately).
The grammar of perl hasn't changed much since perl 5.0, which was
released in 1994. There were a few minor additions, but just about every
perl 5.0 script would still run with perl 5.8.x.
Try getting to run 13 year old C++ code with a current compiler some
time ...
> Fortunately this seems to have been solved by
> Perl 6 [*].
>
> [*] Stopping work on Perl 5 to focus on the probably never-to-be Perl
> 6 brought a surprising stability to the language.
Perl 6 started in 2000, AFAIR, when 5.005_03 was the stable release of
perl5 (with development on perl 5.6 well on the way, yes).
Maybe my memory is faulty but I don't have the impression that there was
much more change in the six years between 5.0 and and 5.005_03 than in the
seven years between 5.005 and 5.8.8 (despite everybody complaining that
perl (not Perl) is essentially unmaintable).
hp
--
_ | Peter J. Holzer | I know I'd be respectful of a pirate
|_|_) | Sysadmin WSR | with an emu on his shoulder.
| | | ···@hjp.at |
__/ | http://www.hjp.at/ | -- Sam in "Freefall"
From: Patricia Shanahan
Subject: Re: The Concepts and Confusions of Prefix, Infix, Postfix and Fully Functional Notations
Date:
Message-ID: <f4kr23$317v$1@ihnp4.ucsd.edu>
Twisted wrote:
> On Jun 11, 2:42 am, Joachim Durchholz <····@durchholz.org> wrote:
>> It is possible to write maintainable Perl.
>
> Interesting (spoken in the tone of someone hearing about a purported
> sighting of Bigfoot, or maybe a UFO).
>
> Still, extraordinary claims require extraordinary evidence. (And no, a
> fuzzy picture of something that might be a giant serpent-like thing in
> the loch, or equivalent, does not constitute "extraordinary
> evidence".)
>
How about "I caught a very small one, but it belonged to a former
employer, so I couldn't keep it for display."?
I wrote a Perl script to process logic analyzer traces for some hardware
engineers. While I was out of the office, they found they needed to
process a new record type. They didn't want to delay their work until I
got back, and one of the EEs knew Perl, so he modified my script.
The change was done correctly. It not only worked. Except for a couple
of comments calling my attention to the changes, it looked as though
the new record type had always been there.
Patricia
From: Vassil Nikolov
Subject: Re: The Concepts and Confusions of Prefix, Infix, Postfix and Fully Functional Notations
Date:
Message-ID: <ka8xaqq6ng.fsf@localhost.localdomain>
On Mon, 11 Jun 2007 17:57:35 -0700, Patricia Shanahan <····@acm.org> said:
| ...
| The change was done correctly. It not only worked. Except for a couple
| of comments calling my attention to the changes, it looked as though
| the new record type had always been there.
"We few, we happy few..." ---The Globe Hacker.
---Vassil.
--
What is the right way to collinearize a cross-post?
On Jun 11, 8:57 pm, Patricia Shanahan <····@acm.org> wrote:
> I wrote a Perl script to process logic analyzer traces for some hardware
> engineers. While I was out of the office, they found they needed to
> process a new record type. They didn't want to delay their work until I
> got back, and one of the EEs knew Perl, so he modified my script.
>
> The change was done correctly. It not only worked. Except for a couple
> of comments calling my attention to the changes, it looked as though
> the new record type had always been there.
*blinks*
Hallelujah! It's a miracle! Praise be the Lord! This must surely be a
sign...
a sign of the End Times. :P