# The Concepts and Confusions of Prefix, Infix, Postfix and Fully Functional Notations

Discussion in 'Python' started by Xah Lee, May 23, 2007.

1. ### Xah LeeGuest

The Concepts and Confusions of Prefix, Infix, Postfix and Fully
Functional Notations

Xah Lee, 2006-03-15

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

âˆ‘ http://xahlee.org/

Xah Lee, May 23, 2007

2. ### Larry ClappGuest

On 2007-05-23, Xah Lee <> 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

Larry Clapp, May 23, 2007

3. ### Markus E LeypoldGuest

Re: The Concepts and Confusions of Prefix, Infix, Postfix and FullyFunctional Notations

> On 2007-05-23, Xah Lee <> 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

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, May 23, 2007
4. ### Jon HarropGuest

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

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

Jon Harrop, May 29, 2007
5. ### Ville OikarinenGuest

3D libraries (was The Concepts and Confusions of Prefix, Infix,Postfix and Fully Functional Notations)

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

Ville Oikarinen, May 29, 2007
6. ### Ulf WigerGuest

>>>>> "Jon" == Jon Harrop <> 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

Ulf Wiger, May 29, 2007
7. ### Tony FinchGuest

vector graphics bindings, was Re: The Concepts and Confusions of Prefix, Infix, Postfix and Fully Functional Notations

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)?

http://www.cairographics.org/bindings/
That covers all the languages you named, plus O'Caml and Haskell.

Tony.
--
f.a.n.finch <> 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.

Tony Finch, May 29, 2007
8. ### Xah LeeGuest

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
]

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

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 â€œf@argâ€.
Essentially, a prefix notation in this context limits it to uses for
functions on only one argument. For example: â€œf@a@b@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 â€œSin@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

âˆ‘ http://xahlee.org/

Xah Lee, May 30, 2007
9. ### Guest

How Purely Nested Notation Limits The Language's Utility

[The full HTML formatted article is available at:
http://xahlee.org/UnixResource_dir/writ/notations.html
]

2007-05-03

There is a common complain by programers about lisp's notation, of
nested parenthesis, being unnatural or difficult to read. Long time
lisp programers, often counter, that it is a matter of conditioning,
and or blaming the use of â€œinferiorâ€ text editors that are not
designed to display nested notations. In the following, i describe how
lisp notation is actually a problem, in several levels.

(1) Some 99% of programers are not used to the nested parenthesis
syntax. This is a practical problem. On this aspect along, lisp's
syntax can be considered a problem.

(2) Arguably, the pure nested syntax is not natural for human to read.
Long time lispers may disagree on this point.

(3) Most importantly, a pure nested syntax discourages frequent or
advanced use of function sequencing or compositions. This aspect is
the most devastating.

The first issue, that most programers are not comfortable with nested
notation, is well known. It is not a technical issue. Whether it is
considered a problem of the lisp language is a matter of philosophical
disposition.

The second issue, about nested parenthesis not being natural for human
to read, may be debatable. I do think, that deep nesting is a problem
to the programer. Here's a example of 2 blocks of code that are
syntactically equivalent in the Mathematica language:

vectorAngle[{a1_, a2_}] := Module[{x, y},
{x, y} = {a1, a2}/Sqrt[a1^2 + a2^2] // N;
If[x == 0, If[Sign@y === 1, Ï€/2, -Ï€/2],
If[y == 0, If[Sign@x === 1, 0, Ï€],
If[Sign@y === 1, ArcCos@x, 2 Ï€ - ArcCos@x]
]
]
]

SetDelayed[vectorAngle[List[Pattern[a1,Blank[]],Pattern[a2,Blank[]]]],
Module[List[x,y],
CompoundExpression[
Set[List[x,y],
N[Times[List[a1,a2],
Power[Sqrt[Plus[Power[a1,2],Power[a2,2]]],-1]]]],
If[Equal[x,0],
If[SameQ[Sign[y],1],Times[Ï€,Power[2,-1]],
Times[Times[-1,Ï€],Power[2,-1]]],
If[Equal[y,0],If[SameQ[Sign[x],1],0,Ï€],
If[SameQ[Sign[y],1],ArcCos[x],
Plus[Times[2,Ï€],Times[-1,ArcCos[x]]]]]]]]]

In the latter, it uses a full nested form (called FullForm in
Mathematica). This form is isomorphic to lisp's nested parenthesis
syntax, token for token (i.e. lisp's â€œ(f a b)â€ is Mathematica's
â€œf[a,b]â€). As you can see, this form, by the sheer number of nested
brackets, is in practice problematic to read and type. In Mathematica,
nobody really program using this syntax. (The FullForm syntax is
there, for the same reason of language design principle shared with
lisp of â€œconsistency and simplicityâ€, or the commonly touted lisp
advantage of â€œdata is program; program is dataâ€.)

The third issue, about how nested syntax seriously discourages
frequent or advanced use of inline function sequencing on the fly, is
the most important and I'll give further explanation below.

