- Haskell-Cafe - Haskell.org

Re: haskell parser for java bytecode?
by Frank-Andre Riess 02 Jul '05

02 Jul '05

Hi there, keeping out of the previous tiff, I'd just like to mention that I, too, am interested in such a project - I don't require a parser for Java bytecode, but I think I'd be a good experience and at least it would get me to know the JVM a bit better... maybe :) By the way, there once was some discussion about having Haskell actually -target- the JVM (I think, it was on the Glasgow Haskell Users list). That might as well be an interesting thing to do. Best regards, Frank-Andre Riess

1 0

Conversion between MonadPlus instances
by Gracjan Polak 02 Jul '05

02 Jul '05

Hi all, A simple question for advanced Haskellers, but I still have some problems bending my mind over it. Example: I have some function, that can return multiple results. Currently I need only the first one, but in the spirit of NotJustMaybe, I try to be as general as possible. If I code it like this: reduction :: (MonadPlus m) => [Rule] -> Expr -> m Expr reduction expr = do rule <- rules reduction rule expr Variable m gets unified with []. But I want m to stay as general as possible here. This version works, but I somehow do not like the "smell" of it reduction expr = do let listmonad = do rule <- rules reduction rule expr msum (map return listmonad) Is there a better way how to "embed" MonadPlus in other "MonadPlus"? -- Gracjan

2 1

RE: ANNOUNCE: GHC survey results
by Simon Marlow 01 Jul '05

01 Jul '05

On 28 June 2005 14:11, Bulat Ziganshin wrote: > Tuesday, June 28, 2005, 1:58:13 PM, you wrote: > >> http://www.haskell.org/ghc/survey2005-summary.html >> 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)? Do you really mean "several times faster"? My impression is that it's a few percent faster, if at all. Some measurements would be good. We've thought about compiling to persistent byte code in the past, but the gains never seemed to be worth the effort: we'd need a byte-code serialiser and loader. > 2) is your plans to support x86-64 platform includes Windows (and all > other sorts of Unix), or it's for Linux only? Definitely Windows too. I hear the cygwin/mingw tools are still unstable on Windows x64, though. > 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) I've read that article, and I think it's an interesting idea. I can't disagree with the arguments put forward, but somehow, the cure seems a bit painful. Cheers, Simon

4 3

Re: [Haskell] best way to do generic programming?
by Thomas Jäger 01 Jul '05

01 Jul '05

Arka, as you already mentioned, you want to have a look at the "Scrap your Boilerplate" approach. > import Data.Generics > ... > data Expr = Const Int | Var String | Add Expr Expr deriving (Typeable, Data) will derive the necessary Data instance and allow you to define > optimizeDeep :: Data a => a -> a > optimizeDeep = everywhere (mkT optimize) On 7/1/05, Arka al Eel <arkaaleel(a)gmail.com> wrote: > Hi, > > I'm playing with generic programming. At the moment I'm interested in > reusable transformations on data types. Provided for example a toy > datatype Expr like this: > > data Expr = Const Int | Var String | Add Expr Expr > > Plus a function "optimize" that optimizes a pattern "x + 0" into "x": > > optimize (Add x (Const 0)) = x > > You would now want this to be this generic, so the function should be > recursive for all other constructors *and* other data types. For > example, suppose that Expr is included in other datatype: > > data Stm = Assign String Expr | Seq Stm Stm > > I now want the "optimize" transformation to work on Stm, like > this: > > x = optimize (Seq (Assign (Add (Var "x") (Const 0))) blah blah) > with a sensible solution in an hour, while I can do this in two > minutes in Scheme. After all, writing compilers is supposed to be a > *strong* point of Haskell. Real world is knocking on your door, guys! Thomas

1 0

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 01 Jul '05

01 Jul '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