- Haskell-Cafe - Haskell.org

More experiments with ATs
by Andrew Coppin 06 Jul '10

06 Jul '10

Currently we have class Functor c where fmap :: (x -> y) -> (c x -> c y) This relies on c having kind * -> *. For example, Bytestring cannot be an instance of Functor. A cleaner solution would be to have something like class Container c where type Element c :: * I then attempted to write class Container c => Functor c where fmap :: (Functor cx, Functor cy, Element cx ~ x, Element cy ~ y) => (x -> y) -> (cx -> cy) However, this fails horribly: The type signature fails to mention c. And even if it did, this type signature still isn't correct: It says that fmap can transform *any* functor into *any* other functor, which is wrong. It seems that we have gained the ability to talk about containers holding any type of value (even hard-coded types or types with class constraints), but lost the ability to refer to a particular "type of" functor without also specifying the element type. Does anybody know a straightforward way to fix this? Or is this just a dead end?

7 10

emacs tags
by Michael Mossey 06 Jul '10

06 Jul '10

(I asked this question on the logical email list to ask, haskell-mode, but got no reply, so I'm hoping someone here might know the answer.) I tried to use tags with emacs. I ran :etags in ghci, then tried to use C-c M-. inside Emacs to find the definition of a symbol. It reported "no source information available". I did some basic checking---a TAGS file does exist in the same directory as the file I was visiting, and contains some kind of entry for the specific symbol (whether the right syntax I don't know). I'm using haskell-mode 2.4 and emacs 21.3.1 on Windows XP. Also ghci 6.12.1. Thanks, Mike

1 0

Is my code too complicated?
by Ertugrul Soeylemez 06 Jul '10

06 Jul '10

Hello fellow Haskellers, I'd like to discuss an interesting topic. My experience is that there are two worlds in Haskell, which are quite separate: the pure, algorithmic world, where you use idiomatic pure Haskell, and the IO-driven world of state, change, threads and execution, where you use idiomatic concurrent Haskell. If you understand these two concepts well, then you are usually a good Haskell programmer. Interestingly this doesn't mean that you get applications done faster or done at all. Most languages today provide a certain "glue" to bring everything together. I think that term originates from "Why Functional Programming Matters" by John Hughes. Haskell provides a lot of low level glue like laziness, currying and other very helpful language features. But what is different in Haskell is that it doesn't seem to provide any high level glue like other languages do, especially when it comes to the IO world. There is a somewhat powerful module system, but nothing to bring modules and the objects they define together in a consistent way. In my opinion this is both a disadvantage and an advantage. It's bad because there is no standard way of gluing, nothing everybody learns and uses. On the other hand it's good, because you can make your own glue. This has proven very useful for me. My usual way is writing monad transformers and sticking them together, often together with concurrent programming. The problem with that approach is: This makes my code harder to understand for beginners. Usually they can tell /what/ my code is doing, because it's written in natural language as much as possible, but they couldn't reproduce it. And when they try to learn it, they give up fast, because you need quite some background for that. Also sometimes when I write Haskell, my friend sits beside me and watches. When he asks (as a PHP programmer with some C background), say, about my types, I can't give a brief explanation like I could in other languages. Yesterday I was writing a toy texture handler for OpenGL (for loading and selecting textures). He asked about my TextureT type. I couldn't explain it, because you couldn't even express such a thing in PHP or C. type TextureT = StateT Config -- Note that this is MonadLib. -- BaseM m IO corresponds to MonadIO m. selectTexture :: BaseM m IO => B.ByteString -> TextureT m () I fear that my code is already too difficult to understand for beginners, and it's getting worse. But then I ask myself: I've got a powerful language, so why shouldn't I use that power? After all I haven't learnt Haskell to write C code with it. And a new Haskell programmer doesn't read my code to learn Haskell. They first learn Haskell and /then/ read my code. Is this a real problem or am I just exaggerating? What do you think? Greets, Ertugrul -- nightmare = unsafePerformIO (getWrongWife >>= sex) http://ertes.de/

13 30

Getting started
by Mrwibbly 05 Jul '10

05 Jul '10

I'm having real trouble starting this project. Basically I have to create a record store that store information about artists and albums and also the number of sales that they have had. It also needs to generate a list of the top 5 sellers. So far I have: recordSale :: Sales -> String -> String -> Sales where recordSale sales anArtist aTrack returns a modified version of the sales. Any help getting started on this would be gratefully received. I don't want answers, I just want help getting started. Thank you -- View this message in context: http://old.nabble.com/Getting-started-tp29046956p29046956.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

5 10

