- Haskell - Haskell.org

haskell cocoa integration
by Markus Schnell 14 Mar '03

14 Mar '03

I put some points together of how one can integrate Haskell with a Mac OS X Cocoa application: http://www.markusschnell.com/cocoa_howto.html Perhaps some Mac-Users can comment on it. Thanks, Markus -- Markus Schnell ______________________________________________________________________________ 160 Zeichen sind für Ihre SMS zu wenig? Bei WEB.DE FreeMail koennen Sie bis 760 Zeichen versenden! http://freemail.web.de/features/?mc=021183

1 0

GPCE 03 CFC
by Akos Ledeczi 14 Mar '03

14 Mar '03

Dear Colleague, just a quick reminder that the deadline for papers and workshop proposals is fast approaching... I apologize if you receive multiple copies of this. Best Regards, Akos Ledeczi Publicity Chair GPCE 2003: Call for Contributions 2nd International Conference on Generative Programming and Component Engineering September 22-25, 2003 Erfurt, Germany Part of NetObjectDays'03 http://gpce.org In Cooperation with ACM SIGPLAN and SIGSOFT Generative and component approaches have the potential to revolutionize software development in a similar way as automation and components revolutionized manufacturing. Generative Programming (developing programs that synthesize other programs), Component Engineering (raising the level of modularization and analysis in application design), and Domain-Specific Languages (elevating program specifications to compact domain-specific notations that are easier to write and maintain) are key technologies for automating program development. GPCE arose as a joint conference, merging the prior conference on Generative and Component-Based Software Engineering (GCSE) and the Workshop on Semantics, Applications, and Implementation of Program Generation (SAIG). The goal of GPCE is to provide a meeting place for researchers and practitioners interested in cutting edge approaches to software development. Thanks to the co-location with NetObjectDays, one of the largest main-stream software development conferences in Germany, the GPCE'03 presentations are expected to have a high attendance by industry practitioners, in addition to regular conference attendees. Important Dates: --------------- Technical paper submission: Apr 6, 2003 Workshop proposal submission: Apr 6, 2003 Practitioner report submission: May 18, 2003 Tutorials proposal submission: May 18, 2003 Demonstration proposal submission: May 18, 2003 Poster proposal submission: Jul 13, 2003 Notification of acceptance for Technical papers: May 25, 2003 Workshop proposals: Apr 20, 2003 Practitioner reports: Jun 1, 2003 Tutorials proposals: Jun 1, 2003 Demonstration proposals: Jun 1, 2003 Poster proposals: Jul 27, 2003 Camera ready copy: Jun 22, 2003 Detailed submission instructions are available at: http://gpce.org Technical Papers ---------------- The GPCE'03 conference invites high quality papers reporting research results and/or experience related to generative programming and component engineering. We seek papers both in software engineering and in programming languages, and especially those that bridge the gap and are accessible to both communities at the same time. The conference solicits submissions related (but not limited) to: * Generative Programming: Reuse, meta-programming, partial evaluation, multi-stage and multi-level languages, * Semantics, type systems, symbolic computation, linking and explicit substitution, in-lining and macros, templates, program transformation * Runtime code generation, compilation, active libraries, synthesis from specifications, development methods, generation of non-code artefacts, formal methods, reflection. * Product Lines and architectures * Industrial Applications * Component-Based Software Engineering: Reuse, distributed platforms, distributed systems, evolution, analysis and design patterns, development methods, formal methods * Integration of Generative and Component-Based Approaches * Domain Engineering, analysis, and languages, domain-specific notations * Separation of Concerns: Aspect-Oriented Programming, Intentional Programming, and Multi-Dimensional Separation of Concerns * Model-driven architecture Reports on applications of these techniques to real-world problems are especially encouraged, as are submissions that relate ideas and concepts from several of these topics, or bridge the gap between theory and practice. Research papers should describe work that advances the current state of the art. The program committee will evaluate each contributed paper based on its relevance, significance, clarity and originality. The program committee is happy to advise on the appropriateness of a particular subject. Authors are invited to submit papers of at most 20 pages in LNCS proceedings format, in PDF form, by April 6, 2003. This deadline is firm. Simultaneous submission to other venues and submission of previously published material are not allowed. Electronic submission will be required, except by special arrangement with the program chairs. Selected papers from the conference will be invited for submission to a fast-track review process in either ACM TOPLAS or ACM TOSEM as appropriate. Practitioner Reports -------------------- GPCE '03 will feature a track geared towards industry and practice, where practitioners will present their experience and insight in applying generative and component-based technologies. We solicit reports in two categories: * Project reports describing successfully completed projects that applied technologies within the scope of GPCE'03. * Experience reports focussing on a particular aspect of technology usage and practice, or describe broad project experiences. The report submissions will be reviewed separately from technical paper submissions by a practitioner report committee. Workshops --------- GPCE workshops provide intensive collaborative environment to explore a specific sub-area of generative and component technology in depth, cover areas that cross the borders of several sub-areas, or focus on the applications and deployment of generative and/or component technology in a particular application domain. Workshops will take place on the first day of the conference. Young Researchers Workshop -------------------------- As in the past year, the conference will feature a one day doctoral symposium, where a panel of experts will review and discuss submissions from graduate students and other young researchers. For more details about submissions, please contact the YRW Chairs Isabel John (john(a)iese.fhg.de) and Matthias Clauss (Matthias.Clauss(a)gmx.de) Tutorials --------- We invite proposals for high-quality tutorials in all areas of generative programming and component-based development. Tutorial levels may be introductory, intermediate, or advanced. Introductory tutorials should seek to educate the participants about the basic concepts and techniques of generative and component-based development. More advanced tutorials may cover advanced development techniques and/or underlying theory. Demonstrations -------------- We invite proposals for demonstrating novel tools, systems, or techniques from both commercial and academic communities. Demonstrations should focus on technical aspects. Demonstrations showing how a specific technology is used in real world scenarios are particularly welcome. Both work in progress or proven techniques are appropriate. Product marketing is inappropriate in this forum. Posters ------- Posters at GPCE provide an excellent forum for authors to present their work in an informal and interactive setting. Posters are ideal for presenting speculative, late-breaking results or for giving an introduction to interesting, innovative work. Exhibits -------- The GPCE '03 exhibits will be held together with the exhibits of NetObjectDays'03, one of the largest main-stream software development conferences in Germany. Therefore, this will be an excellent forum to reach potential customers with news and demonstrations of your latest products, publications or services. If you would like your company to participate as an exhibitor at the conference, please refer to the web site for submission instructions. GPCE'03 Best Contribution Awards -------------------------------- The GPCE'03 audience will elect the best contributions in the following categories: * Best Paper * Best Practitioner Report * Best Commercial Tool * Best Non-Commercial Tool * Best Industrial Project Organizing Committee -------------------- General Chair: (chair03(a)gpce.org) Krzysztof Czarnecki, DaimlerChrysler Research and Technology, Germany. Program Committee Chairs: (pc03(a)gpce.org) Frank Pfenning, Carnegie Mellon University, USA Yannis Smaragdakis, Georgia Institute of Technology, USA Workshop Chair: (workshops03(a)gpce.org) Kasper Osterbye, IT University of Copenhagen, Denmark Tutorial Chair: (tutorials03(a)gpce.org) Gerd Frick, FZI, Karlsruhe, Germany Demonstration Chair: (demos03(a)gpce.org) Markus Voelter, independent consultant, Germany Poster Chair: (posters03(a)gpce.org) Jorn Bettin, SoftMetaWare, New Zealand Industrial Chair: (industrial03(a)gpce.org) Ulrich W. Eisenecker, University of Applied Sciences Kaiserslautern, Germany Publicity Chair: (publicity03(a)gpce.org) Akos Ledeczi, Vanderbilt University, USA Young Researchers Workshop Chairs Isabel John, Fraunhofer IESE, Germany (john(a)iese.fhg.de ) Matthias Clauss, Solutionline CSS, Germany (Matthias.Clauss(a)gmx.de) Program Committee Members (near-final): ------------------------- Giuseppe Attardi, University of Pisa, Italy Don Batory, University of Texas, USA Ira Baxter, Semantic Designs, USA Ted Biggerstaff, softwaregenerators.com, USA Shigeru Chiba, Tokyo Institute of Technology, Japan Rowan Davies, University of Western Australia, Australia Premkumar Devanbu, University of California, Davis, USA Ulrich W. Eisenecker, University of Applied Sciences Kaiserslautern, Germany Robert Glueck, Waseda University, Japan Trevor Jim, AT&T Labs Research, USA Gregor Kiczales, University of British Columbia, Canada Kai Koskimies, Tampere University of Technology, Finland Julia Lawall, DIKU, University of Copenhagen, Denmark Eugenio Moggi, DISI, University of Genova, Italy Jim Neighbors, Bayfront Technologies, USA Calton Pu, Georgia Tech, USA Olin Shivers, Georgia Tech, USA Clemens Szyperski, Microsoft Research, USA Peter Thiemann, University of Freiburg, Germany Eelco Visser, Utrecht University, The Netherlands

