- Haskell-Cafe - Haskell.org

RE: [Haskell-cafe] Re: [Haskell] Dynamic binding
by Ralf Lammel 01 Jul '05

01 Jul '05

> > But note that "same functionality" is one thing, > > having "separate compilation" and "program extensibility" too > > is another one. > > As I said, and as is well-known, "extensibility" is a red herring in > this context - you merely trade one dimension of extensibility for > another one. I am not going to fight for extensibility. It's just that I believe that there is a value in a direct correspondence as opposed to a transcription. I cite from the OOHaskell abstract: "The [...] code [...] demonstrates that OO code translates into OOHaskell in an intuition-preserving way: essentially expression-by-expression, without requiring global transformations." I would like to add a peer-reviewed clear reference to the OOHaskell paper about the red herring that you mention. I don't have such a reference. May I kindly ask you to offer a few for selection? Thanks, Ralf

4 4

Re: haskell parser for java bytecode?
by Kimberley Burchett 30 Jun '05

30 Jun '05

Jerzy Karczmarczuk asked: > > Why for goodness' sake, people interested in Haskell *should* worry > about parsing of Java bytecode chunks? Are you asking why I'm interested in bytecode instead of source code, or are you asking why I'm interested in Java at all? One answer to the first question is: because java bytecode is a simpler problem domain than java source. For example, name resolution is trivial when working with bytecode (there's no ambiguity between package/class/variable names, inherited names are already resolved, overloaded functions are already resolved, etc). Also, many of the newer features of java disappear at the bytecode level: inner classes, generics, the new foreach statement, etc. Another answer to the first question is: because java bytecode can be used as a target for several languages these days, and by working with it directly, I can work with any language that compiles to the jvm, rather than restricting myself just to java. The answer to the second question is: because the rest of the world matters to some people. Kimberley Burchett http://www.kimbly.com/

4 4

Unicode.hs (was: RE: Re[2]: ANNOUNCE: GHC survey results)
by Dimitry Golubovsky 30 Jun '05

30 Jun '05

Hi, Vadim Konovalov wrote: === that file reads: -- Based on the GHC.Unicode library, Copyright 2005, Dimitry Golubovsky. -- See GHC's LICENSE file for the full license text. That said, it is part of GHC? === Clarifying on Unicode stuff in GHC I contributed: It is in CVS now, and I believe will be in 6.4.1 At least it shows up at: http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/libraries/base/GHC/Unicod… (MAIN branch) But this module is just an interface to another module, WCsubst.c: http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/libraries/base/cbits/WCsu… which in turn was produced from UnicodeData.txt (? I believe this is correct name of the file from www.unicode.org) by the shell script: http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/libraries/base/cbits/ubco… This API handles simple case conversions (Char -> Char), and categorization of characters according to what is in the UnicodeData.txt file. Before (i. e. up to and including 6.4), Unicode stuff was handled through wc* locale based functions for wide chars conversion. Since not every installation of Unix (or some other OS) has this set up properly (mine was not: personal itch), this code was proposed for GHC and finally made it there. Hope this explains everything. In fact, Unicode.hs itself is not completely mine ;) PS: Autrijus (the guy who develops Pugs) included those files on his own because 6.4 was just out, and Unicode stuff was not there yet. -- Dimitry Golubovsky Anywhere on the Web

1 0

RE: Re[2]: ANNOUNCE: GHC survey results
by Konovalov, Vadim 30 Jun '05

30 Jun '05

