September 2001 - Haskell

RE: Application letters at the Haskell workshop: suggestion
by brk＠jenkon.com 14 Sep '01

14 Sep '01

> I think there's a lot of truth in all you said in your message and I > make the following comment merely as a point of information. [Bryn Keller] Thanks very much, I was hoping my comments would be taken constructively. > > I think I speak for the majority of 'industrial' programmers when I > > say Haskell is a very difficult language to approach. I believe a > > great deal of this difficulty stems from lack of documentation. > > I think the Advanced Functional Programming books (which are > proceedings of the advanced functional programming summer schools) > are great for explaining some of the tricks/idioms required to > use Haskell effectively for larger systems. > > But there's still the problem of knowing that these are worth seeking > out (merely listing them in amongst 100 other books, articles and > papers isn't enough) and when you should read them (once you've > mastered Bird and Wadler (ahem, Richard Bird's "Introduction to > Functional Programming") or some similar book) or even of knowing > where they are listed (2/3 of the way down the Haskell Bookshelf page: > http://haskell.org/bookshelf/) [Bryn Keller] Very true. Thanks for the pointer, I hadn't realized that the proceedings of those conferences were actually available as books from Amazon and so on. I may have missed it, but I don't think there's anything on the Haskell Bookshelf page that suggests they are... I count four links related to Advanced Functional Programming, of which the first two are broken, and the second two take you to registration sites. There are three (the 1st, 2nd, and 3d annual, natch) different proceedings available from Amazon. At $52 - $66.95, which should I start with? Granted I expect to pay around $50 for computer books, but I'd like to have some sense of what I'm getting. Also, do these books have good coverage of things like existential types, functional dependencies, other experimental-but-apparently-crucial features that are hard to find documentation for? Are they edited into a coherent whole, so that the books is greater than the sum of its papers? > I also have a question: > > > Speaking as an 'industrial' programmer who gave a 30-minute application > > presentation at the International Python Conference earlier this year, > > I think you'll need to educate us as to what kind of conference this > is, what kind of paper it was, etc. In particular: [Bryn Keller] Fair enough. :-) > 1) Who is in the audience? > > Is it other python users or is it python library developers > or is it python compiler writers/porters? > And if all three, then who make up the bulk of the audience, > who were you primarily directing yoru talk at? [Bryn Keller] IPC is basically _the_ Python conference. Python is still a small enough developer community that basically all things Python are discussed there. There is some Python presence and some talks at Open Source and Linux conferences, but basically IPC is it. Since it is a general sort of conference, but Python I'd guess that users and library developers had about even representation (or possibly a majority of library developers), and the minority were compiler implementers. I believe attendance was in the neighborhood of 300. I'd say my intended audience was primarily application developers. > 2) What was the point of your paper? > > To suggest improvements in the language or libraries? > To suggest a need for development tools? > To suggest a neat coding trick? > To describe some useful tool or library that python users might > find useful when writing python? > To describe some useful application that people might find useful > for something other than writing python? > To show that python is useful for some new application domain? > To add to a body of concrete examples of people doing something > useful with python? > Other [the fact that I can't think of other points reflects my lack > of imagination and narrow focus not anything else] [Bryn Keller] The point of the paper was to demonstrate the use of Python for an ambitious and reasonably large-scale project. Essentially we developed a thin client business application, an GUI-builder IDE, and a new extremely portable UI toolkit with excellent internationalization support. The main client application and library runs about 35,000 lines of code, and the generated code for the screens (over 200 of them) easily exceeds 100,000 lines. The main points were to 1) demonstrate that Python is actually suitable for use in a project of this size so others can use it as a data point when speaking to their managers, 2) explain some of the pitfalls we encountered so that others might avoid them, and 3) discuss the architectural considerations that went into designing such a system from scratch. I also made a few suggestions for tools and language improvements, but they were not by any means the main focus. > 3) [this is partly covered by the above] > What did you want to achieve in writing the paper and what did > people at the conference or reading the proceedings hope to learn? > [Bryn Keller] I think this is mostly answered above as you suspected, but I should add that the papers that were presented (along with the lightning talks, and posters) covered quite a gamut. There were extensive discussions of, e.g., Stackless Python (a version of Python with first-class continuations), WAD (an extension module that traps C segfaults and whatnot and converts them to Python exceptions), the new compiler interface, and many, many more. The conference site is http://www.python9.org, if you're interested. I attended with a junior colleague who had been working with Python for about 6 months and he said he got a lot out of it. I also got a lot out of it, though we generally went to different sessions. > -- > Alastair Reid reid(a)cs.utah.edu http://www.cs.utah.edu/~reid/

3 2

Re: Application letters at the Haskell workshop: suggestion
by Ashley Yakeley 14 Sep '01