1 0

clueless GHCI user wishes to load QuickCheck
by nr＠eecs.harvard.edu 13 Mar '03

13 Mar '03

Can anyone help me figure out how to load QuickCheck into GHCI? QuickCheck is included in my Debian package, but my attempts at loading it are bootless: Prelude> :load QuickCheck can't find module `QuickCheck' Prelude> :load util/QuickCheck can't find module `util/QuickCheck' Prelude> :info syntax: `:i <thing-you-want-info-about>' Prelude> :load util/QuickCheck.hi can't find module `util/QuickCheck.hi' Prelude> :load /usr/lib/ghc-5.02.2/imports/util/QuickCheck.hi can't find module `/usr/lib/ghc-5.02.2/imports/util/QuickCheck.hi' Prelude> :load /usr/lib/ghc-5.02.2/imports/util/QuickCheck can't find module `/usr/lib/ghc-5.02.2/imports/util/QuickCheck' Prelude> Any advice, anyone? Norman

6 8

ANNOUNCE: buddha 0.5
by Bernard James POPE 13 Mar '03

13 Mar '03

Announcing the release of buddha 0.5 ------------------------------------ buddha is a declarative debugger for Haskell 98 http://www.cs.mu.oz.au/~bjpop/buddha/ What's new in this release: - a browsing facility - (optional) re-evaluation to improve space usage - better support for exceptions - accurate line numbers - minor interface improvements - many more interesting examples - and of course a swag of bug fixes Requirements: - ghc 5.04 or greater with libraries built for profiling (not tested with 5.04.3 yet) - a unix-ish environment (not tested on windows) Cheers, Bernie

