- Haskell-Cafe - Haskell.org

Talking to the serial (RS232) port from Haskell
by Dan Piponi 25 Apr '07

25 Apr '07

What's the easiest way, from Haskell, to open a serial port (under Windows, say) with the correct baud rate and parity, and send data through it? Is there a serial library for Haskell? -- Dan

2 1

Programming Languages and Mechanised Mathematics -- deadline extension
by Jacques Carette 25 Apr '07

25 Apr '07

[Extended deadline: submissions now due May 2nd, 2007] Programming Languages for Mechanized Mathematics Workshop As part of Calculemus 2007 <http://www.risc.uni-linz.ac.at/about/conferences/Calculemus2007/> Hagenbergs, Austria June 29-30, 2007. The intent of this workshop is to examine more closely the intersection between programming languages and mechanized mathematics systems (MMS). By MMS, we understand computer algebra systems (CAS), [automated] theorem provers (TP/ATP), all heading towards the development of fully unified systems (the MMS), sometimes also called universal mathematical assistant systems (MAS) (see Calculemus 2007 <http://www.risc.uni-linz.ac.at/about/conferences/Calculemus2007/>). There are various ways in which these two subjects of /programming languages/ and /systems for mathematics/ meet: * Many systems for mathematics contain a dedicated programming language. For instance, most computer algebra systems contain a dedicated language (and are frequently built in that same language); some proof assistants (like the Ltac language for Coq) also have an embedded programming language. Note that in many instances this language captures only algorithmic content, and /declarative/ or /representational/ issues are avoided. * The /mathematical languages/ of many systems for mathematics are very close to a functional programming language. For instance the language of ACL2 is just Lisp, and the language of Coq is very close to Haskell. But even the mathematical language of the HOL system can be used as a functional programming language that is very close to ML and Haskell. On the other hand, these languages also contain very rich specification capabilities, which are rarely available in most computation-oriented programming languages. And even then, many specification languages (B, Z, Maude, OBJ3, CASL, etc) can still teach MMSes a trick or two regarding representational power. * Conversely, functional programming languages have been getting "more mathematical" all the time. For instance, they seem to have discovered the value of dependent types rather recently. But they are still not quite ready to 'host' mathematics (the non-success of docon <http://www.haskell.org/docon/> being typical). There are some promising languages on the horizon (Epigram <http://www.e-pig.org/>, Omega <http://web.cecs.pdx.edu/%7Esheard/Omega/index.html>) as well as some hybrid systems (Agda <http://agda.sourceforge.net/>, Focal <http://focal.inria.fr/site/index.php>), although it is unclear if they are truly capable of expressing the full range of ideas present in mathematics. * Systems for mathematics are used to prove programs correct. (One method is to generate "correctness conditions" from a program that has been annotated in the style of Hoare logic and then prove those conditions in a proof assistant.) An interesting question is what improvements are needed for this both on the side of the mathematical systems and on the side of the programming languages. We are interested in all these issues. We hope that a certain synergy will develop between those issues by having them explored in parallel. These issues have a very colourful history. Many programming language innovations first appeared in either CASes or Proof Assistants, before migrating towards more mainstream languages. One can cite (in no particular order) type inference, dependent types, generics, term-rewriting, first-class types, first-class expressions, first-class modules, code extraction, and so on. However, a number of these innovations were never aggressively pursued by system builders, letting them instead be developped (slowly) by programming language researchers. Some, like type inference and generics have flourished. Others, like first-class types and first-class expressions, are not seemingly being researched by anyone. We want to critically examine what has worked, and what has not. Why are all the current ``popular''[1] computer algebra systems untyped? Why are the (strongly typed) proof assistants so much harder to use than a typical CAS? But also look at question like what forms of polymorphism exists in mathematics? What forms of dependent types exist in mathematics? How can MMS regain the upper hand on issues of 'genericity'? What are the biggest barriers to using a more mainstream language as a host language for a CAS or an ATP? This workshop will accept two kinds of submissions: full research papers as well as position papers. Research papers should be nore more than 15 pages in length, and positions papers no more than 3 pages. Submission will be through _EasyChair_. An informal version of the proceedings will be available at the workshop, with a more formal version to appear later. We are looking into having the best papers completed into full papers and published as a special issue of a Journal (details to follow). Important Dates May 02, 2007: Submission Deadline (Extended!) May 30, 2007: Notification June 29-30, 2007: Workshop Program Committee Lennart Augustsson [Credit Suisse] Wieb Bosma [Radboud University Nijmegen, Netherlands] Jacques Carette (co-Chair) [McMaster University, Canada] David Delahaye [CNAM, France] Jean-Christophe Filliâtre [CNRS and Université de Paris-Sud, France] John Harrison [Intel Corporation, USA] Josef Urban [Charles University, Czech Republic] Markus (Makarius) Wenzel [Technische Universität München, Germany] Freek Wiedijk (co-Chair) [Radboud University Nijmegen, Netherlands] Wolfgang Windsteiger [University of Linz, Austria] Location and Registration Location and registration information can be found on the Calculemus <http://www.risc.uni-linz.ac.at/about/conferences/Calculemus2007/> web site. ----------------------------------------------------------------------------- [1] by popular we mean > 1 million users.