Fwd: [Haskell-cafe] Re: Is my code too complicated?
by Alberto G. Corona 05 Jul '10

05 Jul '10

Very often the type system assures safety to a point where some coding is done trough trial and error: -I think that this composition is right, let´s try it-... -oh, some missing type here, Let´s put it here and here-...-go on-... -The typechecker say t´s OK. I run it and, well it works. Later when I look at the code, I have to think twice to understand it. Sometimes I mix transactions, threading, IO and some other abstractions in the same line, things that I would fear much to work with in any other language. This playing thig is fine, because the typechecking cut a lot of dead branches in the entrophic tendency of humans to commit mistakes. For this matter I praise math as the hidden god that handles reality and haskell its prophet. but the resulting code is not a product of my intended design, but something made together with the compiler, and sometimes it needs more than a look to understand it, even to myself. 2010/7/5 Ertugrul Soeylemez <es(a)ertes.de> Felipe Lessa <felipe.lessa(a)gmail.com> wrote: > > > On Sat, Jul 3, 2010 at 9:25 AM, Ertugrul Soeylemez <es(a)ertes.de> wrote: > > > Haskell provides a lot of low level glue like laziness, currying and > > > other very helpful language features. But what is different in > > > Haskell is that it doesn't seem to provide any high level glue like > > > other languages do, especially when it comes to the IO world. There > > > is a somewhat powerful module system, but nothing to bring modules > > > and the objects they define together in a consistent way. > > > > When I first read this paragraph, I thought: "STM to the rescue!". > > STM is one of the best concurrent world glues, IMHO. > > I found that I get along with the basic concurrency constructs. STM may > be handy in a few applications, but in none that I write. > > > > If you want, you may use Haskell just as you as PHP or C: just put > > everything in IO. Your code will get uglier and the type system won't > > catch many bugs, but that's what we get when doing C or PHP, right? > > Not really. Even when programming in such a style, Haskell is much > safer than PHP with its braindead type system, and still somewhat safer > than C. > > > > > The problem with that approach is: This makes my code harder to > > > understand for beginners. Usually they can tell /what/ my code is > > > doing, because it's written in natural language as much as possible, > > > but they couldn't reproduce it. And when they try to learn it, they > > > give up fast, because you need quite some background for that. Also > > > sometimes when I write Haskell, my friend sits beside me and > > > watches. When he asks (as a PHP programmer with some C background), > > > say, about my types, I can't give a brief explanation like I could > > > in other languages. > > > > I agree that it gets harder to reason about the code. In fact, > > sometimes I stack monad transformers in the wrong order. However, as > > Ivan says, if the feature is useful for you, don't be afraid of using > > it. Beginners may have a hard time grasping the concepts for the > > first time, but that's only until they "get it". > > I find monad transformers easy to reason about, and in most cases the > stacking order doesn't make a difference at all. Just remember to > change the running function, too. The problem with them is that > beginners learn them very late. > > > > > Yesterday I was writing a toy texture handler for OpenGL (for > > > loading and selecting textures). He asked about my TextureT > > > type. I couldn't explain it, because you couldn't even express such > > > a thing in PHP or C. > > > > > > type TextureT = StateT Config > > > > > > -- Note that this is MonadLib. > > > -- BaseM m IO corresponds to MonadIO m. > > > selectTexture :: BaseM m IO => B.ByteString -> TextureT m () > > > > "It is the type of functions that may access and modify a state of > > type Config." > > Then you need to explain "type of functions" and this explicitly > implicit "state" and why you have to do it that way in Haskell. > > > Greets, > Ertugrul > > > -- > nightmare = unsafePerformIO (getWrongWife >>= sex) > http://ertes.de/ > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe >

1 0

How easy is it to hire Haskell programmers
by Paul Johnson 05 Jul '10

05 Jul '10

I'm starting to see job adverts mentioning Haskell as a "nice to have", and even in some cases as a technology to work with. However right now I'm looking at it from the other side. Suppose someone wants to hire a Haskell developer or three. How easy is this? I'd appreciate replies from people who have actually done this. * How many applications did you get? * How many of those applicants knew what a monad is, or how to write FizzBuzz in Haskell? Thanks, Paul.

27 53

Re: [Haskell-cafe] music-related problem
by Michael Mossey 05 Jul '10

05 Jul '10

