- Haskell - Haskell.org

Existential types: HM versus System F
by edrx＠inx.com.br 14 Sep '01

14 Sep '01

Could someone recommend me a paper that discusses the relation between Girard's System F and Hindley-Milner type systems? I've been studying system F lately (and Haskell's semantics is still somewhat mysterious to me), and in System F existential types can be built from the basic operations, while in Haskell it seems that one needs language extensions to be able to use them... Thanks & cheers, Eduardo Ochs http://angg.twu.net/ edrx(a)inx.com.br

1 0

RE: closing file handles
by Simon Marlow 14 Sep '01

14 Sep '01

> Tom Pledger wrote: > > [...] > > go' f > > = do h <- openFile f ReadMode > > text <- hGetContents h > > case text of > > (c:_) -> do hClose h > > return c > > > > This way, the pattern match on `text' happens before the innermost > > `do', which in turn closes the handle before letting the rest of the > > computation continue. > > I think the above code will lead to problems if file input is > done when c is evaluated and not earlier. Fortunately, in GHC this isn't the case. Evaluating the (:) is enough to force the character to be read. But to be on the safe side you could also write it like this: go' f = do h <- openFile f ReadMode text <- hGetContents h let c = head text c `seq` do { hClose h; return c } Cheers, Simon

4 3

JPBernède/Haskell/Question about Sgbd Connexion
by Jean-Pierre Bernède 14 Sep '01

14 Sep '01

Hello, I would like to know how can-I mapping Haskell program with a database (for example Oracle). and How can-I encapsulate the request in a O'Haskell Object ? Thanks for your response. Kind regards Jean-Pierre Bernède (Paris - France).

1 0

RE: The future of Haskell discussion
by Julian Seward (Intl Vendor) 14 Sep '01

14 Sep '01

| wxWindows is quite C++ centric and AFAIK nobody has made a | serious effort at a C++ FFI yet. One of the big advantages | of GTK+ is that it was written with bindings for other | languages in mind. Therefore, it is probably the toolkit | with the most language bindings. The lack of any way to interface to C++ is a problem, IMO. I would love to be able to write Haskell programs using Qt and ultimately the KDE libraries, both of which are C++, but I can't, at the mo. J

1 0

Re: Application letters at the Haskell workshop: suggestion
by Marcin 'Qrczak' Kowalczyk 14 Sep '01

14 Sep '01

Fri, 14 Sep 2001 01:00:06 +0200, Lennart Augustsson <lennart(a)augustsson.net> pisze: > I have been writing substantial Haskell programs and I use *NO* > experimental features. In a 2000-line interpreter I used: - FiniteMap (for environments), - Dynamic & Exception (for exceptions in the language being implemented and compile errors), - MonadReader, MonadError (for convenience, in two places), - MVar (could be IORef; for mutable objects in the language being interpreted), - unsafePerformIO (for three global variables: unique supply, loaded modules, search paths), - Readline (for the interactive toplevel). -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

2 1

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 13 Sep '01

13 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