Nameless wrote: > Why should I keep on learning lisp when there are python and perl?
Lisp compilers are much more advanced, for one thing. Xah Lee wrote: > (if there is some demand, i will add a concrept, little programing > example, that shows, how lisp's symbols and macros concepts, set it > apart from new scripting languages) I already did something similar, writing simple programs to simplify symbolic expressions in different languages: http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/239715 Also, here is a symbolic derivative example: http://codecodex.com/wiki/index.php?title=Derivative Note that pattern matching (as found in OCaml, F#, Haskell etc.) is very useful for this kind of term rewriting and is not found in Python, Perl or Lisp. > This lisp's symbol concept, as far as i know, does not exist in some > other high-level functional programing languages such as Haskell. Correct. > I'm > not familiar with many functional languages except Lisp and > Mathematica. I'm curious, as to how Haskell, which itself is quite > with capable of symbolic computation i think, deals with it even > though the language doesn't employ the concep of lisp's symbols per > se. In Standard ML, Haskell and F# you must define a sum type that represents a symbolic expression whereas, in Lisp, you can use the built-in s-expressions. The sum type that you define typically includes a "Symbol" that carries its string name. For example, the F# code cited above used: type expr = | Int of int | Add of expr * expr | Mul of expr * expr | Var of string with static member ( + ) (f, g) = Add(f, g) static member ( * ) (f, g) = Mul(f, g) end in this case, "Var" represents a symbol, e.g. the value Var "x" would represent a variable x. However, note that the best Lisp implementation of the symbolic simplifier (by Pascal Constanza) avoids s-expressions, improving performance. In OCaml, you can rely on the compiler inferring the sum type for you by using polymorphic variants. However, this is not generally a good idea because they are slower and harbor some of the disadvantages of dynamic typing. It is worth noting that eager, statically-typed languages like OCaml and F# are many times faster than the other languages at this task. This is precisely the forte of OCaml and F#, manipulating trees and graphs. -- Dr Jon D Harrop, Flying Frog Consultancy The F#.NET Journal http://www.ffconsultancy.com/products/fsharp_journal/?usenet -- http://mail.python.org/mailman/listinfo/python-list
