> On Thursday, July 17, 2014 7:07:19 PM UTC-7, Matthew wrote: >> >> The benefit of pattern matching is that 10000 complex if-then-else >> constructions are hard to write well. >> > > Writing 10,000 rules and being sure that you have 100% coverage of all > possible case and no overlap is > a challenge. It's hard for humans, it is impossible to guaranteed by > computer analysis. (That is, > given two patterns with associated predicates, associative, commutative > etc.. is one pattern a subset of the other? do they both match some > particular set of expressions? Note that pattern matching systems > of a particularly simple form, Thue or Semi-Thue systems are already > Turing complete.) >
And yet testing for confluence and termination is a topic of research with some decent implementations in the aforementioned languages. Again, I recommend actually reading about this topic. > Richard the popularity of pattern matching has been pretty much dead >> since the 90s. >> > I'm not sure what population is being used here -- users / applications? > For example, parsers > using BNF can be said to be using pattern matching, though > compiler-compilers (as they used > to be called) generally take the BNF and produce tables. Or possibly > if-then-else trees. > This is exactly why I appended my previous e-mail with the change "this kind of rich pattern matching". That being said it isn't a poor crutch, languages like Maude, Elan, and >> more recently Stratego/XT demonstrate proof of concept pretty well (IMO.) >> > > I don't know what needs to be proved. YACC is quite old, and of course > there was older stuff as well. > Then there was a slew of expert system frameworks like OPS5. (I think it > used the Rete algorithm, which may be a version of discrimination net) > There is a general problem that in the hands of novices, and maybe even > experts, large rulesets tend to become unmanageable. > > >> I would suggest reviewing these projects and their associated >> literature before deprecating it further. >> > I looked briefly at Stratego. > Given how frequently you belittle others for not reading historical work I'm surprised that you only looked briefly at these projects. I would expect someone of your stature and experience to review existing literature before making strong claims like you do in your e-mails. The standard paper on Stratego/XT is actually a very good read. Why didn't you think it was worth reading before commenting here? > I see it was used to build a compiler for Tiger (used by Andrew Appel in > [several] textbooks). I actually used that Tiger language for a compiler > class. I suppose one could muck about with patterns, but I used a small > "compiler compiler" that generated Lisp code. Then the abstract syntax > tree could either be interpreted or compiled. So in the > end one was not doing pattern matching at all. > This is kind of like saying "Oh yes, I looked at Java, I see that it was used to build the program "Hello, world!" which is actually used all over the place. I built it once...." The fact that they built a compiler for Tiger is not interesting (this is clearly possible in any system) what's interesting is how they built it. Again, I'd suggest actually reading about these projects rather than looking cursorily at their webpages. > Generally speaking this is a doable but difficult computer science >> problem. Known solutions exist but they're in papers, not in textbooks. I >> think that this work would be appropriate for a GSoC student over a summer >> or for a clever computer science student over a week or two. I don't >> personally expect any of the core-devs-with-other-jobs to get around to it >> for a while though of course I'd be thrilled if that were the case. (Prove >> me wrong Ondrej!) >> >> This is also the sort of thing that would benefit from a performant core. >> We would write patterns in SymPy and then match them using some C++ >> matching system. This is likely a purely structural operation and so >> shouldn't require any of the Python logic code. The patterns would >> probably translate well between SymPy and CSymPy. >> > > I don't understand why a purely structural pattern matching program would > require more that a half page of code, or why it would be of interest to > deploy such a program in the context of symbolic algebraic mathematical > expressions, fast or slow. But maybe you are talking about something > different from this. > Associative/Commutative operators vastly complicate matching systems. However, just because a problem is in general difficult or impossible does > not mean that a partial solution can't be very handy. Computer algebra > systems rely on this. > Fully agree here -- You received this message because you are subscribed to the Google Groups "sympy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAJ8oX-GMzyPx%3DeHzckCN-etN7dnDw4PP6moxaxXR7bLM4OC83w%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
