Cool, thanks for the tips. More inline below:
>
> > For example, I'm trying to figure out how to do polymorphism in FP.
>
> Why?
Because I'm not sure how else to use (for example) a graph library and
still have it look like a circuit, rather than a graph.
>
> > 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.
So... how do I use someone else's implementation of some type of graph
algorithm as applied to my circuit structure, unless I use their
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?
That's a great question! I'm not sure. Just seems that if someone
else has done a bunch of work with graphs, then how can I take
advantage of that? The specialization of changing the abstract thing
into the concrete thing is basically to reduce some of the graph
functionality (for example in a circuit a node can't have more than
one unique edge on it) and renaming things so they match the domain
(eg "vertex" become "node", "edge" become "net"), and add extra stuff
such as PCB layer, simulation model, etc. I still want to be able to
take advantage of things such as finding cycles, fast lookup (if
someone else has already optimized how the thing is held in memory),
etc. without having to reimplement it myself.
>
> > 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.
Yes, I finally figured out how to have a cyclic structure using refs
and dosyncs.
>
> > 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).
I guess the part that I don't quite get is that in OO you implement a
class that's been defined with certain members, etc. In clojure there
is a defstruct where you can easily predefine a map with a bunch of
keys... but that is really just a shortcut for defining a {...} map
manually. Is the idiomatic way to define a function (make-thing
params) which return the structure of interest?
>
> <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
Cool!
--
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