1 0

Learning Haskell, update
by Arjan van IJzendoorn 13 Mar '03

13 Mar '03

Hi all, I've removed the frequently asked questions box at the bottom. It was unused. Fritz Ruehr made a nice Learning Haskell logo. Thank you, Fritz! NHC is compilable under Windows now, so the remark "no windows version" has been removed. Is there someone who wants to make a more decent language comparison table? If not, I'm thinking of removing it. Many things are said about it already in the comp.lang.functional FAQ. Greetings, Arjan

1 0

ANNOUNCE: hugs98.NET March 2003 snapshot
by Sigbjorn Finne 13 Mar '03

13 Mar '03

A new version of Hugs98.NET is now available, sporting the following: * A version of the popular Haskell interpreter, Hugs98 (http://haskell.org/hugs) targetted at the Microsoft .NET platform. * .NET interop integrated via the Haskell FFI. * Support for wrapping up Haskell functions as .NET classes / delegators, providing any .NET language with the ability to call and use Haskell. The distribution comes with documentation and examples demonstrating how to access and interact with .NET -- all available via the Hugs98.NET homepage: http://galois.com/~sof/hugs98.net/ Feedback, contributions, suggestions for improvements, bug reports etc. are most welcome -- please e-mail these to the author: sof(a)galois.com ----------------------------------------------------------------------- The Hugs 98 system is Copyright (c) Mark P Jones, Alastair Reid, the Yale Haskell Group, and the Oregon Graduate Institute of Science and Technology, 1994-2001, All rights reserved. It is distributed as free software under the license in the file "License", which is included in the distribution. The .NET extension is Copyright (c) Sigbjorn Finne, 2002-2003, All rights reserved. It is distributed as free software under the license in the file "License.net", which is included in the distribution. -----------------------------------------------------------------------

1 0

recursive modules in Haskell
by Elke Kasimir 12 Mar '03

12 Mar '03

Hi all! I've just got one of the rare chances to do a somewhat bigger piece of software development in Haskell. After having set up a design (with much use of multi-parameter-classes) I was very excited. However, to extent that implementation proceeded I had to recognize many unforeseen implementation dependencies between instance. A standard situation is: file A.hs: instance Foo A f :: -- implementation requires A and B to be an instance of Foo file B.hs: instance Foo B f :: -- implementation requires A and B to be an instance of Foo The mutual dependencies increase if one uses class constraints to enforce semantic wellformedness, that is if one writes given Bar A => class Foo A whenever this makes sense from the view of the application logic - as I did. No Problem at all for Haskell, but a problem for certain often-used Haskell compilers and interpreters... Factoring out "the common part" does not work in examples like above, so the only way is to collapse everything, and to reduce class constraints as much as is possible - something which hurts deep inside! That the problems appear step-by-step in the course of implementation or even debugging, adds to the pain. So I have put onto my personal Haskell whish-list that certain compilers and interpreters shall either ultimately converged against the language they intend to support, or else provide some suitable alternative. Thinking in the first direction, a precompiler appears before my inner eye which is able to collapse mutually dependent modules into one bigger module. Even if this led to incorrect line numbers in error messages and the like, I would definitely use such a precompiler. A step in the second direction was a slight modification of Haskell such that instance declaration and instance implementation can be provided in separate modules. Elke. -- Elke Kasimir EsPresto AG ----------------------------------------------------------------- - Software Development- Breite Str. 30-31 Tel/Fax: +49-30-90 226-750/-760 10178 Berlin/Germany

2 1

RE: Problem with hierarchical libraries.
by Simon Marlow 12 Mar '03

12 Mar '03

> > IIRC, something very similar was suggested a while back on > the libraries > > list, except that the form beginning with a dot was the > relative module > > name (actually I think I prefer it that way). > > this seems exactly the opposite of what all file systems do. i know > lateral thinking is great, but why do we have to be backwards > all the time? Because it seems strange to have to add the prefix dot to all of our existing imports ('import Prelude' becomes 'import .Prelude'). Besides, I like the idea that the prefix dot is an indication that the current module name has been omitted. > > Personally, I've been using the hierarchical module names > for a while > > and I really don't mind writing out the whole name each > time. It means > > you have less context to think about when reading the source. > oh come on :-) most of the time you don't get to see the > module name > at all -- you have to keep scrolling to the top of the file. > virtually > every editor can tell you what is the name of the file you are > editing... (:f in vim). and tools like haddoc can display > the name of > the module anyways. I think you misunderstand me - my point was that currently, an import declaration means the same regardless of what the current module name is. With relative imports, that's not true any more (but you're right that the editor usually helps by showing the filename). It's a minor point I grant you, but simplicity at the expense of a bit of extra typing is sometimes a good thing. > > This arises because the meaning of a module is defined > independently of > > the mapping between modules and filenames. > > the meaning of modules can still be independent of the > mapping between > modules and filesnames. all that has to be specified is how > to compute this mapping. And that's exactly what we don't want to do (IMO). Filesystems are too different - what about filesystems that don't have directories? What if I want to store my source code in a database or on the web? What about non-case-sensitive filesystems, or ones with restrictions on the length of filenames? > and one has to do that anyways, even if the haskell > report pretends that this can be ommited. Yes, but the point is that it is done by the compiler, not the language specification, so compilers are free to implement different policies, and the spec doesn't have to acquire any platform-specific warts. The mapping between filenames and module names in GHC is rather complicated, see recent discussions on glasgow-haskell-users(a)haskell.org. The mapping in Hugs is different - more liberal in some ways, but less complicated because of the lack of interface files. [snip] > in fact if one decides to ignore this mapping, > all that the "hirarchical modules" proposal does is allow one > to write "." in a module name. Bingo :-) Cheers, Simon

