I'm interested too. Just sent in my CA from Australia, so hopefully shouldn't be too long. I think I looked through the essays briefly when this was first posted, I coincidentally am working through the The Art of the Metaobject Protocol right now.
+1 on an update please :) Ambrose On Thu, Jul 7, 2011 at 12:37 PM, Brent Millare <brent.mill...@gmail.com>wrote: > How's the progress on this project going? During my spare time I've > been reading through some of the logic programming literature, trying > to learn about this, but there is still much to learn. While I could > spend hours continuing to read the literature, I feel it might be more > productive to get dirty instead and learn as I go. What area needs the > most help at the moment? And what would be the best reference for > tackling that sector? > > Best, > Brent > > On May 14, 5:20 am, "Heinz N. Gies" <he...@licenser.net> wrote: > > On May 13, 2011, at 14:37 , David Nolen wrote: > > > > > On Fri, May 13, 2011 at 2:04 AM, Heinz N. Gies <he...@licenser.net> > wrote: > > > Hearing Pattern Matching, > > > do you mean Erlang like Pattern matching? > > > > > Regards, > > > Heinz > > > > > Erlang, OCaml, SML, Haskell, Scala all have the kind of pattern > matching I'm talking about. One important point is that they all support > guards on patterns. It's not clear to me that current implementation > actually use guards to shape the tree, but that is my plan. In the system > I'm proposing guards are actually logical predicates that can be reasoned > about. > > > > > (match n > > > ([x] :guard [(number? x)] > > > ...) > > > ([0] ...)) > > > > > This is not ok in OCaml, SML, or Haskell (or Scala and Erlang as far as > I know). This would be ok in the system I'm proposing since number? is a > logical predicate and we can test for such cases and reorder the pattern. > > > > Erlang not only allows predicate functions, simple math is also just fine > like > > > > f(x) when x < 0 -> > > ... > > > > then again erlangs reasoning for only allowing certain BIF's and simple > arithmetics in guards is speed, those are writtin in plain C so are blazing > fast compared to erlang functions ^^. That is a issue Clojure does not have > to face so I don't think it would make sense to limit the code you can put > in guard expressions. > > > > Regards, > > Heinz > > > > smime.p7s > > 2KViewDownload > > -- > 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