14 Sep '01

At 2001-09-13 16:00, Lennart Augustsson wrote: >I have been writing substantial Haskell programs and I use *NO* experimental >features. What I'm currently working on is over 20000 lines of Haskell 98. >No extensions whatsoever. (It even compiles and runs with all available >Haskell implementations.) >Granted, I write mostly compiler like programs (files in, files out), but >there >is still a lot you can do in Haskell just as it is. Sometimes it might >require >bending slightly backwards to get it done, though. Just as an alternative voice to this orgy of macho austerity... I'm currently working on two Haskell projects. _JVM-Bridge_ is a bridge from Haskell to the Java virtual machine. I use FFI (obviously), and in one place existential types. I admit I haven't really needed more for that project, but also I've tried to minimise extension use for the sake of possible porting etc. http://sourceforge.net/projects/jvm-bridge/ _Truth_, by contrast, is heavily dependent on class functional dependencies and probably even Hugs -98 wouldn't be able to deal with it. _Truth_ is a largely experimental project the nominal goal of which is to represent access to all information. 'Experimental' here means it's not likely to do anything useful anytime soon and frankly more resembles a work of art at this point. It's based on a solution I found to a problem I posed to this list ten months ago ("Imperative Object Destruction") that involves statically typing bits of imperative code based on what 'objects' they destroy, make use of, and create. http://sourceforge.net/projects/truth-framework/ Even with all the clever stuff I do with fundeps, the code would be simpler, cleaner and more general with certain extra extensions: most obviously if GHC were a bit smarter about whether or not instances overlap, but perhaps I could also make use of extensible algebraic datatypes. Empty datatypes would be nice for aesthetic reasons too, but of course there's a trivial workaround (providing a dummy constructor). >PS. OK, a small confession, that program contains one unsafePerformIO for >performance reasons. It works fine without it, but 5% slower. On the other hand, I don't do any unsafe anything anywhere. But I'm nowhere near performance tuning... -- Ashley Yakeley, Seattle WA

1 0

RE: The future of Haskell discussion
by brk＠jenkon.com 14 Sep '01

14 Sep '01

> In my opinion GTK+ is not that nice to develop Win32 applications because > it > provides its own look-and-feel which conflicts with the one of Windows. On > > UNIX-like systems where each desktop environment has its own look-and-feel > it > does not conflict under GNOME because GNOME is based on it. That's why I > think GTK+ should be used mainly to develop applications which are > intended > to run under GNOME and preferably not to do cross-plattform GUI > programming. > I think the best solution for the latter thing is to use a library which > has > multiple implementations based on different "native" libraries like Win32, > > GTK+, Qt. wxWindows (http://www.wxwindows.org/) is an example for this > kind > of library. > [Bryn Keller] Yes, exactly. Additionally, I have had trouble with bugginess in GTK on Win32 (not the Haskell bindings, but GTK itself), and things which want to compile with GTK usually insist on using an executable called gtk-info (IIRC) or something similar -- but on windows, only the DLLs are available (last time I checked). My personal vote would be for wxWindows - it's good stuff, and it's free even for commercial use. Qt's main advantage IMHO is in internationalization. The thing I'd most like to see, however, is not a standard C++ toolkit, but a standard Haskell GUI API which could then be implemented on top of other things (wxWindows, GTK, OpenGL, XUL, etc.). Frantk is implemented something like this I believe, and Fruit also has an interesting (if young) model. Bryn >

1 0

Re: The future of Haskell discussion
by C.Reinke 13 Sep '01

13 Sep '01

> There was the feeling that there is not frequent enough > feedback from the "Task Forces" (eg, FFI Task Force, Library > Task Force) to the Haskell community as a whole. Clause > Reinke kindly volunteered to collect status reports of Task > Forces on a 6-monthly basis and post them to the Haskell > mailing list. > > Claus, maybe you should give the Task Forces an idea of when > you expect the first status report. Just a quick update: when I was volunteered for organising more frequent feedback from the "task forces" to the Haskell community as a whole, I thought of just collecting individual summaries from the existing lists. However, my current opinion on the matter is that this alone would actually be a bad idea, as there are too many lists, no lists for some important topics, some topics spread over several lists, and generally not enough useful structure for the wide range of Haskell sub-communities. So what has been holding up the call for status reports from here (apart from the usual "real" work:-) is my attempt to (a) gather as many of the various Haskell interest groups as I can and (b) find some way to organise them, so that I get an idea of who is out there and how the pieces might fit together. I won't even try to get everything right in the first go, so I hope to send round a first draft of a structure (based on existing info at haskell.org and elsewhere) in the next days. The main point I'm still undecided on is at what level to ask for status reports. In my current version of the hierarchy, there are three levels, with 4-5 broad areas at the top (such as libraries, implementations, etc.), and many of the existing mailing lists or projects, such as Gtk+HS, at the most detailed level. If our community was more organised, I would really like to see reports at the middle (e.g., what's up in terms of GUIs?-) or top level, but as it stands, I will probably need to look for anything I can get at the mailing-list level and then try to edit all those fragments into a more useful overview. For the timescale, I still think that 6-monthly reports are a sensible compromise, and the Haskell workshops are a good reference point. I'll ask for the first status reports as soon as I've got an idea of how everything might fit together, probably early next week. The second round will then take place "in between" Haskell workshops, and so on. It would be nice if we could cover not only the explicit "task forces", but all Haskell (sub-)communities (such as the folks interested in generic programming, or in concurrent/parallel/distributed programming, functional reactive programming, etc.). That'll mean that the individual status reports themselves will have to be brief (plus pointers to more detailed documents, and instructions about how to join the communities or find archives), which should also make it easier to find people who write them;-). More later, Claus

