November 2010 - Haskell-Cafe

"Haskell is a scripting language inspired by Python."
by Jonathan Geddes 12 Nov '10

12 Nov '10

This is off topic (almost regardless of the topic), but It gave me a laugh. Hope you all enjoy it, too. I was telling a friend about the power and elegance of Haskell. When I mentioned that it has influenced many other programming languages, including his favorite language (Python) he retorted by saying that I was mistaken and it was, in fact, the other way around: Python inspired Haskell. The following link was his source of information (or FUD, as the case may be). http://www.datarecoverylabs.com/ultimate-computer-language-guide.html It's called "The *Ultimate* Computer Language Guide," and it's on the internets, so it must be correct, right? --Jonathan

31 50

ANNOUNCE: The Fibon benchmark suite (v0.2.0)
by David Peixotto 12 Nov '10

12 Nov '10

I'm pleased to announce the release of the Fibon benchmark tools and suite. Fibon is a set of tools for running and analyzing benchmark programs in Haskell. Most importantly, it includes an optional set of benchmark programs including many programs taken from the Hackage open source repository. The source code for the tools and benchmarks are available on github https://github.com/dmpots/fibon http://github.com/dmpots/fibon-benchmarks The Fibon tools (without the benchmarks) are available on hackage. http://hackage.haskell.org/package/fibon The package needs to be unpacked and built in place to be able to run any benchmarks. It can be used with the official Fibon benchmarks or you can create your own suite and just use Fibon to run and analyze your benchmark programs. Some more documentation is available on the fibon wiki https://github.com/dmpots/fibon/wiki Fibon Tools =================================================================== Fibon is a pure Haskell framework for running and analyzing benchmark programs. Cabal is used for building the benchmarks. The benchmark harness, configuration files, and benchmark descriptions are all written in Haskell. The benchmark descriptions and run configurations are all statically compiled into the benchmark runner to ensure that configuration errors are found at compile time. The Fibon tools are not tied to any compiler infrastructure and can build benchmarks using any compiler supported by cabal. However, there are some extra features available when using GHC to build the benchmarks: * Support in config files for using an inplace GHC HEAD build * Support in `fibon-run` for collecting GC stats from GHC compiled programs * Support in `fibon-analyse` for reading GC stats from Fibon result files The Fibon Benchmark Suite =================================================================== The Fibon benchmark suite currently contains 34 benchmarks from a variety of sources. The individual benchmarks and lines of code are given below. Dph _DphLib 316 Dotp 308 Qsort 236 QuickHull 680 Sumsq 72 ------------------------------ TOTAL 1612 Hackage Agum 786 Bzlib 432 Cpsa 11582 Crypto 4486 Fgl 3834 Fst 4532 Funsat 16085 Gf 23970 HaLeX 4035 Happy 5833 Hgalib 819 Palindromes 496 Pappy 7313 QuickCheck 4495 Regex 6873 Simgi 5134 TernaryTrees 722 Xsact 2783 ------------------------------ TOTAL 104210 Repa _RepaLib 8775 Blur 77 FFT2d 89 FFT3d 103 Laplace 274 MMult 133 ------------------------------ TOTAL 9451 Shootout BinaryTrees 63 ChameneosRedux 96 Fannkuch 27 Mandelbrot 68 Nbody 192 Pidigits 26 SpectralNorm 97 ------------------------------ TOTAL 569

2 4

Manatee - The Haskell/Gtk+ Integrated Live Environment first version release!
by Andy Stewart 12 Nov '10

12 Nov '10

