Re: [Haskell-cafe] I miss OO
Nice. It would be fantastic to have a little practical real-world challenge (like building a simple music system, or a simple multi-channel sound mixer), and work this out in an imperative language, an object-oriented language, a functional language, and maybe other languages too, like logic languages or constraint languages (does the latter exist?) When OO is about constructing a machine and talking about objects, and FP is about making little algebraic languages, what would C or Pascal be like? In these languages, you don't think about objects, but you don't think about an algebra either? It's been a very long time since I worked with these languages, but as far as I recall, I started thinking about data structures and procedures operating on these data structures, which sounds a look like making ADTs and functions/operations on these... So this sounds odd, because it would mean that C and Pascal are in a sense closer to FP than OO is? Also Luke Palmer talked a couple of times about co-algebraic approaches, but not being a computer scientist, I never really understood what that meant (just reverse all the arrows?) On Thu, Nov 26, 2009 at 3:49 PM, Gregg Reynolds d...@mobileink.com wrote: On Thu, Nov 26, 2009 at 6:44 AM, Stephen Tetley stephen.tet...@gmail.com wrote: 2009/11/26 Gregg Reynolds d...@mobileink.com: Modeling musical stuff could provide an excellent illustration of the difference between OO and the Haskell way; it's the difference between metaphysical engineering and constructive mathematics. Hmm, Stephen Travis Pope's SmOKe - a design that has been the basis of various state-of-the-art Smalltalk music systems - seems pretty concrete to me rather than metaphysical. http://heaveneverywhere.com/stp/PostScript/icmc.94.mode.pdf Looks interesting, but what I was trying to get at - ``metaphysical engineering'' just popped into my head and sounded kinda cool so I went with it - is that these are two radically different ways of thinking about what we're doing when we write programs. For example, Pope talks about music in terms of properties, but then says [t]hese properties may be music-specific _objects_ (such as pitches or spatial positions)... (emphasis added). This is standard OO-speak; there's nothing wrong with it, the point is just that the domain of interest is viewed as a collection of ``objects'' and their behaviors, where ``object'' is the word we use for lack of a better term to refer to things that exist - hence metaphysics. Are there _really_ any objects involved, especially where properties are concerned? Not for me, though others may differ. In any case, the overall picture is that programs are combinations of such objects, so the program is viewed as the description of a kind of machine - hence engineering. In order to describe music, the programmer describes a machine. By contrast, a ``purely functional'' approach (I prefer ``algebraic'' as more accurate or at least more revealing) might construe such properties in terms of types and operations on values of the types, which capture the notion of property directly without implicating objects in any way. A music library would be viewed in terms of a language (algebra), with customized names for domain-specific types and operations, that the programmer can use to describe music instead of describing a machine that produces music. Which makes the programmer a litterateur rather than a constructor of machines, among other things. Cheers, Gregg ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] I miss OO
On Thu, Dec 3, 2009 at 4:09 AM, Peter Verswyvelen bugf...@gmail.com wrote:
Also Luke Palmer talked a couple of times about co-algebraic
approaches, but not being a computer scientist, I never really
understood what that meant (just reverse all the arrows?)
Disclaimer: I am not a category theorist. I think my intuition
matches the terminology pretty well, but I would like to see someone
who knows what they are talking about elaborate or correct me.
The way I use the term, a coalgebraic data type is still very much
functional in nature. Here's how I see it:
An initial algebra focuses on the constructors. You see:
data Nat = Zero | Succ !Nat
Notice Zero :: Nat, Succ :: Nat - Nat. We say that Nat is the
smallest data type that supports both of those constructrs (because of
Haskell's laziness, if I hadn't put the ! there, it wouldn't be the
least).
When you want to construct one, you use one of the constructors
(because it is by def. just large enough to have those)
When you want to destruct one, i.e. write a function f :: Nat - A for
some A, you say well it had to have been made with Zero or Succ, so
you pattern match on Zero and pattern match on Succ.
A final coalgebra focuses on the projections. You might see:
data Conat = Conat { proj :: Either () Conat }
So proj :: Conat - Either () Conat. But we can't say that it's the
smallest data type that supports that projection, because that is a
very small data type (it always projects to ()). Rather it is the
*largest* data type that still supports that projection.
When you want to destruct one, you just use one of the projection,
because it is by def. still small enough to always have them.
When you want to construct one, it is enough to specify the values for
each of the projections, because the data type is large enough to hold
any (well-defined) projection you can think of.
See the dualities?
The difference between Nat and Conat is that Conat has one additional
element, fix (Conat . Right). Technically all the lazy data types are
final coalgebras (just stated with focus on the constructors), because
they have these infinite elements, but it is convenient to pretend
that they don't sometimes. But go to any of the popular total
dependently-typed languages and there are some differences (one of
those differences being that none of them get final coalgebras
right[1]).
Luke
[1] Conor McBride. Let's see how things unfold.
http://strictlypositive.org/ObsCoin.pdf
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] I miss OO
It would be fantastic to have a little practical real-world challenge (like building a simple music system, or a simple multi-channel sound mixer), and work this out in an imperative language, an object-oriented language, a functional language, and maybe other languages too, like logic languages or constraint languages (does the latter exist?) There are some constraint languages. But I do not know whether they are general purpose (or even Turing complete). I have used ZIMPL, which is a language for specifying mixed integer linear optimization problems (which is somewhat related to constraint programming). Though it would not be useful for a music system. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] I miss OO
When OO is about constructing a machine and talking about objects, and FP is about making little algebraic languages, what would C or Pascal be like? In these languages, you don't think about objects, but you don't think about an algebra either? It's been a very long time since I worked with these languages, but as far as I recall, I started thinking about data structures and procedures operating on these data structures, which sounds a look like making ADTs and functions/operations on these... So this sounds odd, because it would mean that C and Pascal are in a sense closer to FP than OO is? You are working with state all the time in C and Pascal. Perhaps a C with a garbage collector would be closer to FP, because you could construct new structures all the time without worrying about memory leaks. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] I miss OO
On Dec 3, 2009, at 20:03 , Matthias Görgens wrote: When OO is about constructing a machine and talking about objects, and FP is about making little algebraic languages, what would C or Pascal be like? In these languages, you don't think about objects, but you don't think about an algebra either? It's been a very long time since I worked with these languages, but as far as I recall, I started thinking about data structures and procedures operating on these data structures, which sounds a look like making ADTs and functions/operations on these... So this sounds odd, because it would mean that C and Pascal are in a sense closer to FP than OO is? You are working with state all the time in C and Pascal. Perhaps a C with a garbage collector would be closer to FP, because you could construct new structures all the time without worrying about memory leaks. A Boehm GC library for C has been around for years. Nevertheless, I wouldn't call C-with-Boehm functional programming. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon universityKF8NH PGP.sig Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] I miss OO
2009/11/26 Eugene Kirpichov ekirpic...@gmail.com: I think two concepts should be separated if one makes sense and is useful without the other. A note out of its time context is certainly useful, for example, it may probably be converted to a MIDI command or to a graphical glyph (which is further to be positioned by a layout engine). Hello all Following on from Eugene's point, for music - time is often a property of the _evaluation_ of some musical structure (a note list or whatever). For instance, rendering a note list with rests to MIDI, requires requires some tracking of time both so note-offs can be generated at some delta after the note-on, and so rests can generate some 'blank' delta. Rendering to ABC or LilyPond (notation systems) - you could get by not considering time at all, or only using it transitionally for segmenting a note list into bars. Neither ABC or Lilypond files have a notion of time, notes and rests are simply sequential. Labelling note lists with onset times as they are constructed (rather than as they are evaluated) can limit or at least make much more complicated what you can do with a notelist: For instance, to concatenate two notelists labelled with time you would have to find the last onset from the first list and then traverse the second list shifting each onset by that value. Best wishes Stephen PS Luke Palmer's point Type classes are not for name punning should be quote of the week in HWN. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] I miss OO
On Thu, Nov 26, 2009 at 1:50 AM, Eugene Kirpichov ekirpic...@gmail.com wrote: I argue that in the situation you provided, the pitch, duration, timbre and instrument are essential attributes of the dot, whereas time is the position of the dot on paper and should be separated from its essence. `Timing', maybe, or temporal `position', `locus', etc., although position also applies to pitch (as interval). Anything but `time', which is guaranteed to induce confusion. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] I miss OO
On Wed, Nov 25, 2009 at 2:51 PM, Michael Mossey m...@alumni.caltech.edu wrote: So if I have objects/data note1, cursor1, and staff1, Python: note1.time() cursor1.time() staff1.time() Haskell needs something like note_time note1 cursor_time cursor1 staff_time staff1 Modeling musical stuff could provide an excellent illustration of the difference between OO and the Haskell way; it's the difference between metaphysical engineering and constructive mathematics. Think algebra. Haskell isn't just about types, its about algebraic types: structures and operations (signatures). So instead of asking ``what kind of object is a note?'', ask ``what is the algebra of notes?'' And not ``what kind of mathematical object is a note?'' but ``what kind of alegebraic formula describes (constructs) a note?'' You get a type constructor and some data constructors, which are essentially algebraic formulae that allow you to construct (i.e. refer to, describe) note values using values of other types. Then you add some operators, which are defined using those constructive formulae (deconstruction via pattern matching.) Type classing allows you to use the same names for operations on different algebras. Etc. Then ``how do I access the time contained in this note? becomes ``how do I construct a formula describing the time value used to construct this note?''. I.e. it's all about the algebraic notations rather than the metaphysics of ``objects'', and Haskell gives you a variety of ways to do this, as other responses in the thread have pointed out. -gregg ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] I miss OO
2009/11/26 Gregg Reynolds d...@mobileink.com: Modeling musical stuff could provide an excellent illustration of the difference between OO and the Haskell way; it's the difference between metaphysical engineering and constructive mathematics. Hmm, Stephen Travis Pope's SmOKe - a design that has been the basis of various state-of-the-art Smalltalk music systems - seems pretty concrete to me rather than metaphysical. http://heaveneverywhere.com/stp/PostScript/icmc.94.mode.pdf Best wishes Stephen ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] I miss OO
On Thu, Nov 26, 2009 at 6:44 AM, Stephen Tetley stephen.tet...@gmail.com wrote: 2009/11/26 Gregg Reynolds d...@mobileink.com: Modeling musical stuff could provide an excellent illustration of the difference between OO and the Haskell way; it's the difference between metaphysical engineering and constructive mathematics. Hmm, Stephen Travis Pope's SmOKe - a design that has been the basis of various state-of-the-art Smalltalk music systems - seems pretty concrete to me rather than metaphysical. http://heaveneverywhere.com/stp/PostScript/icmc.94.mode.pdf Looks interesting, but what I was trying to get at - ``metaphysical engineering'' just popped into my head and sounded kinda cool so I went with it - is that these are two radically different ways of thinking about what we're doing when we write programs. For example, Pope talks about music in terms of properties, but then says [t]hese properties may be music-specific _objects_ (such as pitches or spatial positions)... (emphasis added). This is standard OO-speak; there's nothing wrong with it, the point is just that the domain of interest is viewed as a collection of ``objects'' and their behaviors, where ``object'' is the word we use for lack of a better term to refer to things that exist - hence metaphysics. Are there _really_ any objects involved, especially where properties are concerned? Not for me, though others may differ. In any case, the overall picture is that programs are combinations of such objects, so the program is viewed as the description of a kind of machine - hence engineering. In order to describe music, the programmer describes a machine. By contrast, a ``purely functional'' approach (I prefer ``algebraic'' as more accurate or at least more revealing) might construe such properties in terms of types and operations on values of the types, which capture the notion of property directly without implicating objects in any way. A music library would be viewed in terms of a language (algebra), with customized names for domain-specific types and operations, that the programmer can use to describe music instead of describing a machine that produces music. Which makes the programmer a litterateur rather than a constructor of machines, among other things. Cheers, Gregg ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] I miss OO
On Wed, Nov 25, 2009 at 2:51 PM, Michael Mossey m...@alumni.caltech.edu wrote: I'm fairly new to Haskell, and starting to write some big projects. Previously I used OO exclusively, mostly Python. I really miss the namespace capabilities... a class can have a lot of generic method names which may be identical for several different classes because there is no ambiguity. In my musical application, many objects (or in Haskell, data) have a time associated with them. In Python I would have an accessor function called time in every class. So if I have objects/data note1, cursor1, and staff1, Python: note1.time() cursor1.time() staff1.time() Haskell needs something like note_time note1 cursor_time cursor1 staff_time staff1 which is a lot more visually disorganized. What's worse, I have a moderate case of RSI (repetitive strain injury) so I type slowly and depend on abbreviations a lot. I use the souped-up abbreviation capabilities of Emacs. Let's say I have a field/member-variable called orientedPcSet that is used across many classes. In Python, I can create an abbreviation for that and it is useful many times. In Haskell, I might need someType_orientedPcSet someOtherType_orientedPcSet thirdType_orientedPcSet which prevents me from using abbreviations effectively (especially the dynamic-completion feature). (It would help to make the underscore not part of word syntax, but that's not ideal.) So I'm thinking of moving to a scheme in Haskell using modules, most types being defined in their own modules, and doing qualified imports. Generic names like 'time' can be defined in each module w/o clashing. Then I have Note.time note1 Cursor.time cursor1 Staff.time staff1 This is very useful because I can define abbreviations for the type name and for oft-used accessor function names and these abbrevs are more organized, easier to remember, and easier to combine. I would be interested in comments... is this a good way to do things? Am I trying too hard to impose OO on Haskell and is there a better way? That is the way to do what you want and not a bad practice in general. There's nothing particularly OO about namespacing, for example, ML's modules and functors are quite a bit more flexible in this regard than typical OO languages. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] I miss OO
Michael Mossey wrote: I'm fairly new to Haskell, and starting to write some big projects. Previously I used OO exclusively, mostly Python. I really miss the namespace capabilities... a class can have a lot of generic method names which may be identical for several different classes because there is no ambiguity. In my musical application, many objects (or in Haskell, data) have a time associated with them. In Python I would have an accessor function called time in every class. This is what Type Classes in Haskell are for. See: http://www.haskell.org/tutorial/classes.html Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] I miss OO
2009/11/25 Michael Mossey m...@alumni.caltech.edu: I'm fairly new to Haskell, and starting to write some big projects. Previously I used OO exclusively, mostly Python. I really miss the namespace capabilities... a class can have a lot of generic method names which may be identical for several different classes because there is no ambiguity. In my musical application, many objects (or in Haskell, data) have a time associated with them. In Python I would have an accessor function called time in every class. So if I have objects/data note1, cursor1, and staff1, Python: note1.time() cursor1.time() staff1.time() Haskell needs something like note_time note1 cursor_time cursor1 staff_time staff1 which is a lot more visually disorganized. It looks like you use record syntax. This is not bad per se, but you can use Haskell classes to get an OO feeling. Like that: class Time a where time :: a - Time instance Time Note where time = note_time instance Time Cursor where time = cursor_time What's worse, I have a moderate case of RSI (repetitive strain injury) so I type slowly and depend on abbreviations a lot. I use the souped-up abbreviation capabilities of Emacs. Let's say I have a field/member-variable called orientedPcSet that is used across many classes. In Python, I can create an abbreviation for that and it is useful many times. In Haskell, I might need someType_orientedPcSet someOtherType_orientedPcSet thirdType_orientedPcSet Same here, I think. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] I miss OO
On Wed, Nov 25, 2009 at 2:08 PM, Erik de Castro Lopo mle...@mega-nerd.com wrote: Michael Mossey wrote: I'm fairly new to Haskell, and starting to write some big projects. Previously I used OO exclusively, mostly Python. I really miss the namespace capabilities... a class can have a lot of generic method names which may be identical for several different classes because there is no ambiguity. In my musical application, many objects (or in Haskell, data) have a time associated with them. In Python I would have an accessor function called time in every class. This is what Type Classes in Haskell are for. See: http://www.haskell.org/tutorial/classes.html I feel like this should be qualified. Type classes are not for name punning ; you wouldn't use a type class for the method bark on types Tree and Dog. But if you have a well-defined *structure* that many types follow, then a type class is how you capture that. It sounds like you do have this structure in your example. Further, with typeclasses, you can write methods that are generic over any type with that structure. So: class Temporal a where time :: a - Time temporalOrder :: Temporal a = [a] - [a] temporalOrder = sortBy (comparing time) The ability to do this indicates why using them for punning is a bad idea. Luke ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] I miss OO
Luke Palmer lrpal...@gmail.com wrote I feel like this should be qualified. Type classes are not for name punning ; you wouldn't use a type class for the method bark on types Tree and Dog. But if you have a well-defined *structure* that many types follow, then a type class is how you capture that. It sounds like you do have this structure in your example. Is there any way that type classes can manage name spaces to disambiguate functions like bark on types Tree and Dog? If constants are considered as unary functions, can we use constants in type classes and/or instances? How are local class specific constants, such as tank in Army/tank in Fish, bank in River/bank in Finance, handled? Pat ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] I miss OO
You can define the methods with the same names in different modules, then when you are importing them into the same module for use, use a qualified import. import qualified Dog import qualified Tree This will allow you to use exactly the syntax you described. Dog.bark Tree.bark Plus if you only have to import one of these, it is an opportunity to be implicit which about the module being used. On Thu, Nov 26, 2009 at 6:34 AM, pbrowne patrick.bro...@comp.dit.ie wrote: Luke Palmer lrpal...@gmail.com wrote I feel like this should be qualified. Type classes are not for name punning ; you wouldn't use a type class for the method bark on types Tree and Dog. But if you have a well-defined *structure* that many types follow, then a type class is how you capture that. It sounds like you do have this structure in your example. Is there any way that type classes can manage name spaces to disambiguate functions like bark on types Tree and Dog? If constants are considered as unary functions, can we use constants in type classes and/or instances? How are local class specific constants, such as tank in Army/tank in Fish, bank in River/bank in Finance, handled? Pat ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] I miss OO
2009/11/25 Michael Mossey m...@alumni.caltech.edu: I'm fairly new to Haskell, and starting to write some big projects. Previously I used OO exclusively, mostly Python. I really miss the namespace capabilities... a class can have a lot of generic method names which may be identical for several different classes because there is no ambiguity. In my musical application, many objects (or in Haskell, data) have a time associated with them. In Python I would have an accessor function called time in every class. This is really an opportunity to consider an important difference between the OO and typed, functional approach to things. In OO, we create classes that have time as a property or method; in the typed, functional approach we say there are a family of types that all allow a certain function to be called on them, `time :: t - Time`. This is what type classes are all about; they allow us to say here is a function and some types it works with. After all, you don't just want a `time` property -- you also want it to give you a `Time`. When one is accustomed to treating properties as part of an object, it's natural to go the record syntax route; but this doesn't capture the notion that all these records conform to a certain type equation. In this way, Haskell is more demanding of you; but it also offers you a way to make the semantics of your data explicit. -- Jason Dusek ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] I miss OO
Hello, Coming also from an OO background, I had this same feeling as yours when I started learning haskell. It might help to think that type classes are like interfaces: They allow expressing a family of behaviors as a bunch of related functions. The fact that it allows using same name to act on/with different things is an interesting side-effect. -- Arnaud Bailly -- OQube software engineering http://www.oqube.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] I miss OO
Hi, Are you sure you need to store the time *inside* your objects instead of using, say, pairs (Time, YourObject) (and lists of them instead of lists of your objects)? It would seem strange to me that a note HAS-A time even in an OO design: more likely, a note is associated with a time, and this is modeled by pairing them. 2009/11/25 Michael Mossey m...@alumni.caltech.edu: I'm fairly new to Haskell, and starting to write some big projects. Previously I used OO exclusively, mostly Python. I really miss the namespace capabilities... a class can have a lot of generic method names which may be identical for several different classes because there is no ambiguity. In my musical application, many objects (or in Haskell, data) have a time associated with them. In Python I would have an accessor function called time in every class. So if I have objects/data note1, cursor1, and staff1, Python: note1.time() cursor1.time() staff1.time() Haskell needs something like note_time note1 cursor_time cursor1 staff_time staff1 which is a lot more visually disorganized. What's worse, I have a moderate case of RSI (repetitive strain injury) so I type slowly and depend on abbreviations a lot. I use the souped-up abbreviation capabilities of Emacs. Let's say I have a field/member-variable called orientedPcSet that is used across many classes. In Python, I can create an abbreviation for that and it is useful many times. In Haskell, I might need someType_orientedPcSet someOtherType_orientedPcSet thirdType_orientedPcSet which prevents me from using abbreviations effectively (especially the dynamic-completion feature). (It would help to make the underscore not part of word syntax, but that's not ideal.) So I'm thinking of moving to a scheme in Haskell using modules, most types being defined in their own modules, and doing qualified imports. Generic names like 'time' can be defined in each module w/o clashing. Then I have Note.time note1 Cursor.time cursor1 Staff.time staff1 This is very useful because I can define abbreviations for the type name and for oft-used accessor function names and these abbrevs are more organized, easier to remember, and easier to combine. I would be interested in comments... is this a good way to do things? Am I trying too hard to impose OO on Haskell and is there a better way? Thanks, Mike ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Eugene Kirpichov Web IR developer, market.yandex.ru ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] I miss OO
On Thu, Nov 26, 2009 at 12:03 AM, Eugene Kirpichov ekirpic...@gmail.com wrote: Hi, Are you sure you need to store the time *inside* your objects instead of using, say, pairs (Time, YourObject) (and lists of them instead of lists of your objects)? It would seem strange to me that a note HAS-A time even in an OO design: more likely, a note is associated with a time, and this is modeled by pairing them. +1 This hadn't occurred to me, but in retrospect is quite obvious. In FRP notation, these are Futures, eg. Future Note. Luke 2009/11/25 Michael Mossey m...@alumni.caltech.edu: I'm fairly new to Haskell, and starting to write some big projects. Previously I used OO exclusively, mostly Python. I really miss the namespace capabilities... a class can have a lot of generic method names which may be identical for several different classes because there is no ambiguity. In my musical application, many objects (or in Haskell, data) have a time associated with them. In Python I would have an accessor function called time in every class. So if I have objects/data note1, cursor1, and staff1, Python: note1.time() cursor1.time() staff1.time() Haskell needs something like note_time note1 cursor_time cursor1 staff_time staff1 which is a lot more visually disorganized. What's worse, I have a moderate case of RSI (repetitive strain injury) so I type slowly and depend on abbreviations a lot. I use the souped-up abbreviation capabilities of Emacs. Let's say I have a field/member-variable called orientedPcSet that is used across many classes. In Python, I can create an abbreviation for that and it is useful many times. In Haskell, I might need someType_orientedPcSet someOtherType_orientedPcSet thirdType_orientedPcSet which prevents me from using abbreviations effectively (especially the dynamic-completion feature). (It would help to make the underscore not part of word syntax, but that's not ideal.) So I'm thinking of moving to a scheme in Haskell using modules, most types being defined in their own modules, and doing qualified imports. Generic names like 'time' can be defined in each module w/o clashing. Then I have Note.time note1 Cursor.time cursor1 Staff.time staff1 This is very useful because I can define abbreviations for the type name and for oft-used accessor function names and these abbrevs are more organized, easier to remember, and easier to combine. I would be interested in comments... is this a good way to do things? Am I trying too hard to impose OO on Haskell and is there a better way? Thanks, Mike ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Eugene Kirpichov Web IR developer, market.yandex.ru ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] I miss OO
First of all, thanks for the ideas, everyone. I think I'm starting to get the usefulness of type classes. With regard to your question, Eugene, you are probably right. In fact my rough draft of this code from four months ago used a Map with time as the key (of type Rational). I was trying to come up with a quick example and didn't think straight. You may observe, however, that the concept note has a lot of uses and contexts. Sometimes it means simply a pitch, like middle C. Sometimes it means a black dot on a piece of staff paper, in which case it has a duration (as a number of beats). The context of that black dot gives it a dynamic level, an associated instrument (timbre), and of course, a time. In this larger context, I'm not sure if there is a deep difference between storing time inside the object or outside it, except for the practical matter of wanting to index notes by time (in which case it is useful to use time outside the object as the key). You tell me: do you think it makes a deep difference? Thanks, Mike Eugene Kirpichov wrote: Hi, Are you sure you need to store the time *inside* your objects instead of using, say, pairs (Time, YourObject) (and lists of them instead of lists of your objects)? It would seem strange to me that a note HAS-A time even in an OO design: more likely, a note is associated with a time, and this is modeled by pairing them. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] I miss OO
2009/11/26 Michael Mossey m...@alumni.caltech.edu: First of all, thanks for the ideas, everyone. I think I'm starting to get the usefulness of type classes. With regard to your question, Eugene, you are probably right. In fact my rough draft of this code from four months ago used a Map with time as the key (of type Rational). I was trying to come up with a quick example and didn't think straight. You may observe, however, that the concept note has a lot of uses and contexts. Sometimes it means simply a pitch, like middle C. Sometimes it means a black dot on a piece of staff paper, in which case it has a duration (as a number of beats). The context of that black dot gives it a dynamic level, an associated instrument (timbre), and of course, a time. In this larger context, I'm not sure if there is a deep difference between storing time inside the object or outside it, except for the practical matter of wanting to index notes by time (in which case it is useful to use time outside the object as the key). You tell me: do you think it makes a deep difference? I argue that in the situation you provided, the pitch, duration, timbre and instrument are essential attributes of the dot, whereas time is the position of the dot on paper and should be separated from its essence. I think two concepts should be separated if one makes sense and is useful without the other. A note out of its time context is certainly useful, for example, it may probably be converted to a MIDI command or to a graphical glyph (which is further to be positioned by a layout engine). Thanks, Mike Eugene Kirpichov wrote: Hi, Are you sure you need to store the time *inside* your objects instead of using, say, pairs (Time, YourObject) (and lists of them instead of lists of your objects)? It would seem strange to me that a note HAS-A time even in an OO design: more likely, a note is associated with a time, and this is modeled by pairing them. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Eugene Kirpichov Web IR developer, market.yandex.ru ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
