In general the way repl's handle state is pretty busted. Ever create a piece of data and then later wonder, how the heck did I make this?
On Wed, Feb 22, 2012 at 11:29 PM, Jason Jackson <jasonj...@gmail.com> wrote: > "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. > " > > Personally, I suffer from interactive development problems even with > merely using def/defn. This is especially true if you're eval'ing > snippets, and not the entire file C-cC-k. > > You could solve these problems by creating a new editor specifically > for clojure interactive development which is aware of when you're > updating code vs inserting new code vs deleting code, and change the > interactive session accordingly. I'm sure there's a lot more you could > add to such an editor. > > (or maybe emacs mode is sufficient dunno). > > On Feb 20, 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