Hi all, I am proud to announce the release my gtk2hs project : Manatee - The Haskell/Gtk+ Integrated Live Environment http://hackage.haskell.org/package/manatee Screenshots at : http:goo.gl/MkVw Code at https://patch-tag.com/r/AndyStewart/ beginning with manatee-* Manatee is Haskell integrated environment written in Haskell. The goal of the Manatee project is to provide a fast, safe and flexible integrated environment for haskell hacking. You can consider it is new environment mix Gnome and Emacs. Like Gnome to provide friendly graphics interface and work efficient like Emacs. Manatee use multi-processes framework, any sub-module running in separate process to protected core won't crash. So it minimize your losses when some unexpected exception throw in extension. Now i have implement below sub-modules in Manatee: Editor Webkit Browser File Manager Image Viewer IRC Client Multimedia Player PDF Viewer Process Manager RSS/Atom reader >From some friends feedback, manatee can't work in XMonad, i will fix it soon. You can play it in Gnome. Enjoy! :) Below are steps to build Manatee: 1) Install C library: In Debian use below command: sudo aptitude install libgtksourceview2.0-dev libgconf2-dev libwebkit-dev libcurl4-openssl-dev libgtkimageview-dev libpoppler-glib-dev poppler-data libtagc0-dev -y 2) Install Gtk2hs: cabal install gtk2hs-buildtools gtk And make sure HOME.cabalbin/ in your PATH. 3) Install Manatee: cabal install manatee-core manatee-anything manatee-browser manatee-editor manatee-filemanager manatee-imageviewer manatee-ircclient manatee-mplayer manatee-pdfviewer manatee-processmanager manatee-reader manatee That's all, then type command manatee to play it! :) "manatee-core" "manatee-anything" "manatee" are core packages, must be install, other extension package you can choose you want. Example, if you not install manatee-imageviewer, when you open Image file, manatee will call default image-viewer in your system instead. Manatee will show you "search interface" when you startup it. You can type some filepath or url to open it, example, you can type Haskell file to open in editor, and type url to open in browser. Below are quick play keys: "F2" ==> startProcessManager "F3" ==> startFeedReader "F4" ==> startFileManager "F5" ==> startBrowser "F6" ==> loginIrcDefaultChannel "F7" ==> startIrc Manatee project still in early develop stage, just core framework finish, many details still not perfect. But i think it's good start to build Real-World application in Haskell. Below are high task in my TODO list: Perfect current sub-module: IDE features, code completion browser JavaScript framework graphics custom system etc. Terminal emulator: support MVC design, not like VTE widget Mail-client BT-Client Proxy bridge: to build uniform proxy interface to fighting GFW!!! Jabbar client: video support etc. Spell checker CHM viewer DVI viewer LaTex editor PS viewer Multi-thread download manager Org-Mode : http://orgmode.org/ Twitter client Network toolkit: sniffer etc. Multi-Language translater offline support Too many ideas lying in my TODO list.... Any suggestion and contribution are welcome! :) -- Andy

3 7

Opportunity for Haskell porting to java at R&D labs in Bay Area, CA
by Padma 12 Nov '10

12 Nov '10

We are looking for a entry level Haskell programmer who has experience in porting from Haskell to java. Please contact me by Email or you can call me at 408-207-9367. LOCATION: SUNNYVALE, CA DURATION: 6 MONTHS Degree: Bs or Ms or Ph.D Start immediately Good experience in porting particularly from Haskell to java environment. Check and validate smooth functioning of the system.(After porting is done) This is a R&D project. (prior experience is desired) Good experience in testing and compiling. Regards, Padma SRAOSS INC. 5300 Stevens Creek Blvd Suite 460 San Jose,CA 95129 Direct:(408) 207-9367 Tel: (408) 855-8200 x 321 Fax: (408) 855-8206 <blocked::mailto:padma@sraoss.com> padma(a)sraoss.com <blocked::http://www.sraoss.com/> www.sraoss.com <blocked::http://www.sra.co.jp/> www.sra.co.jp

8 8

Re: Haskell-cafe] Serialization of (a -> b) and IO a
by John Lato 12 Nov '10

12 Nov '10

> > Message: 3 > Date: Thu, 11 Nov 2010 18:56:00 +0100 > From: Sjoerd Visscher <sjoerd(a)w3future.com> > > On Nov 11, 2010, at 6:34 PM, John Lato wrote: > > > I don't know to what extent it would apply in this hypothetical > situation, but ghc (and probably other compilers) rely upon Haskell's > semantics in performing various code transformations. If you break the > semantics some transformations become invalid, resulting in incorrect code. > > > > I've experienced this with code that violated ref. transparency. The > program behavior changed depending on the compiler's optimization settings. > I'm not keen to go back to that. > > Then don't do that. Being able to serialize functions is just as dangerous > as having unsafePerformIO. If you don't use it, you don't have problems. > If you do use "serialize", I think it would cause problems most of the time. A pure serialization would violate referential transparency. GHC relies upon referential transparency for some transformations to be valid. Therefore it's not possible to use a pure serialization function safely unless the user can guarantee that it's only used in a referentially transparent manner, which is an extremely high barrier IMO (higher than for unsafePerformIO). John

