--- Kevin Toppenberg <[EMAIL PROTECTED]> wrote:
> Greg, > > I have heard you talk repeatedly about Haskell, so I finally broke > down and read about it. I wasn't very hopeful that I would be > interested. > > I looked here: http://www.haskell.org/aboutHaskell.html Ah, so persistence pays off in the end! :-) > > But instead, it is a very interesting concept. I like the analagy to > a spreadsheet funcionality where one specifies what the end result > wanted it, rather than the steps needed to get a result. That's a good analogy, though it perhaps gives a somewhat limited view of what functional programming is all about. I think I posted this before, but here is quicksort in Haskell qSort [] = [] qSort (x:xs) = qSort [ y | y <-xs , y < x] ++ [x] ++ qSort [y | y <-xs, y >= x] The key point here is that this code is really just a paraphrase of the essential idea behind the algorithm. It may be paraphrased as follows: If the list is empty, return the empty list. Otherwise, let x be the first element of the list and xs be the remainder of the list. Now, form a new list by concatenating the list formed by taking all elements < x recursively sorted, the list containing x itself, and finally the list of all elements of xs that are >= x sorted. If you think about it, it's obvious why it works. You pick out one element (called the "pivot") form two *shorter* lists by comparing elements with the pivot and sort them. Finally, you put them all together to get the final reult. This is a O(nlog n) algorithm (theoretically the best you can do) and is faster than elementary algorithms like insertion sort for all but the shortest lists. But to code this, you didn't have to follow all the directions in the previous paragraph, just write down a description of what you want to do. I find it much more like mathematics. > > I had thought that someone said that M was a functional language. I saw that, too. I don't know who said it, but it's just a case of incorrect terminology. MUMPS is most definitely *not* a functional language, though it does have features (like indirection) that could perhaps more naturally be modeled in a functional language (where they would be easier to reason about, to boot.) > And > I thought that ment that the spacing after the function names is > important (i.e. else has to have two spaces after it). But either I > am remembering wrong, or it is a name being used another way. Well, some functional languages (like Haskell) are sensitive to spacing, but others (like Scheme or Common Lisp) are not. Functional languages ar languages where computation occurs through the evaluation of expressions and which generally disallow side effects. In Scheme, you *can* change the value of a variable with something like (set! x 2) (The exclamation point is a warning that there is a side effect), but you cannot do this in Haskell. You can, however, write f a b = let x = a*a, y = b*b in x + y Then, f 3 4 is 25 (= 9 + 16). This "let expression" allows you to create a local binding which is not visible outside the expression being evaluated. But you *cannot* write x = 2 x = 3 because that would be creating a new definition for x. Think of "let" as a restrictive version of NEW (at least in some ways). But it's more flexible, too. You can also write f a b = let g x = x*x in (g a) + (g b) so that g is a local function you define "on the fly" as part of the definition of f. This is another characteristic of functional languages: functions are "first-class" objects, like number or characters, and can be passed as parameters to other functions or manipulated in other ways. > > So are are you trying to integrate a language like Haskell with the > concept of Globals like M? Exactly. There are a lot of things that make doing so attractive, such as the loose coupling and easy extensibility of functional programs. Another is that functional programs tend (in my opinion, at least) to be conceptually clearer than their imperative counterparts (as I hope the quicksort example above demonstrates. Another interesting feature of functional languages like Haskell and ML is that they are strongly typed (although it is usually not necessary to be explicit about variable types). This has the advantage of reducing conceptual errors in code and, perhaps more to the point, type systems can be express quite general constraints, allowing the compiler to verify that programs behave correctly to a considerably greater extent than is possible in traditional imperative languages. This is quite an active area of research. > > Thanks for the Haskell link. I don't think I will try to learn it > right now, but it sounds cool. > Kevin > I'm finding Haskell to be quite a challenge, actually. One reason is that the level of abstraction is higher than you are used to in MUMPS. Another reason is that it is based on different abstractions (there is no program counter, no "then", if you will) and so requires a different way of thinking. === Gregory Woodhouse <[EMAIL PROTECTED]> "Interaction is the mind-body problem of computing." --Philip Wadler ------------------------------------------------------- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click _______________________________________________ Hardhats-members mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/hardhats-members
