November 2009 - Haskell-Cafe

Re: Iteratee question
by oleg＠okmij.org 26 Nov '09

26 Nov '09

Valery V. Vorotyntsev wrote: > The following pattern appears quite often in my code: > > results <- map someConversion `liftM` replicateM nbytes Iter.head > > The meaning is: take `nbytes' from stream, apply `someConversion' to > every byte and return the list of `results'. > But there's more than one way to do it: > > > i1, i2, i3 :: Monad m => Int -> IterateeG [] Word8 m [String] > > i1 n = map conv `liftM` replicateM n Iter.head > > i2 n = map conv `liftM` joinI (Iter.take n stream2list) > > i3 n = joinI $ Iter.take n $ joinI $ mapStream conv stream2list > Of those i1, i2, i3 which one is "better" and why? Or is there another - > preferable - way of applying iteratees to this task? > My nai:ve guess is that i1 will have worse performance with big n's. It > looks like `i1' is reading bytes one by one, while `i2' takes whole > chunks of data... I'm not sure though. You are correct: i2 and i3 can process a chunk of elements at a time, if an enumerator supplies it. That means an iteratee like i2 or i3 can do more work per invocation -- which is always good. Since you have to get the results as a list, you pretty much have to use stream2list. It should be noted that stream2list isn't very efficient: it returns the accumulated list only when it is done -- which happens when the stream is terminated, normally or abnormally. So, stream2list has a terrible latency, and is useful only at the last stage of processing. I found it is most useful for testing (to see the resulting stream) and for writing Unit tests (to compare the produced results with the expected). For incremental processing, it is better to stay within Iteratees. Although I think i2 and i3 should be close in performance (only benchmarking can tell for sure, of course), i3 is more extensible because stream2list is at the end of the chain. If later on further processing is required (or, the latency imposed by stream2list becomes noticeable), the chain can be easily extended. The advantage of the arrangement of i3 is that if some Iteratee further down the chain decided that it has had enough (elements), Iter.take can quickly skip the remaining elements without the need to convert them.

2 1

haskell-mode.el mailing list (+ dpatch)
by valery.vv＠gmail.com 25 Nov '09

25 Nov '09

Is there anybody except me feeling the need for mailing list and issue tracker for emacs' haskell-mode? Mailing list is a forum to discuss ideas _and_ the area of patch authors' self-advertisement. And issue tracker is a TODO list; it may be useful or annoying, and I think we can live without one for a while. But I vote for haskell-mode.el mailing list. Examples: http://www.haskell.org/mailman/listinfo/xmonad http://code.google.com/p/xmonad/issues/list -- Description of the attached dpatch: * make `inferior-haskell-find-project-root' respect export lists A "hierarchical module" (one or more dots in module name) with an export list cannot be loaded (`C-c C-l') unless there is .cabal file available. That is because regexp current in `inferior-haskell-find-project-root' does not match module headers with export lists. Like this one: module Codec.Binary.MSCP ( -- * Data structures FileHeader(..), CDR(..), -- * Parsing readFile ) where This patch makes the regexp less strict. Have fun! -- vvv <#part type="application/octet-stream" filename="/tmp/XXX/respect-export-lists.dpatch" disposition=attachment description=respect-export-lists.dpatch> <#/part>

10 15

Re. I miss OO
by Philippos Apolinarius 25 Nov '09

25 Nov '09

