David Barton wrote: > > What began with a fairly limited, and practical, suggestion on Simon's > part to assist the compiler with optimizations and transformations > that are valid in some cases and not in others has blossomed into a > search for a full logical language, with inference, proof checking, > and all the rest. > > Look, if you want a logical language, go for it. Frankly, I am in the > throes of Language Puppy Love(tm) with Maude right this second (those > who are interested, check out http://maude.csl.sri.com). Neat stuff. > But that doesn't mean I want to twist Haskell to fit that frame. Nor > does it mean that I want to abandon Haskell and do all my graphics > interface programming and scripting via term rewriting logic. Have no > fear, Haskell, you are still my first love! David: BTW, I felt the same way about Maude when I first saw it, but I feel Maude is less a programming language than it is an algebraic theorem prover---its programs are not necessarily confluent. > Sergey Mechveliani wrote: > > Adding *rules* to language would NOT cause scripting graphics via term > rewriting logic. I suppose, you know this. > If you do not set {rules..} in your program, you would never notice > they exist. Huh? Scripting graphics? > Sergey Mechveliani wrote: > > On the second, > Haskell is related to lambda calculus, to Haskell B. Curry. > And very probably, it is he, who introduced the rewrite rule technique > - rules for S,K combinators, and others. > Let somebody correct me, if i mistake. > Rather the "graphic interface" affairs, "file handlers", and such, > can be considered as twisting Haskell to what it should not be. > > [more reasons to do algebraic rewriting at compile-time] ... > Jerzy Karczmarczuk <[EMAIL PROTECTED]> writes > > > Sergey Mechveliani: > > >> i asked the list, why the examples deal only with transformations like > >> (map f).(map g) -> map (f.g), > >> why not deal with algebraic simplification, say, > >> (x^2+x+1)*(x-1) -> x^3-1. > > > I am afraid that Sergey is dreaming of transforming Haskell into a > > universal Computer Algebra system. We know for more than 30 years that > > the general problem of algebraic simplification is a mess. I think it is best to sidestep the discussion on "what Haskell is for" and "what Haskell is NOT for." Face it----we are never going to reach consensus on such a topic, and I think Sergey's use of the language is certainly as valid as anyone else's. I think what is going on is that we all got so excited about Simon's little language extension that we are already thinking about how it will affect the way we write programs in the future. It is clearly a very powerful and desirable extension, at least for a certain class of users. BUT, at this stage it's just a hack! The semantics are not clear at all and we don't have any experience with it (at least, not under Haskell). Simon himself admitted that the matcher is unsatisfactory. Probably one wants a second-order algorithm here anyway. The interaction with laziness is tricky, and it can easily destroy the semantics of an unsuspecting user's program. As it stands, the rules extension does not sit well with Haskell's other features. (Compare this with Maude, where analogous mechanisms are intimately related to the foundations of the language.) Mark's comments on the subject indicate that there are better ways to treat compile-time rules. I guess what I'm saying is that we should treat the rules feature carefully, and as a very specialized tool until it is better investigated. Certainly it is too early to start proposing other features or libraries that build on it. --FC