1 0

MoChArt-03 submission deadline extended to March 17
by Charles Pecheur 12 Mar '03

12 Mar '03

[Apologies if you receive more than one copy of this message. -- The Organizers.] ===================================================================== **************************************************** *** EXTENDED Submission deadline: March 17, 2003 *** **************************************************** CALL FOR PAPERS & PARTICIPATION *************************************** SECOND WORKSHOP ON MODEL CHECKING AND ARTIFICIAL INTELLIGENCE (MoChArt-03) August 10, 2003, Acapulco, Mexico IJCAI-03 Workshop Program http://mochart03.na.infn.it/ ===================================================================== Model checking (MC) is the name given to the process of determining whether or not a formula of some logic is satisfied by a model for the logic. Model checking is limited by its exponential complexity with respect to the size of the system being verified. Nevertheless, MC procedures for many classes of models and logics of interest have been efficiently automated and successfully applied to a broad range of real-size applications in the last decade. These recent advances have lead to a growth of interest in the use of the technology in Artificial Intelligence (AI). In the meantime, state space exploration is a central aspect of AI, and the AI community has a long and impressive line of research in developing and improving search algorithms over very large state spaces under a broad range of assumptions. MC researchers are showing a growing interest in this vast body of knowledge, as a way to mitigate the state-space explosion problem. Under a slightly different perspective there is growing interest in the use of model checking techniques for verifying and validating AI applications (as opposed to inside these applications themselves). This is becoming a critical issue, as AI techniques are increasingly considered for safety-critical applications such as space missions. AI software typically features unconventional architectures and requirements that ask for specific verification solutions. These solutions will only emerge from a sustained dialogue between the AI and V&V communities, through forums such as this one. The purpose of the Second MoChArt workshop is therefore to bring together researchers with an interest in both MC and AI. The goals are to tease out common themes and differences, identify common problems and their solutions, share experiences with the applicability of techniques from one field to problems from the other, and to identify the key issues to be addressed in increasing the convergence between MC and AI. The workshop will welcome submissions on all ideas, research, experiments and tools that relate to both MC and AI fields. Topics of interest include: - Foundations - Comparisons between MC and AI problems, approaches and algorithms. - Model checking for combined modal/temporal logics - Model checking for logics of common sense reasoning - Model checking approaches to AI - Planning via model checking - Model checking for multi-agent systems - Model checking for diagnosis - Model checking for games - Using concurrency models in AI (Process Algebras, Petri Nets, Statecharts,...) - AI approaches to model checking - AI approaches to the state explosion problem - Heuristics for model checking - AI approaches to automatic abstraction - Model checking for verification of AI systems - Requirements/specifications/properties for AI systems - Automated verification of AI systems - Model checking of multi-agent systems - Model checking of model-based systems - Model checking of knowledge-based systems - Tools related to any of these topics - Case studies related to any of these topics SUBMISSION The workshop notes will include original material. Archived material will also be considered for presentation but will not appear in the proceedings. Shorter papers are encouraged, particularly those exposing novel ideas or work in progress. Authors are invited to submit papers (11pt, letter or A4, no more than 12 pages long) in PostScript format or Adobe PDF by March 7, 2003 to the following e-mail address: mochart03(a)na.infn.it. The first page of each submission should carry the contact details of a nominated contact person, including email address. PARTICIPATION Participation will be by invitation. Potentially interested participants must submit a *short* position statement, indicating the reasons for their interest in the topics of the workshop to the e-mail address mochart03(a)na.infn.it, by April 1, 2003 IMPORTANT DATES AND DEADLINES - Deadline for the submission of papers: March 17, 2003. - Notification of acceptance/rejection of papers: March 30, 2003. - Deadline for the posotion statement: April 1, 2003 - Deadline for the receipt of camera-ready papers: May 15, 2003. ORGANIZING COMMITEE Massimo Benerecetti Dipartimento di Scienze Fisiche Universita di Napoli ``Federico II'' Via Cintia, Complesso Monte S. Angelo I-80126 Napoli, Italy e-mail: bene(a)na.infn.it http://people.na.infn.it/~bene/ Charles Pecheur RIACS / ASE Group NASA Ames Research Center, M/S 269-2 Moffett Field, CA 94035, U.S.A. e-mail: pecheur(a)ptolemy.arc.nasa.gov http://ase.arc.nasa.gov/pecheur ===================================================================== _______________________________________________________________________ Charles Pecheur RIACS / ASE Group NASA Ames Research Center, M/S 269-2 Bldg N-269, Rm 230 Moffett Field, CA 94035, U.S.A. http://ase.arc.nasa.gov/pecheur Phone : +1-650-604-3588 mailto:pecheur@ptolemy.arc.nasa.gov Fax : +1-650-604-3594 Home phone : +1-650-967-5918