erik flister wrote: > I am dealing with ties because I am converting a MusicXML document > into a more natural form for my purposes. The initial form of the > document will have tied notes (as it comes that way from MusicXML), > and I want to convert that into a form that makes it possible to > ignore ties and see notes as having a single duration. > > > but can't you just say that the first note of a tie has the indicated > start time and a duration which is the sum of the tied notes? i don't > know musicXML, but i'm not seeing why that would be hard... That's what I want to do. I'm asking about a good way to write the algorithm that traverses the notes and reconstructs the document with the correct duration in each note. Actually, I don't want to lose information about the original form of the document, so I have separate fields for the duration of the graphical single note, and the duration of the tied chain. Actually, it is better to speak of the end time than the duration, because what units do you put duration in? Beats? The time signature could be changing measure to measure. MusicXML "position"? The meaning of "one position" changes measure to measure and can be different in different parts. It can get confusing. So I use this concept of "location": data Loc = Loc Int Rational -- measure number and beat within the measure I.e. measure 1, beat 2 measure 7, beat 3 1/2 I use Rational so there is no worry about precision of Floats. Thanks, Mike

2 4

Undecidable Instances [Was: Is my code too complicated?]
by oleg＠okmij.org 05 Jul '10

05 Jul '10

Ertugrul Soeylemez wrote: > Essentially UndecidableInstances turns the type system into a > Turing-complete programming language. One direct consequence is that > type checking may not terminate Actually, the type checking (specifically, instance resolution) always terminates, due to the recursion depth limit. When the type checker hit the limit, one can't generally say either it is because the program is ill-typed or the program is well-typed but needs a bigger limit. In practice, it is usually quite easy to tell the difference. The trace emitted by GHC helps. I'd like to emphasize however that UndecidableInstances is only a sufficient condition of a decidable type checking -- but by no means necessary. There are many good, type-decidable programs that are not accepted without UndecidableInstances. One of the simplest examples is shown in http://okmij.org/ftp/Haskell/types.html#undecidable-inst-defense The situation with UndecidableInstances seems similar to the primitive recursion criterion: all primitive recursion functions surely terminate; non-primitive recursion functions generally don't. That is not the reason to disregard the latter: There are many classes of non-primitive recursive functions that are total. To see that, one has to use more complex criteria. The added complexity is not worthwhile as far as GHC is concerned (The tradeoff is different in Agda, where the added complexity of more powerful termination checkers may be worthwhile).

1 0

Mining Twitter data in Haskell and Clojure
by braver 05 Jul '10

05 Jul '10

I'm computing a communication graph from Twitter data and then scan it daily to allocate social capital to nodes behaving in a good karmic manner. The graph is culled from 100 million tweets and has about 3 million nodes. First I wrote the simulation of the 35 days of data in Clojure and then translated it into Haskell with great help from the glorious #haskell folks. I had to add -A5G -K5G to make it work. It does 10 days OK hovering at 57 GB of RAM; I include profiling of that in sc10days.prof. At first the Haskell executable goes faster than Clojure, not by an order of magnitude, but by 2-3 times per day simulated. (Clojure also fits well in its 32 GB JVM with compressed references.) However, Haskell gets stuck after a while, and for good. Clearly I'm not doing Haskell optimally here, and would appreciate optimization advice. Here's the code: http://github.com/alexy/husky The data and problem description is in http://github.com/alexy/husky/blob/master/Haskell-vs-Clojure-Twitter.md -- also referred from the main README.md. The main is in sc.hs, and the algorithm is in SocRun.hs. The original Clojure is in socrun.clj. This is a continuation of active Twitter research and the results will be published, and I'd really like to make Haskell work at this scale and beyond! The seq's sprinkled already did no good. I ran under ghc 6.10 with -O2 with or without - fvia-C, with no difference in stallling, and am working to bring 6.12 to bear now. Cheers, Alexy

15 41

Re: [Haskell-cafe] music-related problem
by Michael Mossey 04 Jul '10

04 Jul '10

Henning Thielemann wrote: > > On Sun, 4 Jul 2010, Michael Mossey wrote: > >> Henning Thielemann wrote: >>> >>> On Sun, 4 Jul 2010, Michael Mossey wrote: >>> >>>> I can solve a simpler problem which is >>>> >>>> computeSoundedEnd :: Item -> [Item] -> Loc >>>> computeSoundedEnd firstNote notes = compSndEnd (pitch firstNote) notes >> >>> You will certainly not be able to make use of foldl or foldr, but you >>> may use a manual recursion instead. Just like >>> >>> computeAllEnds :: [Item] -> [Item] >> >> What makes it harder than this is that the original document is not a >> single list of Item's--they are broken into measures. > > That is, you want a function of type > > computeAllEnds :: [Measure] -> [Measure] > > ? Right, although it occurs to me that it might be superior to represent the document as [Item] and give Item a measure-number attribute. There are also other measure attributes, so in that case the doc would look like: data Doc = Doc [MeasureInfo] [Item]

1 0