1 0

Re: The future of Haskell discussion
by Marcin 'Qrczak' Kowalczyk 13 Sep '01

13 Sep '01

12 Sep 2001 12:37:25 -0000, kahl(a)heraklit.informatik.unibw-muenchen.de <kahl(a)heraklit.informatik.unibw-muenchen.de> pisze: > * Currently HOPS implements only one evaluation strategy, > namely leftmost outermost graph rewriting with sharing preservation > (without automatic sharing maximisation). > With the standard rules in place, this corresponds > to the original definition of lazy evaluation > (also known as the ``D-rule''), which is different > from the lazy pattern matching evaluation > of sequential Haskell implementations. What is the difference? -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

2 1

RE: Haskell98 undefinedness
by Simon Peyton-Jones 13 Sep '01

13 Sep '01

Personally I think this is ok, and it's compatible with the relaxed story about cumulative imports. I don't propose to change this unless there are yells. | So, it's not considered an error if you do something | like | | module A ( B(C), ...some other stuff..., B(D) ) where | ... | data B = C | D | | but C and D is exported. Is the extra flexibility of | allowing duplicates really worth it? Simon

1 0

RE: Application letters at the Haskell workshop: suggestion
by brk＠jenkon.com 13 Sep '01

13 Sep '01

This is an area of grave concern for me. I am still quite new to Haskell, so perhaps I should wait until others have spoken, but I'll go ahead anyway. I certainly don't mean to offend anyone, so please bear with me. Speaking as an 'industrial' programmer who gave a 30-minute application presentation at the International Python Conference earlier this year, I have to say that I wouldn't even think of submitting a paper to a Haskell workshop. Why? Because the feel of Haskell in general and Haskell conferences in particular is relentlessly academic, and I doubt I'd have anything to say that would be appreciated in such a context. *This does not mean* that I'm dismissing Haskell as "only" an academic exercise, quite the contrary. I think Haskell is a beautiful language in many ways, and a useful one. It is sometimes difficult for me to formulate problems in a purely functional way as opposed to a mixed style like Ocaml or Dylan, but in general once I've succeeded in doing so I find the program that I've written more elegant than the program I would have written in another language. I think I speak for the majority of 'industrial' programmers when I say Haskell is a very difficult language to approach. I believe a great deal of this difficulty stems from lack of documentation. It is common practice in the Haskell community to write some code, write a paper, and consider one's work done. While this is entirely reasonable for research projects, it is not reasonable to later wonder why more people aren't making use of that library. This applies not only to libraries, but also to experimental language features. If anyone needs examples, I've plenty to provide, but I'll not include them here because I don't want anyone to think I'm "blaming" them for this situation. This approach is entirely suitable for the majority of Haskell users today, who seem to me to be very bright people, mostly in academia, though there seem to be a few compiler writers and so on. However, it won't do if people want Haskell to have broader acceptance. Haskell concepts can be difficult for imperative programmers to grasp at first, but the larger issue is that people have to work *hard* to find the information they need. People without a deep and abiding interest in programming languages and their design (such as myself) will not go through the trouble to become familiar with lambda calculus, denotational semantics, and category theory just to learn a language they're not likely to get paid for anytime soon. But remember, the primary documentation of Haskell is currently research papers, which are largely composed of the aforementioned mathematics. The lack of *coherent* documentation describing everything you need to know to write a significant application in Haskell is breathtaking. I have a stack of Haskell papers more than six inches thick at my house, and I do have a good book, but collectively they're less useful to a beginner in the language than, say O'Reilly's _Learning Python_, especially when followed up with _Programming Python_. I'm actually thinking about keeping notes about my learning process so that I could eventually write such a book for Haskell. So I think Haskell is unlikely (in its current state) to attract many people who would develop applications that would be interesting to the people who go to Haskell workshops. I for one would like to see that situation change. I would suggest (if you couldn't guess :-)) that improving documentation and making the documentation more accessible to people with less mathematical background would be excellent places to start. After that's taken care of, (IMHO) a standard (and *maintained*) cross-platform GUI, standard (and *maintained*) database access facilities, and strong Unicode support would more than pay for themselves in terms of increased interest in the language. As an aside, very few contributed packages will build on windows machines (or rely on antiquated versions of Hugs or something), which also doesn't help acceptance. Please take these comments in the spirit they're offered, I'm only trying to help Haskell achieve the status I think it deserves. Bryn > -----Original Message----- > From: S.J.Thompson(a)ukc.ac.uk [SMTP:S.J.Thompson@ukc.ac.uk] > Sent: Wednesday, September 12, 2001 2:04 AM > To: haskell(a)haskell.org > Subject: Application letters at the Haskell workshop: suggestion > > > A thought to dicscuss for next year's Haskell > workshop. This is the second year running that > there have been no submissions accepted in the > `application letters' category for the Haskell > workshop. It seems that this comes from the > fact that these are not getting the same grades > as submissions focussed on more theoretical aspects > of Haskell and functional programming. That's a shame, > since it means that information of value to many users > of the language are not going into the public record. > > A suggestion: why not have a poster session at the next > workshop? This is used at many conferences for shorter > papers, work in progress, implementation aspects and the like. > The advantage of this over ten minute, ad hoc, talks is that > the posters (or poster abstracts) form part of the formal > proceedings and are thus available to the community for > reference. This is, of course, particularly valuable in the > case of applications, when it's useful to find out what one can > re-use, as well as seeing what might be problematic about > existing tools and libraries. > > How would a poster session work? People submit abstracts, > and then bring posters (plus laptops for demos etc. if they > wish) to the meeting. These are displayed over tea/coffee breaks, > or indeed a separate time could be devoted to them. > > I'd be interested to hear what others think; maybe there's a > better way of getting the application-oriented material into > the workshop? > > Simon Thompson > > > _______________________________________________ > Haskell mailing list > Haskell(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell

2 1

RE: Haskell98 undefinedness
by Simon Peyton-Jones 12 Sep '01

12 Sep '01

Yes, it's the same as exporting just B(..) or B(C). I guess I should try to make this clearer. S | -----Original Message----- | From: Sigbjorn Finne [mailto:sof@galconn.com] | Sent: 11 September 2001 20:31 | To: haskell(a)haskell.org | Subject: Haskell98 undefinedness | | | What's the meaning of | | module A (B, B(..)) where { data B = C }; | | Is or isn't C exported? i.e., the H98 report is silent | about what it means to have entity duplicates in | an export list, possibly with different 'visibility' | modifiers. | | --sigbjorn | | | | _______________________________________________ | Haskell mailing list | Haskell(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell |

3 2

Tab "\t" character behaviour in (Win)Hugs/ghc
by Rijk-Jan van Haaften 12 Sep '01

12 Sep '01

Hello, Recently, Craig Delehanty discovered that there is a difference in behaviour of putStr "a\tb" between Hugs and WinHugs (see comp.lang.functional). Hugs interprets it as a alignment character: >putStr "a\tb" "a b" > (7 spaces) but in WinHugs, it is always the same as 8 spaces: >putStr "a\tb" "a b" > (8 spaces) What does the language definition say about this? What is the behaviour of ghc/ghci? Rijk-Jan

1 0

Application letters at the Haskell workshop: suggestion
by S.J.Thompson＠ukc.ac.uk 12 Sep '01

12 Sep '01

A thought to dicscuss for next year's Haskell workshop. This is the second year running that there have been no submissions accepted in the `application letters' category for the Haskell workshop. It seems that this comes from the fact that these are not getting the same grades as submissions focussed on more theoretical aspects of Haskell and functional programming. That's a shame, since it means that information of value to many users of the language are not going into the public record. A suggestion: why not have a poster session at the next workshop? This is used at many conferences for shorter papers, work in progress, implementation aspects and the like. The advantage of this over ten minute, ad hoc, talks is that the posters (or poster abstracts) form part of the formal proceedings and are thus available to the community for reference. This is, of course, particularly valuable in the case of applications, when it's useful to find out what one can re-use, as well as seeing what might be problematic about existing tools and libraries. How would a poster session work? People submit abstracts, and then bring posters (plus laptops for demos etc. if they wish) to the meeting. These are displayed over tea/coffee breaks, or indeed a separate time could be devoted to them. I'd be interested to hear what others think; maybe there's a better way of getting the application-oriented material into the workshop? Simon Thompson

4 3