1 0

Re: [Haskell-cafe] Serialization of (a -> b) and IO a
by John Lato 12 Nov '10

12 Nov '10

> > From: Sjoerd Visscher <sjoerd(a)w3future.com> > > On Nov 11, 2010, at 3:36 PM, Dan Doel wrote: > > > On Thursday 11 November 2010 6:22:06 am Sjoerd Visscher wrote: > > > >> The reasoning above is used regularly to shoot down some really useful > >> functionality. So what would go wrong if we chose to take the practical > >> path, and leave aside the theoretical issues? > > > > You would lose many uses of equational reasoning in your programs. Have > you > > every substituted 'x * 2' for the expression 'x + x' in one of your > programs, > > or vice versa? You can no longer do that, because someone may be > serializing > > the function you're writing, checking how it's implemented, and relying > it. > > > Yes, but it would not break any existing code. It would only break code > that knowingly did the wrong thing. > > > We already have a weak case of this, since (\x -> undefined x) can be > > distinguished from undefined using seq, but that can be hand-waved away > by not > > worrying about bottoms so much. That isn't going to work for serialize. > > Why not? > I don't know to what extent it would apply in this hypothetical situation, but ghc (and probably other compilers) rely upon Haskell's semantics in performing various code transformations. If you break the semantics some transformations become invalid, resulting in incorrect code. I've experienced this with code that violated ref. transparency. The program behavior changed depending on the compiler's optimization settings. I'm not keen to go back to that. I think the only way this would work would be if you consider functions to be equal only to themselves, i.e. "x+x" and "2*x" are not equal. That's not a trade-off I would be willing to make. John

3 3

Fwd: Re: [Haskell-cafe] Type Directed Name Resolution
by John Lask 12 Nov '10

12 Nov '10

> On Thu, Nov 11, 2010 at 8:16 PM, John Lask<jvlask(a)hotmail.com> wrote: >> consider "length" ... >> >> I have records with the attribute length, length can be given as an Int, >> Double, Float or maybe as a constructed type "Length", length's use as a >> record selector would also clash with List.length. All these have the same >> denotation. >> >> should I then seporate into int_length, float_length, or use rec1_length, >> rec2_length etc etc... > > class Lengthy a where > type LengthType a > length :: a -> LengthType a > > This extends easily to lenses if you want setters. > to make use of the class Lengthy I still need to define record selectors with different names, which is exactly the point I am making... ....ie data Record = RecLen { rec_length :: ... } instance Lengthy Record where length = rec_length >> This is easily handled in C, Pascal, PL/1, Cobol why not in Haskell ? > > By this argument, Haskell should provide global mutable state and > allow side-effects universally. > no, but these languages have their strengths as well, for example Cobol PIC strings format currency values very nicely and it would be great if there were a Haskell library that could do the same. Not to mention currency values! The point is that languages are often constructed with a purpose in mind, at which they tend to be particularly good. Haskell has traditionally been a test bed for type system innovation, which is why we all like it so much. As and if, the usage of Haskell broadens, then domains of application stray into areas of application for which it is not ideally suited, in those circumstances why not consider features of other languages which handle those use cases well. (for some definition of "well") By the way I am not arguing for TDNR, merely that all is not well with haskell records.

3 2

Rebindable record syntax
by Philippa Cowderoy 11 Nov '10

11 Nov '10

