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
- References:
- Re: Language vs. Library
- From: "Steven T. Hatton" <hattons@globalsymmetry.com>
- Re: Language vs. Library