I also have a small syntax idea. One principle that would be nice, and that Mathematica lacks, is parity between anonymous predicate dispatch constructs, and those attached to vars.
So while one way is to look at predicate dispatch as an extension of multimethods, another way is to look at it as an extension of maps. so instead of writing (hash-map lhs1 rhs1 lhs2 rhs2 ...) you would have (rules lhs1 rhs1 lhs2 rhs2 ...) but in this case, the lhs and rhs would describe a computation, rather than just looking up literal values from literal values. Then you can use this anonymously, or def it to a var. The benefits are 1) you can re-use conj as the way to add new rules, or do all the typical sequence manipulation on it, and 2) it is natural to have alternatives like ordered-rules or other types of rule "collections" that determine the reordering behavior when new rules are conj'ed on, similar how there are multiple versions of sets and maps. It is also natural to have the equivalent version of a pattern set, so you can ask about membership in this sequence of patterns. So it could be possible to start from this construct, and then figure out the convenience macros later. 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
