- Haskell-Cafe - Haskell.org

BostonHaskell: Next meeting - July 16th at MIT CSAIL Reading Room (32-G882)
by Ravi Nanavati 07 Jul '09

07 Jul '09

I'm pleased to announce the July meeting of the Boston Area Haskell Users' Group. Based on the feedback from the June meeting and the constraints of our speakers, the July meeting has been scheduled for Thursday, July 16th from 6:30pm - 8:30pm. Like the June meeting, it will be held in the MIT CSAIL Reading Room (32-G882, i.e. a room on the 8th floor of the Gates Tower of the MIT's Stata Center at 32 Vassar St in Cambridge, MA). We have the following two talks scheduled: "An Introduction to GHC Hacking" by Alec Heller "Haskell on the iPhone" by Ryan Trinkle (a more in-depth discussion than his on-the-spot Lightning Talk last month). As always, there will be a break between the talks for discussion and mingling. We have openings for Lightning Talks (5-minute talk, 2-minute Q&A) during that period. We are also open to short, relevant advertisements (like my Hac Phi plug last month). If you're interested in giving a Lightning Talk, have an advertisement you'd like to share or are interested in speaking at a future meeting, please contact me at ravi_n(a)alum.mit.edu. I'd also appreciate it if people who can (and can't) attend this meeting fill out the attendance poll here: http://www.learnmyself.com/poll10828x74C54f13 I apologize for the URL, but Google Groups seems to ban JavaScript and I didn't want to delay this announcement while I tried to come up with something more convenient. Responding to this poll will help with two things: 1. Getting an idea of what fraction of the Boston-area Haskell community can and can't attend this meeting (to help with future scheduling). 2. Giving me an estimated count of attendees, should I manage to secure a sponsor for refreshments. Sponsorship of or other assistance with refreshments is still being eagerly solicited. If you have any questions about the meeting please send them to the BostonHaskell mailing list: bostonhaskell(a)googlegroups.com or contact me directly. I look forward to seeing many Boston-area Haskellers at the July meeting! Thank you, - Ravi Nanavati

1 0

Catering for similar operations with and without state
by Phil 07 Jul '09

07 Jul '09

Hi, I'm trying to think around a problem which is causing me some difficulty in Haskell. I'm representing a stateful computation using a State Transform - which works fine. Problem is in order to add flexibility to my program I want to performs the same operation using different techniques - most of which require no state. My program at the moment is a stack of state monads/transforms. I have a random number generator as a state monad (seed=state), feeding a Box Muller (normal) generator implemented as a state transform (state is 'maybe' normal, so it only spits out 1 normal at a time), which in turn feeds another state machine. This all works fine, but I want to add flexibility so that I can chop and change the Box Muller algorithm with any number of other normal generators. Problem is most of them do not need to carry around state at all. This leaves me with a messy solution of implementing lots of state monads that don't actually have a state, if I want to maintain the current paradigm. This strikes me as really messy - so I'm hoping someone can point me in the direction of a more sensible approach? Currently I have my Box Muller implemented as below - this works: class NormalClass myType where generateNormal :: myType Double type BoxMullerStateT = StateT (Maybe Double) type BoxMullerRandomStateStack = BoxMullerStateT MyRngState instance NormalClass BoxMullerRandomStateStack where generateNormal = StateT $ \s -> case s of Just d -> return (d,Nothing) Nothing -> do qrnBaseList <- nextRand let (norm1,norm2) = boxMuller (head qrnBaseList) (head $ tail qrnBaseList) return (norm1,Just norm2) But say I have another instance of my NormalClass that doesn't need to be stateful, that is generateNormal() is a pure function. How can I represent this without breaking my whole stack? I've pretty much backed myself into a corner here as my main() code expects to evalStateT on my NormalClass: main = do let sumOfPayOffs = evalState normalState (1,[3,5]) -- (ranq1Init 981110) where mcState = execStateT (do replicateM_ iterations mc) 0 normalState = evalStateT mcState Nothing If it wasn't for this I was thinking about implementing the IdentityT transformer to provide a more elegant pass-through. I've never tried designing my own Monad from scratch but this crossed my mind as another possibillity - i.e. a Monad that either has a state of maybe double, or has no state at all? I may be talking rubbish here of course :-) I'm pretty daunted by where to even start - but I want to improve this as the quick and dirty solution of implementing a load of state monads with no state just to cater for the above method strikes me as very ugly, and as I can easily see ways of doing this in C or C++, I figure there must be a better approach in Haskell - I'm just thinking in the right way! Any advice or hints would be great, Cheers, Phil.

3 2

LINQ, SQL and hs-dotnet
by Günther Schmidt 06 Jul '09

06 Jul '09

Hi all, is there anyone who has already tried using LINQ2SQL with hs-dotnet and would care to share the experience? I'm trying to figure out what exactly it would take to access an SQL database via LINQ / hs-dotnet. Ie. whether or not it's necessary to create Entity classes, or if one can just use LINQ to generate SQL. Günther

1 0

Haskell Platform 2009.2.0.1 and GLUT32.DLL on Windows: which version?
by Peter Verswyvelen 06 Jul '09

06 Jul '09

I know GLUT32.DLL is not bundled with the Haskell Platform installer, but which GLUT32.DLL should I use? Every DLL I tried (even building FreeGLUT myself<http://netsuperbrain.com/blog/posts/freeglut-windows-hopengl-hglut/#more-136>) gives the error: *"The procedure entry point glutAddMenuEntry could not be located in the dynamic library glut32.dll"* Any hints as to which glut32 version to use would be highly appreciated. Thanks, Peter

2 2

Monoid wants a (++) equivalent
by Bryan O'Sullivan 06 Jul '09

06 Jul '09

I've thought for a while that it would be very nice indeed if the Monoid class had a more concise operator for infix appending than "a `mappend` b". I wonder if other people are of a similar opinion, and if so, whether this is worth submitting a libraries@ proposal over.

36 63

Documentation design
by Isaac Dupree 06 Jul '09

06 Jul '09

(for reference, here's the blog-post I wrote that inspired me to ask this list for advice. I'll explain everything in this email anyway though. http://haddock2009.wordpress.com/2009/06/23/how-to-navigate-your-code/ ) My challenge: getting to know an existing code-base quickly and easily, so that I can hack on it. Haddock and HsColour are already pretty helpful at this, but they could be more helpful. (haddock with --ignore-all-exports, i.e. cabal haddock --internal, especially) My dream situation: both haddock-pages and hscolour-pages would be super-hyperlinked and super-readable. For example, haddock would list all a module's definitions, not just its exports. In HsColoured source, every identifier would link to its definition or the haddockumentation of its definition. and so forth. It would be so much easier to generate and browse this in HTML, than to get an IDE working, and it would be so much more readable than a mere text-editor (even with syntax hilighting) and quicker clicking on hyperlinks than grepping for everything. Actually I don't have the resources to worry about designing any HsColour stuff right now (its current design is mainly just a lexeme highlighter). But, with your advices, I can design an improvement on Haddock's ignore-exports mode, which currently has a few shortcomings: 1. you can't tell which identifiers in a module are exported 2. it doesn't document a module's re-exports at all 3. it still obeys {-# OPTIONS_HADDOCK hide #-} et al, even when they're not appropriate for reading documentation of internals 4. 2+3 means that some things may be found nowhere in the documentation at all! Not quite satisfying for something invoked by `cabal haddock --internal`. (Here's a haddock-generated page you can look at so you can figure out the formatting-details I'll be describing: http://www.haskell.org/ghc/docs/latest/html/libraries/base/Data-List.html and its source code http://www.haskell.org/ghc/docs/latest/html/libraries/base/src/Data-List.ht… ) The ideal haddockumentation-formatting for this purpose isn't quite obvious though. For example, sometimes you want to think about a module in terms of its abstract interface, but sometimes you want to figure out how it's implemented (without reverting completely to text based code browsing). Maybe a compromise of some sort would be good. so... Here's a proposal, for a new mode (`haddock --all-internal`?, to be invoked by `cabal haddock --internal` rather than --internal's current effect of ignore-all-exports) : Files with no explicit export list can be treated as-is anyway. For all files that have an explicit export list, generate the synopsis-of-exports near the top, as usual. But have the index link, generally, to where functions are originally defined (modulo being from a non-internally-documented separate package, where it should link to the appropriate place), and have the fuller documentation below be a compilation of the identifiers *defined* in this module. Actually that would need some revision because the sections and subsections -- *, -- **, etc. defined in the export-list in the .hs, actually are displayed 1. above the table of contents, linking to places in 2. the full list of definitions. Which might be defined in the module in a different order than they're listed in the export list. Why not add the sections into the synopsis? In this case, instead of adding them to the main doc section. But hmm... in ordinary non-internal documentation, would it be nice to *additionally* have the sections marked in the synopsis (in addition to in the Contents and in the main docs section)? Maybe this mode should also abstain from "hiding" any module, because that would cause missing docs. Etc. Questions? Comments? Opinions? Does anyone want this feature, and/or not think it's particularly useful? -Isaac

3 2

How to pretty print code efficiently
by John Ky 06 Jul '09

06 Jul '09

Hi, Currently I'm pretty printing code by building arrays of strings and calling indent. For example: instance JavaPrintableNamed AST.EnumeratedType where javaLinesNamed parentName (AST.EnumeratedType memberDefinitions) = [ "public enum " ++ asJavaId(parentName) , "{" ] ++ memberCodeLines ++ [ "}" , "" ] where memberCodeLines = indent $ javaLines memberDefinitions The indent function takes a list of strings and adds an indent to the beginning of every line. I can imagine this to be very inefficient as it builds many strings and concatenates them. In Ruby, I might do the same thing like this: class EnumeratedType < JavaPrintableNamed def writeTo(writer) writer.print "public enum " writer.puts self.asJavaId writer.puts "{" writer.indent do self.memberDefinitions.writeTo(writer) writer.puts end where above, the writer.indent takes care of the indent, and everything is appended to a stream, which doesn't seem so bad in terms of efficiency. I'm looking for a way to do something similar in Haskell. Anyone can give me a hand? Thanks -John

4 5

Read & Show instance generation for GADTs?
by Conal Elliott 05 Jul '09

05 Jul '09

Are there any tools for generating Show & Read instances for GADTs? - Conal

1 0

ANN: AC-Vector, AC-Colour and AC-EasyRaster-GTK
by Andrew Coppin 04 Jul '09

04 Jul '09

OK, so having released AC-HalfInteger, I got slightly carried away and released three other small packages. These are packages that many programs I write all end up using. I'm forever copying these files, so I made them into actual bonafide packages. http://hackage.haskell.org/package/AC-Vector-1.1.1 This provides two types, Vector2 and Vector3, which are unboxed vectors of Doubles, with arithmetic, dot product and cross product, and a few other useful items. http://hackage.haskell.org/package/AC-Colour-1.1.1 This provides two types, Colour and Colour8. Both implement simple RGB colour types with arithmetic. Colour has unboxed Double fields, and Colour8 has unboxed Word8 fields. My usual workflow is to do all the image generation with Colour, and to convert to Colour8 just before the data hits the I/O channels. You can, however, do arithmetic directly on Colour8. (I haven't extensively tested that it works properly though...) http://hackage.haskell.org/package/AC-EasyRaster-GTK-1.1.1 This is a layer over Gtk2hs. As you all probably know, Gtk2hs provides a Cairo binding that makes vector graphics wonderfully easy. However, *bitmapped* graphics is darned tricky. I basically had to sit in the #haskell channel with Duncan for a few hours trying to figure out how the hell to do it. This knowledge is now codified in the above package. Load it up and you don't need to know a thing about GTK; you can just create an ImageBuffer, write some pixels to it (efficiently!), save it to disk or display it on screen. (But you *can* access the underlying GTK+ resources if you wish...) In other news, it appears that the batch job to generate the documentation just ran, so you can view it all online. :-D Comments, suggestions, random flames, etc... [I'm particularly curios to know what Duncan will make of the GTK thing...]

4 6

Re: [Haskell-cafe] ANN: AC-Vector, AC-Colour and AC-EasyRaster-GTK
by Andrew Coppin 04 Jul '09

04 Jul '09

Paul Johnson wrote: > Andrew Coppin wrote: >> Well, no, because now I'm going to have to spend a few hours trying >> to find out what CIE is before I can even use that library. >> >> I think really it's just aimed at a different problem. It looks like >> it's trying to specify actual real-world colours. [It's news to me >> that this isn't fundamentally impossible...] I'm only trying to >> specify colours on a computer screen. And as we all know, computer >> screens aren't calibrated in any way, and the same RGB value looks >> different on each display. But then, I'm only trying to write a >> fractal generator, so CIE specifications are somewhat overkill here. ;-) > Your display may not be calibrated, but those used for graphic design > certainly are. Indeed. And if you're in any kind of position where you *care* about such things, you should be using color, not AC-Colour. If, however, you just want to throw together pretty pictures, AC-Colour is simpler and easier. Different libraries for slightly different tasks. ;-) > On the package naming front: I appreciate your wish to avoid just > having another "colour" library. But "AC_Colour" doesn't help much. > "Simple_colour" might be better. Mmm, yeah. Naming everything with "AC" precludes name clashes and doesn't require too much thinking. Coming up with a better name requires thinking about what actually makes your package unique. And, of course, if another package comes along, that analysis may change. (E.g., I seem to recall there's a "newbinary" package which has actually been long since superceeded - so not so "new" any more!) If I name my package simple-colour, and then somebody else makes an even simpler one... the name becomes kind of meaningless. (Admitedly there's not too much danger of this happening...) I just like the idea of having definitely unique, distinctive package names. Otherwise I'd have to come up with stuff like geovector and trivicolour and so on... Arguably EasyRaster-GTK should have been a sufficiently unique name by itself though.

1 0