Lots to think about :) I definitely agree there needs to be a simple way to "query" a predicate dispatch system in order for it to work well in larger programs. But I haven't thought about it much more then that yet.
David On Mon, Feb 20, 2012 at 9:56 PM, kovas boguta <kovas.bog...@gmail.com>wrote: > Mathematica implements a version of open and order-independent > dispatch, so I wanted to add some points to the discussion. > > The design of Mathematica's pattern matching is tightly coupled to the > language's computational model, as well as with all other aspects of > the system. So a lot of it would get lost in translation to Clojure, > and not give you as much mileage as it does in Mathematica. So I'm > mostly gonna focus on some pitfalls rather than the upside. > > The biggest problem for the developer is understanding the state of > the rules system, especially during interactive development. > > Mathematica tries it's best to insert new function definitions in the > "right" order, trying to figure out if pattern X if a subcase of > pattern Y, etc. Of course, there are ambiguous cases, particular since > the pattern language is rich. You solve this problem by either making > your pattern more specific, changing the order in which definitions > are loaded, or attaching the definition another symbol that has higher > precedence. > > So debugging the pattern ordering is something you end up needing to > know how to do. > > But this exposes a bigger problem: when doing interactive development, > you will end up with old definitions sticking around. You are > debugging one case of your function, and change the pattern a little. > The old pattern is still there, potentially shadowing the new one. So > anytime you see unexpected output while debugging, you need to wonder > about the state of the definitions and if you should reinitialize > them. > > You can also get a function that works at the repl, but its broken in > source. The way this happens is, you enter definitions in arbitrary > order at the repl, but they are in a different order in source. So in > cases where order matters, this can get you too. > > I've pretty much had every possible situation happen. > > In Mathematica, it's possible to manually specific the order of the > definitions, but it's too cumbersome to use in source code. > > In Clojure, the situation is simpler, and that helps. The pattern > language (or versions that we've seen of it) is simpler, and > destructuring is not part of its mission. (Changes to destructuring > are a common source of this shadowing issue.) There is also the > core.logic engine to do more deduction about the patterns themselves. > > Still, I still see the two problems of 1. debugging the ordering, and > then 2. dealing with the state of the definitions during debugging and > interactive development. > > On 1, the best thing is if you look at the source and immediately > understand what the ordering will be. So when you are writing code, > you just have this simple mental model, and spotting mistakes is easy. > For example, if the system does no "intelligent" ordering for you, its > obvious what the order at runtime will be, and you don't have to fight > anything to get things into the desired order. > > On 2, this is more tooling support, in rough order of importance > -- which case is called for input X, and why > -- debugging a specific case independent of all others (suppress the > other cases) > -- various operations for comparing and testing patterns > -- ide support for displaying / editing the ordering of definitions > > I've spent a ton of time debugging this stuff; its really important to > have a quick way to find out why something happened in these open > matching systems, and then have a convient way to patch the behavior. > Its just not as easy as changing a cond case in a single place in > source. > > The great thing about pattern matching in Mathematica is that it is so > deeply integrated with all kinds of other primitives, from string > manipulation, data manipulation, math stuff, the equivalent of Map, > the equivalent of macros. So my question is can clojure-style pattern > matching and predicate dispatch be equally as powerful and pervasive, > but it it's own way. > > One thought I had is about the relationship with program querying. > With predicate dispatch, you'll have greater runtime control over your > program, can swap things in and out at a finer granularity. And with > this idea of program querying that Rich talked about, you might find > all sorts of behaviors in your program that you might want to do > something about. Seems sort of complementary. > > Maybe there is something there at that intersection, that can be a > greater extension of logic-based programming beyond only extending the > multimethod concept. So instead of replacing defn or defmulti, there > could be an entirely different use case, and it would be obvious which > one to use when. > > -- > 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
