On Tue, Feb 15, 2011 at 12:04 PM, MS <5lvqbw...@sneakemail.com> wrote: > Maybe my mind has been polluted by OO concepts.
I was having this discussion on another list and it seems that the less OO folks know, the easier they find FP... so you may well be right :) > For example, I'm trying to figure out how to do polymorphism in FP. Why? > Specifically, an electrical circuit "is a" type of graph (vertices and > nodes). So an electrical circuit is a data structure containing vertices and edges and describing how they are connected. Then you'll have some functions that operate on that data structure. > What I'm trying to figure out is how to take an abstract concept like > a graph G comprising vertices and edges (V, E), and then "derive" from > this a specific type of graph, specifically an electrical circuit. Again, why? Either an electrical circuit is a general graph or it isn't - and if it isn't, you need a custom representation and/or a custom set of functions to operate on it. What I'm getting at here is how much work would you have to do (in an OO program) to extend a graph class and customize it to match the specific semantics of your domain? An associated question is then: do you need the generic implementation - or are you just trying to solve the "electrical circuit" problem? In other words, how much abstraction do you _really_ need? > In any case I want an > edge to have a list of its vertices, and a vertex to know its edge. > It can be cyclic or acyclic. A fairly simple data structure should take care of that. > In OO, suppose the > library class has something like "get-edges", but the circuit class > which derives from it, this method would be called because the circuit > "is a" type of graph. The implementation of get-edges and the > internal structure of the graph class should be hidden from the user. Define a set of functions that define the API you want to expose, and implement them to use the graph library on your circuit/graph. That's essentially what's you'd do in the OO case, except you'd be putting the API functions in one class and having it extend the other (graph class). <personal> I started with basic procedural / imperative programming in the late 70's and got into FP in the mid 80's. I first started doing OO in the early 90's (and it was hard work and not very natural at first). Over time, I internalized the OO way of thinking and it's become pretty much second nature now - but I have to say it's always seemed a lot more complex, inherently, than the world of FP that I'd come from. Now that FP is becoming more popular again (yay!), I'm very pleased to see languages offering FP on a mainstream platform (JVM) and I'm looking forward to FP itself moving further into the mainstream. I do worry that we've all become so used to the OO way of thinking that we'll find it hard to strip away some of the OO layers and get back to a simpler view of algorithms and data structures :) </personal> -- Sean A Corfield -- (904) 302-SEAN Railo Technologies, Inc. -- http://getrailo.com/ An Architect's View -- http://corfield.org/ "If you're not annoying somebody, you're not really alive." -- Margaret Atwood -- 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