One practical way to see how this is so, is by considering unix's
shell syntax. You all know, how convenient and powerful is the unix's
pipes. Here are some practical example: â€œls -al | grep xyzâ€, or â€œcat a
b c | grep xyz | sort | uniqâ€.

Now suppose, we get rid of the unix's pipe notation, instead, replace
it with a pure functional notation: e.g. (uniq (sort (grep xyz (cat a
b c)))), or enrich it with a composition function and a pure function
construct (Î»), so this example can be written as: ((composition uniq
sort (lambda (x) (grep xyz x))) (cat a b c)).

You see, how this change, although syntactically equivalent to the
pipe â€œ|â€ (or semantically equivalent in the example using function
compositions), but due to the cumbersome nested syntax, will force a
change in the nature of the language by the code programer produces.
Namely, the frequency of inline sequencing of functions on the fly
will probably be reduced, instead, there will be more code that define
functions with temp variables and apply it just once as with

A language's syntax or notation system, has major impact on what kind
of code or style or thinking pattern on the language's users. This is
a well-known fact for those acquainted with the history of math
notations.

The sequential notation â€œf@g@h@xâ€, or â€œx//h//g//fâ€, or unixy â€œx|h|g|
fâ€, are far more convenient and easier to decipher, than â€œ(f (g (h
x)))â€ or â€œ((composition f g h) x)â€. In actual code, any of the f, g, h
might be a complex pure function (aka lambda constructs, full of
parenthesis themselves).

Lisp, by sticking with a almost uniform nested parenthesis notation,
it immediately reduces the pattern of sequencing functions, simply
because the syntax does not readily lend the programer to it as in the
unix's â€œx|h|g|fâ€. For programers who are aware of the coding pattern
of sequencing functions, now either need to think in terms of a
separate â€œcompositionâ€ construct, and or subject to the much
problematic typing and deciphering of nested parenthesis.

(Note: Lisp's sexp is actually not that pure. It has ad hoc syntax
equivalents such as the â€œquoteâ€ construct â€œ '(a b c) â€, and also â€œ`â€,
â€œ#â€, â€œ,@â€ constructs, precisely for the purpose of reducing
parenthesis and increasing readability. Scheme's coming standard the
R6RS â†—, even proposes the introduction of [] and {} and few other
syntax sugars to break the uniformity of nested parenthesis for
legibility. Mathematica's FullForm, is actually a version of
unadulterated nested notation as can be.)

Xah

âˆ‘ http://xahlee.org/

, Jun 8, 2007
10. ### Jürgen ExnerGuest

wrote:
[nothing relevant to Perl]

Oh no, it is back.
Did your ISP finally cancel your old account or why are you switching to a
Don't try to disguise yourself. Your 'contributions' can easily be
identified no matter what pseudonym you are using.

***PLONK AGAIN***

jue

Jürgen Exner, Jun 9, 2007
11. ### TwistedGuest

On Jun 8, 7:30 pm, "Jürgen Exner" <> wrote:
> 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. )

Twisted, Jun 9, 2007
12. ### LewGuest

Re: The Concepts and Confusions of Prefix, Infix, Postfix and FullyFunctional Notations

Twisted wrote:
> On Jun 8, 7:30 pm, "JÃ¼rgen Exner" <> wrote:
>> 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

Lew, Jun 9, 2007
13. ### Paul McGuireGuest

On Jun 9, 6:49 am, Lew <> 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

Paul McGuire, Jun 9, 2007
14. ### BCBGuest

"Paul McGuire" <> wrote in message
news:...
> On Jun 9, 6:49 am, Lew <> 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/

BCB, Jun 10, 2007
15. ### TwistedGuest

On Jun 9, 8:21 pm, "BCB" <> wrote:
> "Paul McGuire" <> wrote in message
>
> news:...
>
> > On Jun 9, 6:49 am, Lew <> 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...

Twisted, Jun 10, 2007
16. ### Larry ElmoreGuest

Re: The Concepts and Confusions of Prefix, Infix, Postfix and FullyFunctional Notations

Twisted wrote:
> On Jun 9, 8:21 pm, "BCB" <> wrote:
>> "Paul McGuire" <> wrote in message
>>
>> news:...
>>
>>> On Jun 9, 6:49 am, Lew <> 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.

Larry Elmore, Jun 10, 2007
17. ### LewGuest

Re: The Concepts and Confusions of Prefix, Infix, Postfix and FullyFunctional Notations

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

Lew, Jun 10, 2007
18. ### ReillyGuest

On Jun 10, 3:11 pm, Larry Elmore <>
wrote:
> Twisted wrote:
> > On Jun 9, 8:21 pm, "BCB" <> wrote:
> >> "Paul McGuire" <> wrote in message

>
> >>news:...

>
> >>> On Jun 9, 6:49 am, Lew <> 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

>
>
> > 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.

Reilly, Jun 11, 2007
19. ### BCBGuest

<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!

BCB, Jun 11, 2007
20. ### TwistedGuest

On Jun 10, 8:50 pm, "BCB" <> 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.

Twisted, Jun 11, 2007