My experience with objects comes from Common List, Clean, Hasekell and Nice. In all these languages, the function behavior is determined by many objects. I think that this is more powerful and clear than the Java way. In Nice one can see the superiority of type-driven behavior over the Java dot notation, since the dot notation is a particular case of the type driven behavior. To make a long story short, one can apply the dot notation to the first argument, or put it together with the other arguments. For instance, consider the followin init() function (entirely in dot notation): c l a s s DrawLines ext ends Applet { Button ext = new Button ( ”Exi t ” ) ; Button dbutton= new Button ( ”Exec” ) ; TextFi e ld t f= new TextFi e ld ( 1 5 ) ; i n t xx= 5 ; i n i t ( ) { this.setBackground ( Color . l ightGray ) ; t h i s . add ( dbutton ) ; t h i s . add ( t f ) ; t h i s . add ( ext ) ; t h i s . setLayout ( n u l l ) ; ext . r e shape (50 , 30 , 50 , 2 0 ) ; dbutton . r e shape ( 50 , 80 , 80 , 3 0 ) ; t f . r e shape (140 , 80 , 200 , 3 0 ) ; } ... etc. } However, in Nice the method is selected not only by the dotted object, but by all arguments. This becomes clear by placing the dotted object inside the argument list: c l a s s DrawLines ext ends Applet { Button ext = new Button ( ”Exi t ” ) ; Button dbutton= new Button ( ”Exec” ) ; TextFi e ld t f= new TextFi e ld ( 1 5 ) ; i n t xx= 5 ; i n i t ( ) { setBackground (this, Color . l ightGray ) ; add (this, dbutton ) ; t h i s . add ( t f ) ; add (this, ext ) ; setLayout (this, n u l l ) ; reshape (ext, 50 , 30 , 50 , 2 0 ) ; reshape (dbutton, 50 , 80 , 80 , 3 0 ) ; reshape (tf, 140 , 80 , 200 , 3 0 ) ; } ... etc. } In order to see how useful and practical is the generalization of dot selection, let us suppose that one needs to write Lisp-like lists in Nice. I am using Nice because it has both the simpler, more restricted dot notation as Java and Python, and the argument selection, more general and powerful, as Haskell and Lisp. Here is the Nice definition of polymorphic lists: import java . i o . * ; class Lst<T> { T head ; ?Lst<T> t a i l ; } ?Lst<int> cons ( i n t x , ?Lst<int> xs ) { ?Lst<int> newList= new Lst ( head : x , tail : xs ) ; return ( newList ) ; } ?Lst<String> cons ( String x , ?Lst<String> xs ) { ?Lst<String> newList= newLst ( head : x , tail : xs ) ; return ( newList ) ; } String car (? Lst<String> xs ) { if ( xs==null ) return ( "" ) ; else return ( xs.head ) ; } int car (? Lst<int> xs ) { if ( xs==null ) return ( 0 ) ; else return ( xs.head ) ; } boolean isEmpty (? Lst<String> xs )= xs==null ; ?Lst<String> cdr (? Lst<String> xs ) { if ( xs== null ) return ( xs ) ; else return ( xs.tail ) ; } ?Lst<String> cdr (? Lst<String> xs ) { if ( xs== null ) return ( xs ) ; else return ( xs.tail ) ; } ?Lst<int> cdr (? Lst<int> xs ) { if ( xs== null ) return ( xs ) ; else return ( xs.tail ) ; } void main ( String [ ] args ) { InputStreamReader converter = new InputStreamReader ( System.in ) ; Buf feredReader in = new BufferedReader ( converter ) ; ?String s= "Type a sentence and press <Enter>" ; println ( s ) ; s= in.readLine ( ) ; ?Lst<String> words=null ; StringTokenizerst = new StringTokenizer ( s ) ; while ( st.hasMoreTokens ( ) ) { words= cons ( st.nextToken ( ), words ) ; } var xs= words ; while ( ! isEmpty ( xs ) ) { println ( car ( xs ) ) ; xs= cdr ( xs ) ; } } If you want to see how the above program can be generalized into a full fledged Lisp like stucture, take a look at my page on Nice: www.discenda.org. In any case, since Haskell has the more general method selection, there is no need to have the more restricted dot selector. Nice has both method selectors, but I seldom use the dot selector. --- On Wed, 11/25/09, Michael Mossey <mpm(a)alumni.caltech.edu> wrote: From: Michael Mossey <mpm(a)alumni.caltech.edu> Subject: [Haskell-cafe] I miss OO To: haskell-cafe(a)haskell.org Received: Wednesday, November 25, 2009, 1:51 PM 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(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe resizeLeftPane();gLaunchProfile.start('RT_AD_FOOT'); __________________________________________________________________ The new Internet Explorer® 8 - Faster, safer, easier. Optimized for Yahoo! Get it Now for Free! at http://downloads.yahoo.com/ca/internetexplorer/

1 0

ANNOUNCE: feldspar-language
by Emil Axelsson 25 Nov '09

25 Nov '09

I'm happy to announce the first release of Feldspar, which is an embedded domain-specific language with associated code generator mainly targeting DSP algorithms. The language is developed in cooperation by Ericsson, Chalmers University and Eötvös Loránd University. Feldspar stands for *F*unctional *E*mbedded *L*anguage for *DSP* and *PAR*allelism. The language front-end is available on Hackage: http://hackage.haskell.org/package/feldspar-language The back-end C code generator will be uploaded and announced shortly. For more information, see: http://feldspar.sourceforge.net/ / Emil

5 13

ANN: mecha-0.0.4
by Tom Hawkins 25 Nov '09

25 Nov '09

Mecha is a little constructive solid modeling language intended for 3D CAD. This release adds animation capabilities, which use POVRay and FFmpeg behind the scenes. At work we've used Mecha to illustrated the kinematics of a new hydraulic pump design -- I wish I could post the animation, it's pretty cool to watch. http://hackage.haskell.org/package/mecha/

1 0

ANN: atom-0.1.2
by Tom Hawkins 25 Nov '09

25 Nov '09

Atom is a DSL for designing hard realtime embedded software with Haskell. This release adds guarded division operations, 'phase', a new scheduling constraint, and a new rule scheduling algorithm. Many thanks to Lee Pike for his contributions! (Lee, sorry it took so long to get this out.) http://hackage.haskell.org/package/atom/

1 0

Scrap your boilerplate traversals
by rodrigo.bonifacio 25 Nov '09

25 Nov '09

2 1

Pointfree rank-2 typed function
by Bas van Dijk 25 Nov '09

25 Nov '09

Hello, Given this program: ------------------------------------------------------------ {-# LANGUAGE Rank2Types #-} newtype Region s a = Region a unRegion :: forall a s. Region s a -> a unRegion (Region x) = x runRegionPointfull :: forall a. (forall s. Region s a) -> a runRegionPointfull r = unRegion r ------------------------------------------------------------ Is it possible to write the rank-2 typed function 'runRegionPointfull' in pointfree style? Unfortunately the following doesn't typecheck: runRegionPointfree :: forall a. (forall s. Region s a) -> a runRegionPointfree = unRegion Couldn't match expected type `forall s. Region s a' against inferred type `Region s a1' In the expression: unRegion In the definition of `runRegionPointfree': runRegionPointfree = unRegion Why can't the typechecker match `forall s. Region s a' and `Region s a1'? Thanks, Bas

4 5

surrogate code points in a Char
by Manlio Perillo 25 Nov '09

25 Nov '09

Hi. The Unicode Standard (version 4.0, section 3.9, D31 - pag 76) says: """Because surrogate code points are not included in the set of Unicode scalar values, UTF-32 code units in the range 0000D800 .. 0000DFFF are ill-formed""" However GHC does not reject this code units: Prelude> print '\x0000D800' '\55296' Is this a correct behaviour? Note that Python, too (2.5.4, UCS4 build, Linux Debian), accept these code units. Thanks Manlio

4 3

HOpenGL and freeglut rendering problems
by Eitan Goldshtrom 25 Nov '09

25 Nov '09

Hello. I'm new to this mailing list, so I apologize if this question is inappropriate for this list, but I've been looking for a solution to this problem for weeks and I've had no luck. I am trying to write a program with HOpenGL and freeglut, but I can't seem to get it to render. I'm running Ubuntu 9.10 on a DELL 1555 with an ATI Radeon HD 4500. Right now my program just creates a window with a black background. However, when I try to run the program I get the following error: "Unable to create direct context rendering for window 'IGL' This may hurt performance." I've read that this is because of the fglrx driver. The driver uses indirect rendering for OpenGL, but freeglut requires direct rendering? Is there a way to force freeglut to function with indirect rendering? -Eitan

2 1