> btw, in Pugs sources > (http://search.cpan.org/CPAN/authors/id/A/AU/AUTRIJUS/Perl6-Pugs-6.2.7.tar.g z) > there is Unicode.hs module wich can classify and convert full range of > Unicode symbols under any OS. i don't understand - is this module > already included in GHC 6.5? if not, it would be good addition that file reads: -- Based on the GHC.Unicode library, Copyright 2005, Dimitry Golubovsky. -- See GHC's LICENSE file for the full license text. That said, it is part of GHC?

1 0

Re: [Haskell] ANNOUNCE: GHC survey results
by Bernard Pope 30 Jun '05

30 Jun '05

[moved to haskell-cafe] On Tue, 2005-06-28 at 14:46 -0700, John Meacham wrote: > Unfortunatly hat suffers from the same problem that pretty much every > non-trivial preprocessor does, as soon as you start using ghc's special > or experimental features that have not been added to hat yet, they stop > working. I agree this is a problem. [snip] > I am not sure what the general solution would be. perhaps > hat being integrated with ghc? I think it is preferable to keep them separate. Already a big effort was put into making hat independent of nhc98. There will always be more tools that Haskell could use, which must transform the source code one way or another. I'd rather not see them all be pushed inside ghc, or whatever other compiler was popular at the time. It's probably better for ghc's maintainability to keep these tools out of its source tree (pure speculation on my part though). > or better yet would be a standard > interface for ghc to call a preprocessor but at some intermediate level > where most of the extensions have been sugared away but most of the > original source structure still exists... the nice thing about a > standard interface would be that jhc and other compilers could support > it too. It wouldn't even need to be a plugin based thing, but rather an > executable that ghc can run and pass commands to it on stdin and read > results on stdout. Sounds nicer. Perhaps GHC-as-a-library might be close to what is needed. There is a danger that we won't be able to settle upon what is the right core language to use, and some tools will be left out, thus reverting to the solution employed by hat at the moment. > Being able to just work on any unmodified program the > compiler supports is a huge feature. Yes. The problem is that Haskell is being torn in two directions. One direction is a research vehicle. The other direction is a work-horse. GHC sits somewhere in the middle, and does an amazing job too. The trouble is that it has become a fast moving target. Overall I think Hat's solution is a reasonable compromise between the competing needs of the tool. If anything I would like to see the Haskell community produce a Haskell front end which was compiler neutral. That would facilitate many interesting projects, and that might even help with the need to support new extensions as they come along. There are already some candidates floating around, but it seems they are not widely adopted. Cheers, Bernie.

1 0

Commerical Users of Functional Programming Workshop 2005
by Andy Moran 29 Jun '05

29 Jun '05

[ Apologies for multiple postings; please forward to potentially interested parties ] CUFP 2005 THE SECOND COMMERCIAL USERS OF FUNCTIONAL PROGRAMMING WORKSHOP Talinn, Estonia September 24th 2005 Co-located with ICFP Functional languages have been under academic development for over 25 years, and are still proving to be very fertile ground for programming language research. Consequently, most of the development focus of these languages is driven by academic and theoretical questions. More recently, however, functional languages have been very successfully used in commercial, industrial, and government settings, where their advantages have been able to be leveraged dramatically. The goal of CUFP is to act as a voice for commercial users of functional programming languages and technology. It aims to help functional programming become increasingly viable as a technology for use in the commercial, industrial, and government space, by providing a forum for FP professionals to share their experiences and ideas, whether business, management or engineering. It also aims to enable the formation and cementing of relationships and alliances that further the commercial use of functional languages. Providing user feedback to language designers and implementors is not a primary goal of the workshop, though it will be welcome if it occurs. Program plans ------------- The meeting will last a full day, with a mix of invited and submitted presentations, plus discussion sessions. Topics will range over a wide area, including: * Case studies both of successful and unsuccessful uses of functional programming; * Business opportunities and risks from using functional languages; * Enablers for functional language use in a commercial setting; * Barriers to the adoption of functional languages, and * Mitigation strategies for overcoming limitations of FP. There will be no published proceedings, as the meeting is intended to be more a discussion forum than a technical interchange. A full report of last year's workshop will appear in the Functional Programming column of SIGPLAN Notices. See http://www.galois.com/cufp/ for more information, including last year's schedule and a report describing last year's workshop. This year's schedule will also be available there soon. Submissions ----------- Submissions by prospective speakers or suggestions for speakers are welcome! Just send an e-mail to cufp at galois.com with an outline of what you'd like to talk about or what you think your suggestee should give a talk about. Program Committee ----------------- Mike Ashley: Mike.Ashley at sagian.com Jim Grundy: Jim_Grundy at ichips.intel.com Xavier Leroy: Xavier.Leroy at inria.fr Simon Peyton Jones: simonpj at microsoft.com Ulf Wiger: ulf.wiger at ericsson.com Andy Moran: moran at galois.com John Launchbury: john at galois.com (Chair) -- Andy Moran Phone: 503.626.6616, x113 Galois Connections Inc. Fax: 503.350.0833 12725 SW Millikan Way, Suite #290 http://www.galois.com Beaverton, OR 97005 moran(a)galois.com

1 0

Compiling an extremely large Haskell file (in GHC)
by Arjun Guha 29 Jun '05

29 Jun '05

I have an extremely large source file of about 11 MB. It's the all-pairs shortest paths data for a map of the Hyde Park area of Chicago (no real reason, really). I generated information in Scheme and printed the result to a Haskell source file as a list. I then edited the file to initialized an array with the data. GHC, with a 200MB stack, took up 1 hour and 1.3 GB of memory before getting killed by the system. How would I compile something of this size? I need to have the array of all-pairs shortest paths pre-computed. Any suggestions? Thanks. -Arjun

6 7

Announce: Yet Another Tool to Generate FFI Bindings: hsffig
by Dimitry Golubovsky 29 Jun '05

29 Jun '05

I am pleased to announce the very first alpha release of the (yet another) FFI binding autogeneration tool. Some time ago, I asked the list subscribers about available bindings to Berkeley DB. Several people kindly shared their code with me. One thing I noticed in all bindings: they required manually-written wrappers to accomodate for Berkeley DB indirect style of calling functions. Considering large number of such functions in BDB, I attempted to write a tool which would automatically parse the BDB include file, and extract function prototypes to generate FFI declarations. Soon it became clear that an almost full C syntax parser would be necessary. Finally it resulted in what I am presenting to the Haskell community with hope that this utility will be useful to many developers. Of course there are many omissions and shortcuts, but before I move forward, I would like to get some feedback from potential users of this tool. There is no detailed documentation. I have written a brief README file. More detailed documentation will follow. I haven't created a homepage for this project yet: the only way to get it so far is the darcs repo: darcs get http://www.golubovsky.org/repos/hsffig Files in the repository may be browsed at: http://www.golubovsky.org/repos/hsffig/ I will appreciate any feedback. Dimitry Golubovsky Middletown, CT

2 1

Re: ANNOUNCE: GHC survey results
by Bulat Ziganshin 28 Jun '05

28 Jun '05

Hello Simon, Tuesday, June 28, 2005, 1:58:13 PM, you wrote: SM> http://www.haskell.org/ghc/survey2005-summary.html SM> There's a lot to take in, but it's an interesting read. Enjoy! thank you all, processing all the 600 answers was not easy work :) i have several comments regarding results of this survey: 1) GHCi compiles to bytecode several times faster than GHC makes unoptimized compilation. can unoptimized GHC compilation just create bytecode (as Ocaml does)? 2) is your plans to support x86-64 platform includes Windows (and all other sorts of Unix), or it's for Linux only? 3) many users complaining about non-compatibility between GHC versions. if they mean library interfaces changes then how about using Pesco's library versioning scheme? (see http://www.haskell.org/tmrwiki/EternalCompatibilityInTheory) 4) i definitely will poll for nightly snapshot build for Windows (if it's possible) and frequent releases of stable versions i think there is a plans to move toward the "real world". but it encounter the chicken&egg problem - the commercial programmers don't want to use Haskell because it's too far-from-earth, and you cannot make movements toward "real world" because there is almost no voices from non-academic world. of course i can't monopolize the right to say over all these programmers. but from my point of view several things can be done to be closer to commercial programs and programmers: 1) adding OO-like features in O'Haskell style. for readers that don't know it's about adding new variants to ADT types: type Figure = Circle ... type Figure |= Box ... and adding new fields to existing records: type Point = {x,y::Int} type ColoredPoint = Point extended with {c::Color} imho these extensions are great because it's both in Haskell and C++ style 2) adding "real-world" libraries. i think about libraries for string processing, regular expression handling, command-line processing, serializing, ASCIIZ strings, working with filesystem and running external commands, networking, web-oriented libraries (http/ftp/smtp/pop3, constructing/deconstructing emails), DBMS access i enumerated here only working libraries which i seen in MissingH, or written by Pesco, John Meacham, or Peter Simons 3) may be it is time to include some FFI-generating tool in GHC? many newcomers have some C/C++ libraries they need to communicate 4) some newcomers wrote what they want to say example programs and even tutorials in the package. i think that at least links to such sources/texts can be provided so that a newcomer can easily get a TASTE of Haskell 5) of course, you must add words about Pugo and Darcs in readme :) anyway, ADT is a vehicle of progress ;) -- Best regards, Bulat mailto:bulatz@HotPOP.com

4 6

Noob error: Type b -> c b Does not match IO a
by kynn＠panix.com 28 Jun '05

28 Jun '05

--text follows this line-- I'm trying to learn Haskell from YAHT. My attempt at a solution of Exercise 3.10 is failing with a "Type does not match" error. The exercise is to write a function that will read numbers (one per line) from the command line, until the number 0 is entered. At this point the program is supposed to print out the sum of the numbers, their product, and for each number, the factorial. The interaction should resemble this: Give me a number (or 0 to stop): 5 Give me a number (or 0 to stop): 8 Give me a number (or 0 to stop): 2 Give me a number (or 0 to stop): 0 The sum is 15 The product is 80 5 factorial is 120 8 factorial is 40320 2 factorial is 2 The code I have for this is given next (the line that fails is indicated by a comment): module Main where import IO main = do hSetBuffering stdin LineBuffering numberList <- getList let s = sumList numberList let p = prodList numberList putStrLn ("The sum is " ++ s) putStrLn ("The product is " ++ p) printFact numberList fact 0 = 1 fact 1 = 1 fact x = x * fact x - 1 sumList [] = 0 sumList (x:xs) = x + sumList xs prodList [] = 1 prodList (0:xs) = 0 prodList (x:xs) = x * prodList xs printFact [] = return printFact (x:xs) = do -- triggers error message putStrLn (x ++ " factorial is " ++ fact x) printFact xs return getList = do putStrLn "Give me a number (or 0 to stop):" numString <- getLine let num = read numString if num == 0 then return [] else return (num:getList) Here's the full error I get (from HUGS): IO> :l Ex3_10 ERROR "./Ex3_10.hs":28 - Type error in generator *** Term : printFact xs *** Type : b -> c b *** Does not match : IO a If anyone can explain to me how to fix this error I'd appreciate it. Also, what is the difference between <- and let? Lastly, any comments on any other detail of the code, particularly coding, style are most welcome. Thanks! kj

5 5