In another thread I wrote:
> Another example [of Greenspun's 10th law]: Mathematica is
> essentially a Lisp engine inside.
Although it's poor form to follow up one's own posts, I thought that
y'all might find these interesting (or funny, or sad, or scary)
excerpts from the Mathematica manual. [[Double brackets in the
following enclose my notes]]
===============================================
1.12.2 Basic Internal Architecture
...
When you type input into Mathematica, a data structure is created in
the memory of your computer to represent the expression you have
entered.
In general, different pieces of your expression will be stored at
different places in memory. Thus, for example, for a list such as {2,
x, y + z} the "backbone" of the list will be stored at one
place, while each of the actual elements will be stored at a different
place.
The backbone of the list then consists just of three "pointers"
that specify the addresses in computer memory at which the actual
expressions that form the elements of the list are to be found. These
expressions then in turn contain pointers to their subexpressions. The
chain of pointers ends when one reaches an object such as a number or
a string, which is stored directly as a pattern of bits in computer
memory.
Crucial to the operation of Mathematica is the notion of symbols such
as x. Whenever x appears in an expression, Mathematica represents it
by a pointer. But the pointer is always to the same place in computer
memory-an entry in a central table of all symbols defined in your
Mathematica session.
This table is a repository of all information about each symbol. It
contains a pointer to a string giving the symbol's name, as well as
pointers to expressions which give rules for evaluating the symbol.
The basic principle of Mathematica memory management.
Every piece of memory used by Mathematica maintains a count of how
many pointers currently point to it. When this count drops to zero,
Mathematica knows that the piece of memory is no longer being
referenced, and immediately makes the piece of memory available for
something new.
===============================================
2.1.1 Everything Is an Expression
Mathematica handles many different kinds of things: mathematical
formulas, lists and graphics, to name a few. Although they often look
very different, Mathematica represents all of these things in one
uniform way. They are all expressions.
A prototypical example of a Mathematica expression is f[x, y]. You
might use f[x, y] to represent a mathematical function a. The function
is named f, and it has two arguments, x and y.
You do not always have to write expressions in the form f[x, y, ...
]. For example, x + y is also an expression. When you type in x + y,
Mathematica converts it to the standard form Plus[x, y]. Then, when it
prints it out again, it gives it as x + y.
The same is true of other "operators", such as ^ (Power) and /
(Divide).
In fact, everything you type into Mathematica is treated as an
expression.
You can see the full form of any expression by using FullForm[expr].
Here is an expression.
In: x + y + z
Out: x + y + z
This is the full form of the expression.
In: FullForm[%]
Out: Plus[x, y, z]
Here is another expression.
In: 1 + x^2 + (y + z)^2
...
In: FullForm[%]
Out: Plus[1, Power[x, 2], Power[Plus[y, z], 2]]
The object f in an expression f[x, y, ... ] is known as the head of
the expression. You can extract it using Head[expr]. Particularly when
you write programs in Mathematica, you will often want to test the
head of an expression to find out what kind of thing the expression
is.
...
===============================================
2.1.6 Expressions as Trees
[[I won't bore you with the contents of this section. You get the
idea. On to scarier stuff...]]
===============================================
2.2.1 Function Names as Expressions
...
The ability to treat the names of functions just like other kinds of
expressions is an important consequence of the symbolic nature of the
Mathematica language. It makes possible the whole range of functional
operations discussed in the sections that follow.
Ordinary Mathematica functions such as Log or Integrate typically
operate on data such as numbers and algebraic expressions. Mathematica
functions that represent functional operations, however, can operate
not only on ordinary data, but also on functions themselves. Thus, for
example, the functional operation InverseFunction takes a Mathematica
function name as an argument, and represents the inverse of that
function.
...
>>>>> Unless you are familiar with advanced symbolic languages, you
will probably not recognize most of the functional operations
discussed in the sections that follow. At first, the operations may
seem difficult to understand. But it is worth persisting. Functional
operations provide one of the most conceptually and practically
efficient ways to use Mathematica. <<<<<<<<< [[>Emphasis added<]]
...
===============================================
2.2.5 Pure Functions [[aka: LAMBDA]]
When you use functional operations such as Nest and Map, you always
have to specify a function to apply. In all the examples above, we
have used the "name" of a function to specify the function. Pure
functions allow you to give functions which can be applied to
arguments, without having to define explicit names for the functions.
If you are going to use a particular function repeatedly, then you can
define the function using f[x_] := body, and refer to the function by
its name f. On the other hand, if you only intend to use a function
once, you will probably find it better to give the function in pure
function form, without ever naming it.
If you are familiar with formal logic or the LISP programming
language, you will recognize Mathematica pure functions as being like
LAMBDA expressions or anonymous functions. Pure functions are also
close to the pure mathematical notion of operators. [[This is straight
from the manual!]]
...
[[Okay, you asked for terrible syntax, here's the king of terrible
syntax!]]
Just as the name of a function is irrelevant if you do not intend to
refer to the function again, so also the names of arguments in a pure
function are irrelevant. Mathematica allows you to avoid using
explicit names for the arguments of pure functions, and instead to
specify the arguments by giving "slot numbers" #n. In a Mathematica
pure function, #n stands for the na argument you supply. # stands for
the first argument.
...
In: Map[Take[#, 2]&, {{2, 1, 7}, {4, 1, 5}, {3, 1, 2}}]
Out: {{2, 1}, {4, 1}, {3, 1}}
...
[[Eamples of a Lambda expression inside another (named) function:]]
In: fromdigits[digits_] := Fold[(10 #1 + #2)&, 0, digits]
...
When you use short forms for pure functions, it is very important that
you do not forget the ampersand. If you leave the ampersand out,
Mathematica will not know that the expression you give is to be used
as a pure function.
[[I like the pun between the shape of the & and LAMBDA!]]
When you use the ampersand notation for pure functions, you must be
careful about the grouping of pieces in your input. As shown in
Section A.2.7 the ampersand notation has fairly low precedence, which
means that you can type expressions like #1 + #2 & without
parentheses. On the other hand, if you want, for example, to set an
option to be a pure function, you need to use parentheses, as in
option -> (fun &).
...
===============================================
2.7.7 Blocks Compared with Modules
...
Most traditional computer languages use a so-called
"lexical scoping" mechanism for variables, which is analogous to the
module mechanism in Mathematica. Some symbolic computer languages such
as LISP also allow "dynamic scoping", analogous to Mathematica blocks.
===============================================
2.7.8 Contexts
...
In Mathematica, you can use the notion of "contexts" to organize
the names of symbols. Contexts are particularly important in
Mathematica packages which introduce symbols whose names must not
conflict with those of any other symbols. If you write Mathematica
packages, or make sophisticated use of packages that others have
written, then you will need to know about contexts.
The basic idea is that the full name of any symbol is broken into two
parts: a context and a short name. The full name is written as
context`short, where the ` is the backquote or grave accent character
(ASCII decimal code 96), called a "context mark" in Mathematica.
[[I'll do this by demonstration:]]
In[1]:= InscribedRadius
Out[1]= InscribedRadius
;;; Oops: I forgot to load Polytops package!
In[2]:= <<Geometry`Polytopes`
>From In[2]:= Symbol "InscribedRadius" appears in multiple contexts
definitions in context "Geometry`Polytopes" may shadow
or be shadowed by other definitions. More...
[[And in the More... it tells me:]]
* This message occurs most often when loading packages that introduce
symbols with the same names as symbols that have already been entered
or that have been introduced by other packages.
* If symbols with the same name exist in more than one context, the
name will refer to the symbol that occurs first in the context search
path. Any symbol can be accessed by entering the full context name of
the symbol.
*Unwanted symbols can be removed using Remove.
From: Markus Grueneis
Subject: Re: That's not Ridiculous Syntax... THIS is Ridiculous Syntax! (And REALLY expensive software!)
Date:
Message-ID: <4krqk4Fdgq3aU1@individual.net>
········@gmail.com schrieb:
> In another thread I wrote:
>
>> Another example [of Greenspun's 10th law]: Mathematica is
>> essentially a Lisp engine inside.
>
> Although it's poor form to follow up one's own posts, I thought that
> y'all might find these interesting (or funny, or sad, or scary)
> excerpts from the Mathematica manual. [[Double brackets in the
> following enclose my notes]]
>
> [snipped the holy manual stuff...]
If you think Mathematica adds noisy syntax, then try Maple. (By the way,
what do think is the more popular CAS among all students in our
mathematics-department? You guess it.)
Mathematica isn't that bad beside. Especially it's special treatment of
errors, or the glorious victory of the manual at hiding any useful
information in places where you the least expect it. Just my 0.02€.
-mg
········@gmail.com wrote:
> In another thread I wrote:
>
> > Another example [of Greenspun's 10th law]: Mathematica is
> > essentially a Lisp engine inside.
>
> Although it's poor form to follow up one's own posts, I thought that
> y'all might find these interesting (or funny, or sad, or scary)
> excerpts from the Mathematica manual. [[Double brackets in the
> following enclose my notes]]
You think that's bad.
Try looking at:-
* The source code to Perl5 - for a real man's obfustication of lisp
* Boost Lambda - for a real man's obfustication of lambda
Le Mon, 21 Aug 2006 05:25:20 -0700, Rob Thorpe a écrit :
> * Boost Lambda - for a real man's obfustication of lambda
Yes. I was delighted when I discovered them, all the more since I didn't
know lambda-calculus yet. But Boost::Lambda proved to be somewhat
difficult to use, not very practical and above all, it generates
absolutely insane error message at compile-time (like any C++ library
that makes heavy use of template meta-programming).
Now that I use Lisp, lambda functions are just a revelation. I'm just
discovering all the places where they simplify in a surprisingly huge
manner my designs.
Anonymously,
Nowhere man
--
···········@levallois.eu.org
OpenPGP 0xD9D50D8A