Re: Functional program design concepts
For examples of polymorphism mixing Java and Clojure, try my article on Developer Works: http://www.ibm.com/developerworks/java/library/j-clojure-protocols/ -Stuart Sierra clojure.com -- 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
Re: Functional program design concepts
> If your domain model can be represented by a simple vector / map / > set, then you have a very rich set of tools (in Clojure) to operate on > your domain model. If your domain model is represented by fixed types, > you have to write all sorts of wrapper functions to be able to apply > those operations. One of the nicest things about Clojure in this area > is that once you have a basic set of operations defined on your simple > data structures, it's easy to incrementally wrap it up in as much of a > typed API as you want via records, protocols and macros etc to create > an aesthetically pleasing façade around the core functionality. > > Hope that makes sense? In principle it makes sense! In practice I need some practice :) Actually I need to finish my home remodel so I can get to writing code in the evenings! -- 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
Re: Functional program design concepts
On Feb 15, 4:12 pm, James Reeves wrote: > On 15 February 2011 22:53, MS <5lvqbw...@sneakemail.com> wrote: > > >> 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? > > The short answer is protocols:http://clojure.org/protocols. > Cool thanks I'll take a look. -- 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
Re: Functional program design concepts
On Feb 15, 3:10 pm, Sean Corfield wrote:
> On Tue, Feb 15, 2011 at 2:53 PM, MS <5lvqbw...@sneakemail.com> wrote:
> > 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.
>
> Almost any such graph library is going to be a bunch of functions that
> operate on a data structure. Your circuit can be that data structure
> so you can simply use the functions on it. I suspect you're assuming a
> level of type checking, from statically typed OO languages, that just
> doesn't need to be there?
>
> > 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.
>
> Sounds like you just need a set of functions that match your domain,
> which wrap the graph library (which in turn operates on the underlying
> graph data structure that represents your circuit).
>
> > Yes, I finally figured out how to have a cyclic structure using refs
> > and dosyncs.
>
> I was thinking of something much simpler - a pure data structure.
At first it was simple, but I want a net to point to its nodes, and
the nodes to point to its parent net.
Actually what originally started this was I wanted a way to pre-sort
the circuit database (for example resistors, capacitors, and their
associated parameters) in a way that allowed for constant time
access... so (this was in python...) I figured out how to create a map
where the parameters were the keys, so if you wanted to search for a
given parameter you'd have to pick the right map. Then I realized
this is probably not necessary or practical even for extremely large
circuits. This turned into figuring out how to wire up the
components, and here I am :)
>
> > In clojure there is a defstruct...
>
> This is why I think you're trying to apply a strict type system which
> will get in the way of a simple solution. You want named types with
> specific behaviors because that's more like the OO you're used to?
Yes that's what I'm used to, and what's funny is that this is almost
exactly what the samples in SICP were moving towards, with tag-based
dispatch and functions associated with lists of stuff.
In a way just having a "to the metal" type of data structure feels a
little loosy goosy I think I want to be able to ask about what
type of structure this is... but I suppose I could tag it with a
{:type :ckt} or something. Kind of feels like I should have more
infrastructure... so maybe this is just the mental shift I need to
move away from OO :)
--
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
Re: Functional program design concepts
2011/2/16 Sean Corfield > On Tue, Feb 15, 2011 at 3:11 PM, Raoul Duke wrote: > > you might also sorta be saying that there are lots of different kinds > > of polymorphism in programming, and that we need to know when to/not > > use any given form of it, which i'd agree with :-) > > We're probably in violent agreement, yeah :) > > I think one of the big sticking points for a lot of folks raised on OO > - and Java in particular - is moving to a mental model where types are > "not needed" and adopting, for example, duck typing as a way to > achieve polymorphism without types. > Duck typing is a rather weak kind of polymorphism, and generally not the kind which I would speak about for promoting Clojure best practices. In Clojure, you will see some kind of duck typing when doing host interop calls, e.g. (.length foo). But one has to acknowledge this is very weak : you don't know if method .length of object foo will happen to implement the expected the semantics by accident or not. In Clojure, the focus is on the function, and thus you know which function you want to invoke, you're in control of its namespace and its name. So if the function is somehow specialized for the argument foo, it will not be by accident. It will either be by way of the function's implementation being a plain old function with conditionals, or a protocol function extended to foo's type, or a multimethod specialized on some characteristic of foo. So I'd say: in Clojure, polymorphism of function is an implementation detail of the function implementor, and the caller does not need to know/adapt. > > When I first got into FP it was via languages that either had no types > or only very weak types. When I first got into OO, it was via C++ > which lets you abuse the type system in interesting ways (and of > course you have full generic programming via templates so type-checked > duck typing is essentially possible :) In '97, I got into Java and, > whilst I liked the clean syntax and straightforward approach to most > everything, I found the type system very restrictive (and still do). > Since around 2001 I've been doing nearly all of my programming in > scripting languages that have very weak type systems and when I'm > writing OO in those languages, I tend to forego type checking in a lot > of places so I don't have to introduce interfaces or base classes that > my own classes then have to implement / extend, unless there's > specific reasons for using an explicit hierarchy of types (which I > find is rarely the case). > > If your domain model can be represented by a simple vector / map / > set, then you have a very rich set of tools (in Clojure) to operate on > your domain model. If your domain model is represented by fixed types, > you have to write all sorts of wrapper functions to be able to apply > those operations. One of the nicest things about Clojure in this area > is that once you have a basic set of operations defined on your simple > data structures, it's easy to incrementally wrap it up in as much of a > typed API as you want via records, protocols and macros etc to create > an aesthetically pleasing façade around the core functionality. > > Hope that makes sense? > -- > 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 > -- 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
Re: Functional program design concepts
There are two very interesting threads over on the Scala mailing lists at the moment that have some bearing on this thread - and I think illustrate the two very different ways of thinking about types and type systems: Benefits of static typing: http://groups.google.com/group/scala-debate/browse_thread/thread/a41b29cd1b8cc9e5 benefit of dynamic typing: http://groups.google.com/group/scala-user/browse_thread/thread/6f202d003d5fec1e (continued here:) http://groups.google.com/group/scala-debate/browse_thread/thread/26f433993fdfd651 The latter is in the context of a new feature being added to Scala in 2.9.0 to support the idea of a "dynamic" type. On Tue, Feb 15, 2011 at 4:12 PM, James Reeves wrote: > The short answer is protocols: http://clojure.org/protocols. -- 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
Re: Functional program design concepts
On Tue, Feb 15, 2011 at 3:11 PM, Raoul Duke wrote: > you might also sorta be saying that there are lots of different kinds > of polymorphism in programming, and that we need to know when to/not > use any given form of it, which i'd agree with :-) We're probably in violent agreement, yeah :) I think one of the big sticking points for a lot of folks raised on OO - and Java in particular - is moving to a mental model where types are "not needed" and adopting, for example, duck typing as a way to achieve polymorphism without types. When I first got into FP it was via languages that either had no types or only very weak types. When I first got into OO, it was via C++ which lets you abuse the type system in interesting ways (and of course you have full generic programming via templates so type-checked duck typing is essentially possible :) In '97, I got into Java and, whilst I liked the clean syntax and straightforward approach to most everything, I found the type system very restrictive (and still do). Since around 2001 I've been doing nearly all of my programming in scripting languages that have very weak type systems and when I'm writing OO in those languages, I tend to forego type checking in a lot of places so I don't have to introduce interfaces or base classes that my own classes then have to implement / extend, unless there's specific reasons for using an explicit hierarchy of types (which I find is rarely the case). If your domain model can be represented by a simple vector / map / set, then you have a very rich set of tools (in Clojure) to operate on your domain model. If your domain model is represented by fixed types, you have to write all sorts of wrapper functions to be able to apply those operations. One of the nicest things about Clojure in this area is that once you have a basic set of operations defined on your simple data structures, it's easy to incrementally wrap it up in as much of a typed API as you want via records, protocols and macros etc to create an aesthetically pleasing façade around the core functionality. Hope that makes sense? -- 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
Re: Functional program design concepts
On 15 February 2011 22:53, MS <5lvqbw...@sneakemail.com> wrote: >> 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? The short answer is protocols: http://clojure.org/protocols. However, calling a protocol method has the same syntax as calling a normal function. So you can start by writing functions specific to a certain graph implementation, and then painlessly convert convert them into a protocol when you actually need polymorphism. The actual code that uses these functions/methods need not change. To put it another way, OOP languages tend to emphasize thinking about polymorphism before you need it. In Clojure, you should generally only think about polymorphism when you actually need it. So if you don't have two equally-good graph data structures sitting in the wings, just write it using normal functions for now. - James -- 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
Re: Functional program design concepts
On Tue, Feb 15, 2011 at 3:03 PM, Sean Corfield wrote: > If polymorphism is the appropriate solution, yes. But for a lot of > people steeped in OO thinking, polymorphism is a bit of a hammer for > every problem that looks like a nail. you might also sorta be saying that there are lots of different kinds of polymorphism in programming, and that we need to know when to/not use any given form of it, which i'd agree with :-) -- 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
Re: Functional program design concepts
On Tue, Feb 15, 2011 at 2:53 PM, MS <5lvqbw...@sneakemail.com> wrote: > 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. Almost any such graph library is going to be a bunch of functions that operate on a data structure. Your circuit can be that data structure so you can simply use the functions on it. I suspect you're assuming a level of type checking, from statically typed OO languages, that just doesn't need to be there? > 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. Sounds like you just need a set of functions that match your domain, which wrap the graph library (which in turn operates on the underlying graph data structure that represents your circuit). > Yes, I finally figured out how to have a cyclic structure using refs > and dosyncs. I was thinking of something much simpler - a pure data structure. > In clojure there is a defstruct... This is why I think you're trying to apply a strict type system which will get in the way of a simple solution. You want named types with specific behaviors because that's more like the OO you're used to? As an exercise, forget all about types. Imagine all you have are functions and simple data structures (vectors, sets and maps). Try to build the simplest possible thing that will work. -- 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
Re: Functional program design concepts
On Tue, Feb 15, 2011 at 1:58 PM, Raoul Duke wrote: > because polymorphism makes code suck less, if done well. If polymorphism is the appropriate solution, yes. But for a lot of people steeped in OO thinking, polymorphism is a bit of a hammer for every problem that looks like a nail. I don't find I need polymorphism anywhere near as often in FP code as I'm used to using in OO code (caveat: duck typing is a form of polymorphism and that is often my preferred approach even in OO, when I'm using a dynamically typed language...). -- 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
Re: Functional program design concepts
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?
>
>
> 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
Re: Functional program design concepts
Thanks, I have HTDP on my computer but after the first chapter I got distracted and have been meaning to get to itI'll look for my answers there! :) On Feb 15, 1:13 pm, Raoul Duke wrote: > On Tue, Feb 15, 2011 at 1:12 PM, Raoul Duke wrote: > > for a functional take: > >http://ac.aua.am/trietsch/web/Critical%20Path_Holistic%20Approach_fin... > > aw, crap. > > http://www.htdp.org/ > > is the link i really wanted to copy-paste. (i think the one i did > paste is good reading if you are a process nerd like me, tho.) > > sincerely. -- 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
Re: Functional program design concepts
On Tue, Feb 15, 2011 at 1:55 PM, Sean Corfield wrote: > On Tue, Feb 15, 2011 at 12:04 PM, MS <5lvqbw...@sneakemail.com> wrote: >> For example, I'm trying to figure out how to do polymorphism in FP. > Why? because polymorphism makes code suck less, if done well. see "typeclasses" in haskell for an example that i think while not perfect is pretty good for fp. :-) sincerely. -- 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
Re: Functional program design concepts
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). 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 :) -- 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
Re: Functional program design concepts
On Tue, Feb 15, 2011 at 1:12 PM, Raoul Duke wrote: > for a functional take: > http://ac.aua.am/trietsch/web/Critical%20Path_Holistic%20Approach_final.pdf aw, crap. http://www.htdp.org/ is the link i really wanted to copy-paste. (i think the one i did paste is good reading if you are a process nerd like me, tho.) sincerely. -- 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
Re: Functional program design concepts
On Tue, Feb 15, 2011 at 1:07 PM, Saul Hazledine wrote: > On Feb 15, 9:04 pm, MS <5lvqbw...@sneakemail.com> wrote: >> Maybe my mind has been polluted by OO concepts. > Maybe a combination of OO and static typing. for a functional take: http://ac.aua.am/trietsch/web/Critical%20Path_Holistic%20Approach_final.pdf -- 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
Re: Functional program design concepts
On Feb 15, 9:04 pm, MS <5lvqbw...@sneakemail.com> wrote: > Hi, I just (mostly) finished reading the Programming Clojure book and > while it gave a great overview of the language, I'm still at a loss > for how to design programs. > You'll get better answers later but here is my take on it. > Maybe my mind has been polluted by OO concepts. > Maybe a combination of OO and static typing. > For example, I'm trying to figure out how to do polymorphism in FP. > Specifically, an electrical circuit "is a" type of graph (vertices and > nodes). I would say an electrical circuit is a type of datastructure and you already have those built in to the language. There's no need to set up a type hierarchy to express it. My first approach would be to build a datastructure that can describe an electrical circuit. Saul -- 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
Functional program design concepts
Hi, I just (mostly) finished reading the Programming Clojure book and while it gave a great overview of the language, I'm still at a loss for how to design programs. Maybe my mind has been polluted by OO concepts. For example, I'm trying to figure out how to do polymorphism in FP. Specifically, an electrical circuit "is a" type of graph (vertices and nodes). The book specifically says that multimethods are rare, so I'm thinking I probably shouldn't immediately go to multimethods to do what I want to do. 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. I'm also greatly influenced by SICP, but I have yet to "get" how to do anything really, other than play with small ideas. In the electrical circuit, you can have the nets be the edges and the vertices be the pins on a device. In this case there is exactly one edge per vertex, but there can be many vertices per edge. Another way is to have both nets and nodes be vertices in the graph, with edges simple indicating a connection. In an analog circuit there is no directionality; in a digital circuit there is. 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. Anyway, so suppose I find a graph library (I know they exist). How do I abstract the library into something that looks like a circuit, but still be able to use the methods for the library? 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. So how do I do this? thanks Michael -- 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
