On Tue, 2011-07-19 at 22:27 -0400, Adam Richardson wrote: > On Tue, Jul 19, 2011 at 9:04 PM, daly <d...@axiom-developer.org> > wrote: > > On Tue, 2011-07-19 at 20:14 -0400, Adam Richardson wrote: > > On Tue, Jul 19, 2011 at 6:23 PM, Brian Hurt > <bhur...@gmail.com> wrote: > > What's this awk-a-mel he speaks of? Ocaml, > pronounced > > oh-camel, I ... > > > > > > I will confess that as I listened to the presentation (when > I got the > > email with Tim's link, I just started the video while I was > working on > > some drudgery), I felt like he missed some of the language > features > > promoted in functional languages. > > > > > > He worded functional programming contributions in terms of > advancing > > the idea of limiting/protecting variable assignment > (immutability), > > and to me, that's missing the points of first class > functions (which, > > in light of what he says OOP languages brought to the table, > actually > > provided protected function pointers through purely > functional > > languages without any need for OOP) and an emphasis on > function purity > > and limiting the scope of unpure functions (to me, this goes > beyond > > merely protecting assignment.) > > > > > > These omissions, coupled with the mispronunciations of > functional > > programming language names, and the value placed on the last > language > > being homoiconic (without much justification) had me > wondering how > > much he actually has used languages such as OCaml or > Haskell. > > > Homoiconic representation is fundamentally important and > lacking > in other languages. The programs == data idea is what makes > the > macro facility work, allows dynamic program construction, > compile > to core, etc. There is a story going around that McCarthy > attended > a python talk where they made the claim that python IS a > lisp-like > language. John pointed out that if it lacks homoiconicity it > cannot > be a lisp. (I probably have the details wrong). > > > > I tend to take the position that Micheal L. Scott does in his book > "Programming Language Pragmatics", when he states that: > > > Metaprogramming requires, at the least, that we have true > first-class functions in the strict sense of the term, that > is, that we be able to generate new functions whose behavior > is determined dynamically. A homoiconic language can simplify > metaprogramming [emphasis added] by eliminating the need to > translate between internal (data structure) and external > (syntactic) representations of programs or program extensions. > (p. 563) > > > Homoiconic does simplify the process, but I'm not sold it's a > requirement for productive metaprogramming. For instance, Template > Haskell is a very powerful, usable tool for integrating > metaprogramming into programs written in Haskell, a language that is > not considered homoiconic: > http://www.haskell.org/haskellwiki/Template_Haskell > > > That said, I appreciate the syntax of Clojure and CL very much, but > there are also times I appreciate the syntax of non-Lisp languages, > too :)
Indeed it is ALMOST possible to do some things by referencing the abstract syntax tree version of Haskell. If the AST version were the actual language of Haskell you could build the syntactic-sugar version on top of it. Unfortunately, they started the other way around. And, you'll note, the Template Haskell language has various restrictions (e.g. non-recursive, separate files, etc) that make it not-quite-first-class Haskell. This is more than a matter of syntactic elegance. There are things you simply cannot do by machine that you can do by hand (well, technically you can but only with a lot of special case programming). Eventually you need a Haskell parser you can invoke at compile time. One of my AI programs "learned" by doing self modification at run time. It rewrote itself to optimize the cases and saved the changes. During execution, the program gradually shifted until the code I originally wrote no longer existed. I can't imagine doing that in Haskell or C++ or any other language except maybe assembler. A standard example is to write a dumb Rubics cube program that rewrites itself when it discovers a shorter solution. You can do this by interpreting a data structure but in lisp, the program IS the data structure. It is fun to watch the program learn. It is a shame we don't teach students to do this. Imagine what Google COULD be if they bothered to unify programs and data, letting Google learn by itself. But that is probably too much science for an "engineering company". They need a few more lispers on staff. Sigh. Tim Daly > > > Interesting points. > > > Adam > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient > with your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