I stood up and suggested rebindable record syntax at Anglohaskell earlier this year, but never got round to posting a proposal. Given the TDNR discussion, it seems timely to link everyone to what I'd got round to writing: http://flippac.org/RebindableRecordSyntax.html Apologies for the lack of concrete examples: if anyone's interested I'll try to crank some out soon, specific requests would help. I probably don't have the energy to champion this properly on my own, so speak up if you think it's a good idea! Incidentally, I believe something similar has been proposed elsewhere - it's also possible I'd seen it before and forgotten before "rediscovering" the idea. -- flippa(a)flippac.org

1 0

Fwd: Re: [Haskell-cafe] Type Directed Name Resolution
by John Lask 11 Nov '10

11 Nov '10

> > On 12/11/2010, at 2:16 PM, John Lask wrote: > >> On 12/11/2010 9:22 AM, Richard O'Keefe wrote: >>> >>> I'm afraid it's not a *convincing* use case. >>> It's not convincing because here "owner" *means different things*. >> >> >> consider "length" ... >> >> I have records with the attribute length, length can be given as an Int, Double, Float or maybe as a constructed type "Length", length's use as a record selector would also clash with List.length. All these have the same denotation. > > "All these have the same denotation"? I am extremely confused here. > AH! You mean you call them all by the same name. Well yes, that's > the problem, right there. > > I remind readers once again that in SML record selectors *don't* clash with > names of functions. I am not concerned here to argue either for or against > SML-style records and their selectors, only to point out that wanting > *record fields* whose significance depends on the record they select from > is *NOT* the same thing as TDNR in principle, so that arguments for that > don't even come close to being arguments for TDNR as such. > >> >> should I then seporate into int_length, float_length, or use rec1_length, rec2_length etc etc... > > No, the differing result types are an epiphenomenon of their differing > semantics. > > The length of a piece of string is a physical length. length of string measured in CM's, in MM, in Inches, as an Int, float ... they all denote the same thing modulo some theory. You could argue that a length in CM's measured as a float is semantically different to that of CM's as an Int, which it is, but somewhere along the line those semantic differences become irrelevant to the abstract domain of application, your model, and it is that model that you wish to represent as a program, although you need to deal with the concrete differences as an implementation detail. > The length of a lecture is a time. > The length of a queue is a natural number (counting people). > The length of a book is a positive integer (counting say pages, or words) > The length of a vowel is a relative time. > > These quantities are measured differently, combined differently, and assessed > differently. Calling them all "length" is a METAPHOR. (There are at least > three metaphors in the list above: time-is-space, codex-is-scroll, and > a form of metonomy.) > >> for proper name space management why should I have to define each record >> that defines a length field with different representation in distinct modules, or with different names for the field label when they denote the same thing? > > But you just explained that while they may have the same denotation (the > identifier), what it DENOTES is NOT the same (otherwise they could not > be different types). > you are right > As SML proves, having record-sensitive field names is a *different* > question from Type Directed Name Resolution applied to plain function names. >> agreed >> This is easily handled in C, Pascal, PL/1, Cobol why not in Haskell ? > > But it *isn't* handled *AT ALL* in any of those languages, let alone > handled easily. > > In C, Pascal, PL/I, and COBOL field names are *not* values. > C, Pascal, and PL/I let you pass functions as parameters to functions. > But you cannot pass field names that way. The only thing you can do > with a field name is apply it *immediately* to a record. And those > languages don't have type variables, so when you apply a selector to > a record, you know then and there what the type is. > > If what you want is some sort of record facility at least as good as > SML's, fine. What I am arguing against is anything resembling Type > Directed Name Resolution (alias ad hoc overloading) being applied to > plain ordinary functions. that's something like what I want. I am not argiung in favor of TDNR, only that haskell record system needs improvement, particularly the scoping of field labels. > > (By the way, if the field names of a record type are visible outside its > module, I start wondering why.) > > depends on what your using them for .. >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe(a)haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > > >

1 0

[ANNOUNCE] csound-expression - csound combinator library
by Anton Kholomiov 11 Nov '10

11 Nov '10

Hi, I'm glad to announce csound combinator library. It features liberation from id-style csound code, haskore-like composition structures, type-safe composable opcodes and simple instrument interface (no interface at all, instrument is just a function from some note representation to signal). http://hackage.haskell.org/package/csound-expression Anton

3 6