1 0

Program optimisation
by Andrew Coppin 25 Apr '07

25 Apr '07

I have *no idea* if this is an appropriate place to put this, but here goes... I have a (presumably) common problem. I have a nice Haskell program. It's compute-bounded, and I'd like to make it go faster. To that end, I've been trying to optimise it. Without going into great detail, the program basically revolves around processing a list and dumping the results into a file. Notable things about this structure: it's *big*, and I only need to *map* over it. Anyway, here's what I did... I wrote a simplified, cut down version of the program so I would have a fixed test case. I compiled it with GHC 6.6 and ran it. It takes 40 seconds to complete. Next, I read the GHC manual. Apparently there's a command-line switch "-O2" which makes GHC try harder to optimise the program. (I had stupidly assumed it always tries to make good code...) The result? The program now does the same job in 30 seconds. That's quite a big speedup just for typing 3 characters! (Gee... I wonder what it does differently? I did notice that the compilation time went from 5 seconds up to 20 seconds. And the *.exe got smaller.) Next I played with profiling. If I'm reading this correctly, the "-s" profile is telling me that my program spends 72% CPU time doing GC. o_O Er... that's really suboptimal. Also - and this is really weird - the "-p" profile tells me that 82% of the program's time is spent in the quant8 function. The source code for this function is precisely quant8 :: Double -> Word8 quant8 x = floor $ x * 0xFF Why that should take 82% CPU when the program is also doing heavy-metal complex number arithmetic and trig functions I have no idea! (Since I took those measurements, I have come up with a theory. When I ask for all these computations to be done... Haskell doesn't actually *do* them. It just stores them up until "needed". It just occurred to me that quant8 is the *last* thing I ask it to do before the code hits a strict ByteString... So is the profiler just misappropriating all the work to quant8 when it's really elsewhere?) OK, so to recap: currently my program takes 30 seconds to run. Next, I changed the 2D lists (i.e., [[x]]) into 1D lists (that is, [x]). The new runtime? 30 seconds. Right, that seems to be no-op. Next I replaced lists with immutable boxed arrays. New runtime: 33 seconds. Ooops. Now, I would have thought an array would make the GC's life *much* easier by replacing tens of thousands of cons cells with one nice big array. But, apparently, no. The profiler output says GC is almost identical. Hmm... weird! Next, I switched to IO-mutable boxed arrays. (With in-place updates.) New runtime: 35 seconds. Da hell...? The more I optimise this program, the slower it goes! :'( Finally, in a fit of desperation, I changed it to *unboxed* arrays. For some reason, you can't have an unboxed array of complex numbers. So I had to make *two* unboxed arrays of doubles, and manually split/join myself. Similar problems happened elsewhere too. Suffice it to say, my program is now vomit-inducingly ugly. It doesn't even *function* correctly any more! (There's a byte alignment issue somewhere... I can't track it down.) New runtime: 15 seconds. I say again: 15 seconds. Changing to an unboxed array has *doubled* the speed. Not only that, the GC report now shows GC as using 7% CPU time, and peak RAM usage has been reduced from 25 MB to 4 MB. The memory graph is now utterly flat, whereas even with IO-mutable arrays with in-place update, it was still fluctuating all over the place. I will mention that the ByteString module was the only thing I would find in all of Haskell for doing binary I/O. The final (fast) program uses an IOUArray Int Word8 to do the binary I/O instead. (What's the difference BTW? Is there one? Other than the name anyway.) Perhaps part of the speed was in avoiding an array type conversion? I don't know. Certainly this is the messiest part, and the part where I suspect my bug is hiding. Finally, in the fast version, quant8 uses way less CPU (more like 50%), and the complex number math uses much more. Really goes look like the profiler being counterintuitive to me... Personally, I find it quite worrying that I had to manually mutilate my program to unbox everything when the compiler is supposed to be able to do such things automatically. Does GHC "know" about the array types? Or are they just a bunch of FFI calls that some 3rd party wrote? When I talk to other people about Haskell, they all say "immutable sucks; that must be SO slow!" and I tell them "yeah, but the compiler can strip almost all of it out automatically". Well, my experience with this program suggests very differently. I do wonder if the program went faster just because unboxed arrays are strict. I couldn't think of any way to make a boxed array be strict. (I tried for ages!) Next task: Attempt to make the program use both cores on my dual-core monster machine for even more speed... A short program synopsys: module Main where init_frame :: [[Complex Double]] next_frame :: [[Complex Double]] -> [[Complex Double]] process :: [[Complex Double]] -> [[Colour]] save_file :: FilePath -> [[Colour]] -> IO () main = do work 0 init_frame work n xss = do save_file ("Frame" ++ show n) (process xss) if n < 500 then work (n+1) (next_frame xss) else return ()

3 2

Re: release plans
by Chad Scherrer 25 Apr '07

25 Apr '07

> What do you think of this plan? Are there features/bug-fixes that you really want to see in 6.8? I'm most anxious for parallel GC - do you think it will be another release or two before this is a reality? Thanks, Chad

3 2

HXT namespace problem
by Martin Huschenbett 25 Apr '07

25 Apr '07

Hi all, I'm currently trying to generate XML documents with HXT. Everything went well but I can't figure out how to generate the "xmlns:..." attributes for the namespaces. My code looks like: runX $ constA (request TableListRequest) >>> root [] [writeA] >>> writeDocument [(a_indent,v_1)] "-" where writeA generates the actual content. This code generates something like: <?xml version="1.0" encoding="UTF-8"?> <soapenv:Envelope> <soapenv:Body> <request:tablelist/> </soapenv:Body> </soapenv:Envelope> But I want it with XML namespaces, i.e.: <?xml version="1.0" encoding="UTF-8"?> <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:request="http://www.officematic.de/domas/request" > <soapenv:Body> <request:tablelist/> </soapenv:Body> </soapenv:Envelope> I tried using "uniqueNamespaces" and "uniqueNamespacesFromDeclAndQNames" but neither worked. Maybe I used them in the wrong part of code. The tree representation my document looks like: ---XTag "/" | +---XTag "{http://schemas.xmlsoap.org/soap/envelope/}soapenv:Envelope" | +---XTag "{http://schemas.xmlsoap.org/soap/envelope/}soapenv:Body" | +---XTag "{http://www.officematic.de/domas/request}request:tablelist" and for me this looks like if there is enough namespace information provided. I would appreciate any help, Martin.

2 2

Why Perl is more learnable than Haskell
by kynn 25 Apr '07

25 Apr '07

Perl is a large, ugly, messy language filled with quirks and eccentricities, while Haskell is an extremely elegant language whose design is guided by a few overriding ideas. (Or so I'm told.) Based on this one would think that it would be much easier to learn Haskell than to learn Perl, but my experience is exactly the opposite. I've been wanting to learn Haskell for years, literally, but it has been a case of Sisyphus and the Rock. Despite my efforts, I never get to the level of expertise that would make Haskell useful to me. (I don't need elegant factorial or Fibonacci functions in my everyday work.) Sooner or later life intervenes: big project due, long trip abroad, etc., and when I finally return to learning Haskell, I have forgotten almost everything I learned and I have to start all over again. (BTW, I've heard similar stories from many wannabe Haskell programmers.) Arguably, this experience means that I have no business learning Haskell, because it's just not relevant to my work. Maybe so, but I still cling to the fanciful notion that if I knew Haskell well enough, I would find plenty of stuff to do with it in my daily work... Anyway, in contrast to my struggle with Haskell, I learned Perl incrementally over the years, by using it in daily little projects, ranging at first from command-line snippets to 100-line self-contained scripts, and moving on to larger, hairier projects. This daily reinforcement of the little bits of Perl I was picking up was crucial to my being able to retain it and move forward. Perhaps Haskell will never lend itself to something like a Perl one-liner, but still I wish that there were books on Haskell that focused on making Haskell useful to the learner as quickly as possible... If such already exist and I've missed it, please let me know. Or I can always wait until I retire; then I'll probably have a sufficiently long stretch of free time in my hands (barring any operations, strokes, heart attacks, hip fractures, etc.). I bet I could start a Haskell Wannabes Club at the nursing home... kj -- View this message in context: http://www.nabble.com/Why-Perl-is-more-learnable-than-Haskell-tf3559193.htm… Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

48 77

Re: [Haskell] ANN: IOSpec 0.1
by Wouter Swierstra 25 Apr '07

25 Apr '07

Hi Stefan, > in the Teletype module, it would probably be better to reflect > IOTeletype operations as: > > data Action a = Finish a | Put Char (Action a) | Get (Char -> > Action a) > > That way, there is no need to use (unobservable) laziness. I'm afraid I've lost you. How does this differ from the current definition of IOTeletype? Thanks, Wouter This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.

1 0

Re: [Haskell] ANN: IOSpec 0.1
by Wouter Swierstra 25 Apr '07

25 Apr '07

Hi Twan, > Wouter Swierstra wrote: >> Test.IOSpec Version 1.0 > Shouldn't that be 0.1? You're right of course. > You use Dynamic for the data type in IORefs, this has the > unfortunate consequence of needing Typeable constraints. You could > try to use unsafeCoerce instead, > > type Data = () > > unsafeToData :: a -> Data > > unsafeToData = unsafeCoerce > > unsafeFromData :: Data -> a > > unsafeFromData = unsafeCoerce > > I think this should be just as safe as Dynamic, since internally > Dynamic uses unsafeCoerce as well. Just steal the details from there. I'm not entirely happy with the "unsafeFromDynamic" approach I use at the moment. GHC can derive instances of Typeable, so the price you have to pay is not too high. The real problem is that Haskell's type system is not expressive enough to cleanly describe the type of the heap (I know, I could be using HList, but still...). If you're interested, I also have a dependently typed version of the code for IORefs that allows heterogeneous, type-safe, well-scoped pointers. I should probably mention that an ulterior motive for this work is integrating IO in dependently typed languages such as Epigram. It is all, of course, still very much subject to active research. Wouter This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.

1 0

Re: [Haskell] ANN: IOSpec 0.1
by Wouter Swierstra 25 Apr '07

25 Apr '07

Hi Isaac, <Moving to Haskell-cafe> > How does or might this relate to the typeclass-based Restricted IO > monad > http://article.gmane.org/gmane.comp.lang.haskell.general/14526 > ? RIO's technique has the advantage that multiple capabilities can be > easily combined in one use of the monad - but this manner of using > typeclasses might interfere with how testable it is? (I think that > should be okay... Also that this is a really neat project - > incremental > progress on taming Haskell IO in practice!) Stefan is absolutely right. The RIO, as far as I remember, restricts which parts of the IO monad you use. The same could be said for the Test.IOSpec modules. However, the Test.IOSpec also give you a pure specification of the functions you are using. This is very important if you want to trace/debug an execution of you code - you can see how the state of your machine changes at every step. There's also a bit finer control over how you test your functions: concurrent code is parameterised over the scheduler, for instance. Both these aren't possible with the RIO approach. > P.S. why >> *If you're an ICFP referee, you may want to avoid reading any >> further* ICFP has a double-blind review process: if I were to submit a paper, I should do so anonymously. The idea behind it all is that if the reviewers don't know who the author of a paper is, they can't be prejudiced. The code I just released is described in a paper submitted to ICFP. All the best, Wouter This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.

1 0

ICFP Programming Contest 2007
by Johan Jeuring 25 Apr '07

25 Apr '07

Want to show off your programming skills? Your favorite programming language? Your best programming tools? Join the ICFP Programming Contest 2007! The 10th ICFP Programming Contest celebrates a decade of contests. This is one of the world's most advanced and prestiguous programming contest you can enter. For free! Book July 20 - 23, 2007. Check out http://www.icfpcontest.org/.

1 0