Re: Re: Language vs. Library

• To: mathgroup at smc.vnet.net
• Subject: [mg61213] Re: Re: Language vs. Library
• From: "Steven T. Hatton" <hattons at globalsymmetry.com>
• Date: Thu, 13 Oct 2005 01:39:24 -0400 (EDT)
• References: <did316\$qfd\$1@smc.vnet.net> <200510110721.DAA15085@smc.vnet.net> <dii8qs\$9cv\$1@smc.vnet.net>
• Sender: owner-wri-mathgroup at wolfram.com

```Andrzej Kozlowski wrote:

>
> On 11 Oct 2005, at 16:21, Steven T. Hatton wrote:
>
>> I've described Mathematica as Lisp on steroids, and I believe that is
>> probably a very apropos depiction.  An expression is a list (in the
>> Lisp
>> sense) where a Lisp car is analogous to a Mathematica Head.
>
> I do not think this is a correct or helpful this description of
> Mathematica.  In fact, I think people who take this similarity too
> far end up writing even more inefficient programs than people who
> keep using For loops. The biggest difference is, of course,  the way
> recursion is handled and it is recursive programming that is the
> essence of Lisp. It is certainly not essential in Mathematica; I
> don't think even one in five Mathematica programs I write use recursion.

There are two way to repeat something programmatically.  Iteration, and
recursion.  Both are actually a form of recursion at the most fundamental
level, though iteration does not involve pushing a function call onto the
activation stack for each execution of the loop.  Basically this is
Russell's Paradox.  You either fall into an infinite loop, or try to escape
the loop with infinite regress.

I don't claim to be an expert in Lisp. The only form of the language I have
any considerable experience with is Emacs Lisp, and most of that is limited
to getting my .emacs setup correctly.  I will say there are many
similarities that I can see.  The basic construct of Lisp is the List which
typically has a named symbol as its head, followed by arguments, or program
data which are often lists in their own right.  Lists are formed of
components called atoms which constitute the fundamental data types such a
string, integer, floatingpoint, bool, etc.  The type of a variable is
determined by the value assigned to it.  Variables have associated
properties stored in a property list.  Symbols are "interned" in a
hashtable.  This hashtable is either global, or buffer local - a scoping
feature that Mathematica doesn't support.  It would be analogous to have a
separate symbol table for each notebook opened in a frontend session.

The retrun value of a function is determined by the last expression
evaluated in the block as is the case with both Module and Block  in
Mathematica.  Emacs has a form of dynamic scoping analogous to that of the
Block construct in Mathematica. There are anonymous "lambda" functions,
operations such as mapc, mapcar, apply, evaluate, etc.  Lisp libraries have
a "requires" mechanism which invokes the loading of the library which
"provieds" the required feature.  The naming conventions used in library
naming are analogous to the package naming in Mathematica, even to the
extent that they typically use the library name as the name of the its
implementation file.  There are autoload "hooks" analogous to the
Mathematica declare package which cause the loading of packages if a
condition arrises in which features they probide are needed.

Emacs Lisp has a form of garbage collection which frees memory no longer
referenced by other objects.  There is a form of byte compiling. The same
language that the editor is implemented in is used both as a programming
language to be edited, and as the interpreted language supporting the
editing.  Editor customizations are stored in lists forming constructs of
the language.  Emacs probides a powerful regular expression search and
replace capability analogous (but signally different from) Mathematica's
pattern matching and transformation rules.  You can select a block of code
within an Emacs Lisp buffer and evaluate it separately from the rest of the
code, though the results will likely depend on the current state of the
evaluation environment and variables set in the global or buffer local
context as determined by both the Lisp code representing the editor and the
program under development.

Considering that, to a large extent, the two languages have extremely
different objectives, they are extraordinarily similar.

Now as for writing recursive code

>> I'm not sure if structural entities such as Module and Block
>> qualify as
>> foundational in Mathematica, or are derived from more fundamental
>> components.  Likewise for many of the procedural entities such as
>> For If
>> Goto, etc. qualify as elementary.
>
> A lot of Mathematica is written in Mathemtica and the rest is written
> in C. One could argue that the latter but not the former part
> belongs "the core", but as this distinction is largely invisible to
> the user  so in practice it does not matter.

Another point of close analogy with Emacs and Lisp.  James Gosling of Java
fame was the first to implement Emacs in C, BTW.

> Anyway,  languages like C seems to me a fundamentally different from
> Mathematica. C has essentially no "built-in functions" but it has a
> very clearly defiend sytax. In fact I wuld say that in the case of
> languages like C, language is syntax. On the other hand in
> Mathematica there are lots of built-in fucntions. There is a basic
> syntax for making valid expressions and there is also syntax
> associated with each built in function (it is not at all clear to me
> if you would want ot consider Solve, NSolve, Integrate, GroebnerBasis
> etc, as belonging to "the language", core or otherwise, but they
> certainly have a syntax).

It's been argued that C and C++ programmers create their own syntax using
the CPP.  Unfortunately, there is more truth to that than I would like.
C++ provides some features such as operator overloading, an templates that
make it mildely more similar Mathematica than is C.  What I'm talking about
in terms of "core language" is demonstrated by examining the way
differentiation is implemented using a recursively evaluated, goal-oriented
pattern-matching scheme.

> Another crucial thing is the evaluation
> sequence, understanding of which is as important as that of correct
> syntax.  Mathematica's syntax is is a very different thing form  C's
> syntax: it  allows a far greater variety of possibly legal
> expressions, it is constantly being expanded by the addition of new
> functions, new options, etc (and can even be modified by the user)
> and it  is not fully documented and probably never will be. All this
> makes me feel that all comparisons with languages like C or even Lisp
> are not very useful and neither would be a concept of "core
> language", even in the unlikely event of WRI deciding to open the
> source code of Mathematica so that we could see which functions are
> written in terms of which.

Some of that can be seen.  I will say there are certainly different
linguistic levels to Mathematica.  There is the level of FullForm (or I
prefer to think of it as TreeForm), then there is the level of "ascii"
symbolic representation of the FullForm elements. Beyond that, there is the
level of unicode 2D representation, which, unfortunately, can have an
impact on how expressions evaluate.  For example, MatrixForm evaluates to
an expressions different semantically distinct from its argument.

--
"Philosophy is written in this grand book, The Universe. ... But the book
cannot be understood unless one first learns to comprehend the language...
in which it is written. It is written in the language of mathematics, ...;
without which wanders about in a dark labyrinth."   The Lion of Gaul

```

• Prev by Date: Re: Re: Re: sqrt(x^2) = x
• Next by Date: changing the size of the numbers on x-axes
• Previous by thread: Re: Re: Language vs. Library
• Next by thread: Re: Language vs. Library