On Wed, Nov 25, 2009 at 2:08 PM, Erik de Castro Lopo 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

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 wrote:

Luke Palmer 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

2009/11/27 Daniel Schüssler

I think punning is a worthwhile goal on its own, since I find myself wasting quite some thought on whether to prefix a record field name somehow, and if I do, what I should use as a short but sufficiently unique prefix.

I agree, especially since it looks like the record situation is not about to be solved; for example by looking at the discussion generated by Simon Peyton-Jones's TDNR proposal (which I like, but I don't feel like my opinion should count on that matter ) David.

On Thu, Nov 26, 2009 at 12:03 AM, 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.

+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 :

...

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

2009/11/26 Michael Mossey :

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

On Thu, Nov 26, 2009 at 1:50 AM, Eugene Kirpichov 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.

2009/11/26 Gregg Reynolds :

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

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 wrote:

On Thu, Nov 26, 2009 at 6:44 AM, Stephen Tetley wrote:

...

2009/11/26 Gregg Reynolds :

...

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

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.

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] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH