Re: Lisp syntax vs. Mathematica syntax




Jon Harrop wrote:
> josephoswaldgg@xxxxxxxxxxx wrote:
> > Mathematica takes a TOTALLY different approach to programming
> > abstraction. And I'd hardly consider the resulting dog's breakfast as
> > "no problem."
>
> You can write a term-level interpreter for Mathematica just as you can write
> an interpreter for any other language. You can write programs in
> Mathematica as you would in other languages. It is, after all, evaluated in
> basically the same way.

For sufficiently complicated definitions of "basic", perhaps. The
Mathematica programs will have all sorts of little traps that you might
not find.

My personal "favorite" is Apply, where I had not defined a function
"g". Check out Mathematica's documentation

Apply[Plus, g[a,b]] --> a+b

WTF! Hey, what happened to my function g? And, amazingly enough, at
least some folks at Wolfram think this is what Lisp does, and they'll
start explaining to you about the "head" of an expression....

You can also write a Mathematica-like syntax parser in Lisp. Look up
Fateman's "mma" If you want to.

> Just to clarify, many of the symbols that you've listed are simply infix
> functions. You've also omitted a lot of Mathematica's syntax (which is
> unusually complicated).

And some of those "functions" affect the pattern *transformations* of
the expressions they define. That's not what Lisp folks mean when they
talk about functional programming.

> Mathematica can also be very concise. For example, the following squares
> each element in a list "l":
>
> #^2&/@l

Yes, because Mathematica has the "feature" that it automatically
distributes functions over lists.
What you are doing is not the same as other programming environments.

> The OCaml equivalent is:
....

irrelevant. You seem to be seriously mixing up surface syntax with
evaluation semantics.

Yes, you can write programs in Mathematica very easily in a huge number
of various approaches. But will they come when you call them? Can you
really be sure what they do? That you can avoid name capture? That
things don't depend on the exact structure of the expressions you pass
in? That you really made the right choice between Hold and Unevaluated?

.



Relevant Pages

  • Re: merits of Lisp vs Python
    ... To me superfluous mean more regarding a predefined syntax and grammar. ... Lisp has superfluous parentheses when compared with OCaml/F# (are _not_ ... metaprogramming" yet Mathematica, ... Precisely the large criticism to symbolic math in MathML becomes ...
    (comp.lang.lisp)
  • Re: Benefits of Dynamic Typing
    ... Mathematica implements everything that you've listed from Lisp and adds ... > syntax for for representing data externally predefined ... Mathematica takes this further by allowing 2D typesetting of expressions. ...
    (comp.lang.functional)
  • Re: Benefits of Dynamic Typing
    ... >> syntax for for representing data externally predefined ... >> reads from streams and returns lisp data. ... > Mathematica takes this further by allowing 2D typesetting of expressions. ...
    (comp.lang.functional)
  • Re: How Lisps Nested Notation Limits The Languages Utility
    ... Arguing in favor of Lisp syntax is like ... note that Mathematica provides strictly more in the way of macros. ... Neither of them has written any significant or even non-significant Lisp program. ...
    (comp.lang.lisp)
  • Re: merits of Lisp vs Python
    ... Whereas i wait that a core of LISP ... in lisp prefix notation for mathematical formula? ... For instance, Python uses explicit * for products, but Mathematica ... syntax assumes product for two adjacent tokens. ...
    (comp.lang.lisp)