1 0

Conway's Life
by Abraham Egnor 12 Mar '03

12 Mar '03

I'm implementing Conway's Life in Haskell; my basic implementation is attached. Does anyone have suggestions for optimizations (or alternative representations)? It's interesting to note that the difference between this with no ghc optimization, -O, and -O2 is pretty striking; on my computer, it's about seven seconds, two seconds, and one second runtime, respectively. Abe module Main where import Data.Array.IArray import Data.Array.Unboxed import Data.Ix import System.Random type Grid = UArray (Int, Int) Int randomGrid :: (RandomGen g) => g -> Int -> Grid randomGrid g s = listArray b $ map (\x -> if x then 1 else 0) $ take (rangeSize b) $ randoms g where b = ((0,0),(s-1,s-1)) getCell :: Grid -> (Int, Int) -> Int getCell g c@(x,y) = if (x < xmin) || (x > xmax) || (y < ymin) || (y >= ymax) then 0 else g ! c where ((xmin, ymin), (xmax, ymax)) = bounds g update :: Grid -> Grid update g = array (bounds g) $ map aux $ assocs g where aux (c@(x,y),e) = let around = map (getCell g) $ filter (/= (x,y)) $ range ((x-1,y-1),(x+1,y+1)) in (c,rule (sum around) e) rule 2 e = e rule 3 e = 1 rule _ _ = 0 printGrid :: Grid -> IO () printGrid g = do let ((xmin, ymin), (xmax, ymax)) = bounds g mapM_ aux $ map (\x -> range ((x,ymin),(x,ymax))) [xmin..xmax] putStrLn "" where aux ixs = do mapM_ (putStr . show) $ map (g!) ixs putStrLn "" main :: IO () main = printGrid $ (iterate update (randomGrid (mkStdGen 0) 50)) !! 100

1 1