- Haskell - Haskell.org

ANNOUNCE: HaRe, the Haskell Refactorer, version 0.3
by H.Li 19 Nov '04

19 Nov '04

Dear Haskellers, As part of our project on Refactoring Functional Programs http://www.cs.kent.ac.uk/projects/refactor-fp/ we are pleased to announce the availability of HaRe 0.3 (also known as HaRe 19/11/2004), a snapshot of our Haskell Refactorer prototype. Apart from bug-fixes, there are two major changes since HaRe 0.2. First, a number of new refactorings have been added to HaRe. They are of two kinds: module refactorings such as cleaning the imports, moving a definition from one module to anther module, etc. and data-oriented refactorings such as from concrete to abstract data type. Second, we have evolved the architecture of HaRe and derived an API (documented using Haddock) for program analysis and transformation. This allows HaRe to serve as a framework for end-users to build their own refactorings or just program transformations. You can get HaRe 0.3 and the documentation about how to build your own refactorings via: http://www.cs.kent.ac.uk/projects/refactor-fp/hare.html Please see the README.txt for build/use instructions and known issues, and let us know about any problems, bugs, suggestions or additional platforms you can confirm as working. Happy Refactoring! The HaRe Team (Huiqing Li, Chris Brown, Claus Reinke, Simon Thompson) Project email: refactor-fp(a)kent.ac.uk Background: Refactoring is the process of changing the structure of programs without changing their functionality, i.e., refactorings are meaning-preserving program transformations that implement design changes. For more details about refactoring, about our project and for background on HaRe, see our project pages. HaRe - the Haskell Refactorer: HaRe is our prototype tool supporting a collection of refactorings for Haskell 98 (see README.txt for known issues and limitations). It is implemented as a separate refactoring engine (on top of Programatica's Haskell frontend and Strafunski's generic traversal strategy library), with small scripting frontends that call this engine from either Vim or Emacs. The refactoring engine itself has been seen to build (with ghc-6.2.1) and run on most flavours of Windows (cygwin needed to build) and on Suns, so we expect it to build and work on other unix-like platforms with almost no changes. In other words, we've tried to make sure that most of you should be able to build and use HaRe from your favourite OS/editor. Currently supported refactorings: removeDef : remove an unused definition duplicateDef : duplicate a definition under a new name liftToTopLevel : move a local definition to top level liftOneLevel : move a local definition one level up demote : move a definition local to point of use rename : rename an identifier introNewDef : turn expression into use of new definition unfoldDef : replace use of identifier by right-hand side addOneParameter: add parameter to definition rmOneParameter : remove unused parameter from definition generaliseDef : turn expression on rhs of definition into new parameter of that definition clean imports : clean the imports to remove unnecessary ones make import explicit: make the used entities explicit in the identified import declaration add to export : add an item to the export list remove from export : remove an item from the export list move def to another module : move a definition from one module to another module From concrete to abstract data type: transform a concrete data type to an abstract one, which is composed from a sequence of elementary refactorings. Caveats (see also README.txt): Please keep in mind that this is a prototype, so we do not recommend to use it on your productions sources just yet. Just play with it to get an idea of tool-supported refactoring in Haskell, and send us your feedback and bug-reports. Our goal is to develop this into a tool that many of you will find indispensable for Haskell development. History: Functionally, HaRe 0.1 was still roughly the snapshot you'd seen at the Haskell workshop, packaged up for relative ease of build/use, but unaware of types and modules, and all refactorings only working on a single module. It had some annoying issues that plagued some of our Emacs users, didn't work at all with literate Haskell files, and had several other minor problems. HaRe 0.2 did not add refactorings, but all refactorings were modified to take Haskell's module system into account. This means that a single refactoring may affect multiple modules in a given project (e.g., renaming an exported function should trigger corresponding renamings in all client modules that are part of the current project), that export/import lists have to be respected or adapted, and that generally the refactorings should now work in multi-module settings. Beyond these major changes, several issues in the Emacs version of the user interface have been ironed out, there is initial support for literate Haskell files, and lots of smaller issues have been dealt with (see README.txt for a few more details). Interim snapshots have been available since December last year, and some of you have already played with those. The earliest snapshots were somewhat buggy, but over the last weeks the software has stabilised to the extent that we are back to Bug 0 (aka: insufficient test-coverage!-), and the time has come to distribute the current snapshot more widely.

1 0

RE: [Haskell] Unnamed fields
by Simon Peyton-Jones 19 Nov '04

19 Nov '04

I'm not sure there's a "good" reason; it seems a reasonable idea. But it's certainly not in Haskell today, and my feeling is that's it's not sufficiently compelling to implement as "yet another GHC feature". But if loads of people say it'd transform their lives, I might reconsider :-) Simon | -----Original Message----- | From: haskell-bounces(a)haskell.org [mailto:haskell-bounces@haskell.org] On Behalf Of Ian Lynagh | Sent: 16 November 2004 21:10 | To: Malcolm Wallace | Cc: haskell(a)haskell.org | Subject: Re: [Haskell] Unnamed fields | | On Tue, Nov 16, 2004 at 04:07:48PM +0000, Malcolm Wallace wrote: | > On Tue, 16 Nov 2004 15:04:02 +0000, Ian Lynagh <igloo(a)earth.li> wrote: | > | > > > Is there a good reason why I can't say | > > > | > > > data Bar = Bar { _ :: Int, _ :: Char, x :: Bool } | | In case it wasn't clear, there is an x :: Bool in lots of alternatives, | so I really want | | data Bar = Bar { _ :: Int, _ :: Char, x :: Bool } | | Baz { _ :: String, x :: Bool } | | ... | | > Since you only want one field out of many, what is the difficulty in | > simply defining the projection/updating functions separately? | > | > data Bar = Bar Int Char Bool | > x (Bar _ _ b) = b | > (Bar i c _) `updX` b = Bar i c b | | Then I have to write twice as much again (2n if there are n fields I do | want to name). I'm not denying it's possible to do without it, but it | would make life easier if we had the above. I also think that it feels | inconsistent that it isn't possible. | | | Thanks | Ian | | _______________________________________________ | Haskell mailing list | Haskell(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell

1 0

CFP: 1st Int'l Workshop on Automated Specification and Verification of Web Sites (WWV'05)
by Santiago Escobar 19 Nov '04

19 Nov '04

[ We apologize for multiple copies ] ******************************************************************* 1st International Workshop on Automated Specification and Verification of Web Sites (WWV'05) March 14-15 2005, Valencia, SPAIN http://www.dsic.upv.es/workshops/wwv05 ******************************************************************* SCOPE The increased complexity of Web sites and the explosive growth of Web-based applications has turned their design and construction into a challenging problem. Nowadays, many companies have diverted their Web sites into interactive, completely-automated, Web-based applications (such as Amazon, on-line banking, or travel agencies) with a high complexity that requires appropriate specification and verification techniques and tools. Systematic, formal approaches to the analysis and verification can address the problems of this particular domain with automated and reliable tools that also incorporate semantic aspects. We solicit paper on formal methods and techniques applied to Web sites, Web services or Web-based applications, such as: * rule-based approaches to Web site analysis, certification, specification, verification, and optimization * formal models for describing and reasoning about Web sites * model-checking, synthesis and debugging of Web sites * abstract interpretation and program transformation applied to the semantic Web WWV'05 provides a forum for researchers from the communities of Rule-based programming, Automated Software Engineering, and Web-oriented research to facilitate the cross-fertilization and the advancement of hybrid methods that combine the three areas. Participants are encouraged to present work in progress, overviews of more extensive work, position papers and reports of practical experiences. WWV'05 is supported by the EU Commission under ICT for EU-India Cross-Cultural Dissemination project ALA/95/23/2003/077-054. LOCATION WWV'05 will be held in Valencia, Spain (http://www.turisvalencia.es) at the Department of Information Systems and Computation of the Technical University of Valencia (http://www.dsic.upv.es) SUBMISSION PROCEDURE Submission will be web-based via the conference web-site: http://www.dsic.upv.es/workshops/wwv05 Submissions must be received by January 10, 2005. In addition, an ASCII version of the title and abstract must be submitted by January 4, 2005. These are strict deadlines. Submitted papers should be at most 15 pages in the Electronic Notes in Theoretical Computer Science (ENTCS) style and should include an abstract and the author's information. See the author's instructions of ENTCS style at http://math.tulane.edu/~entcs. PUBLICATION Accepted papers will be published in a preliminary proceedings volume, which will be available during the workshop. Publication of the workshop proceedings in the series Electronic Notes in Theoretical Computer Science (ENTCS) is envisaged. PROGRAM CO-CHAIRS Maria Alpuente (Technical University of Valencia, Spain) Moreno Falaschi (University of Siena, Italy) WORKSHOP CHAIR Santiago Escobar (Technical University of Valencia, Spain) PROGRAM COMMITTEE (TBA) ORGANIZATION The ELP Group http://www.dsic.upv.es/users/elp/elp.html IMPORTANT DATES Abstract Submission 4 January 2005 (strict) Full Paper Submission 10 January 2005 (strict) Acceptance Notification 19 February 2005 Camera Ready 3 March 2005 Workshop 14-15 March 2005

1 0

pattern matching woes
by Ryan Paul 18 Nov '04

18 Nov '04

I recently elected to employ Haskell for my functional programming needs rather than Ocaml. Thus far, I have been relatively happy with the expressiveness and syntactic grace of Haskell, but there are a few aspects of Haskell's syntax that irritate me... In OCaml, when I am doing pattern matching, I can string together patterns to which I wish to assign the same result. for example: match a with X z | Y z | Z z -> True | _ -> False I cannot find a good way to do this with Haskell. I would really like to be able to do that, and I cant think of any reasons why it shouldnt be possible - could such a feature be added to the Haskell standard? If anybody can suggest possible alternatives, I would like to see them - the following is the actual code in question, from one of my compiler projects: The Haskell code: flatten a = case a of App l -> flatten' l List l -> a : flatten' l Arg l -> a : flatten l Ret l -> a : flatten l Fun _ l -> a : flatten' l Call _ l -> a : flatten' l Assign _ l -> a : flatten l Op x _ z -> a : flatten x ++ flatten z _ -> [a] where flatten' l = foldl (\x y -> x ++ (flatten y)) [] l As compared to the ocaml equivelent: let rec flatten a = let proc l = (List.fold_left (fun x y -> x @ (flatten y)) [] l) in match a with | Op (x,y,z) -> a :: (flatten x) @ (flatten z) | Assign (n,l) -> a :: (flatten l) | Fun (n,l) | Call (n,l) -> a :: (proc l) | App l | List l -> a :: (proc l) | Arg l | Ret l -> a :: (flatten l) | _ -> [a] My second issue is with modules. I regularly use modules to clean up namespace issues. When I want to do this with Haskell, I have to define the module in a separate file and then use qualified import to bring it into the file in which I want to use it. Often, I dont particularly want or need to use the module again elsewhere, so putting it in a separate file is counterintuitive. I would like to be able to nest my modules, and have the parent module be able to do a qualified import on the modules inside of it. The following is an example of how I use nested modules in OCaml: module Get = struct let funcs = function App l -> l >< Is.func | _ -> [] ;; let params = function Fun (n,l) -> l >< Is.param | _ -> [] ;; let assigns = function Fun (n,l) -> l >< Is.assign | _ -> [] ;; let calls = function Fun (n,l) -> l >< Is.call | _ -> [] ;; let vargs = function Call (n,l) -> l >< Is.varg | _ -> [] ;; module All = struct let funcs a = (flatten a) >< Is.func ;; let assigns a = (flatten a) >< Is.assign ;; let strs a = (flatten a) >< Is.str ;; let consts a = (flatten a) >< Is.const ;; let calls a = (flatten a) >< Is.call ;; end end When I want to extract all the calls from a func recursively, I would do something like: Get.All.calls somefunc If I just wanted to get the calls at the very top level, I would do: Get.calls somefunc Note: i'm not subscribed to the mailing list, so if you respond, please cc your response to my email address. Thanks! -- SegPhault

1 0

parser for "Typing Haskell in Haskell"
by WANG Meng 18 Nov '04

18 Nov '04

Hi All, Does anybody know what parser "Typing Haskell in Haskell" use? I am tring to use the code for some type checking. But I cannot find a parser in the distribution. -W-M- @ @ | \_/

2 1

Closed Projections on HLists?
by Jared Warren 18 Nov '04

18 Nov '04

I'm doing some work with heterogeneous sets as provided by the HList library <http://homepages.cwi.nl/~ralf/HList/>. My code uses projections of sets internally and I keep running into the open-world assumption when I ask the type checker to infer the result of projections. For example (in ghci): *> hProject hNil No instance for (HProject HNil l') ...When obviously the only valid projection from the empty set is the empty set. Here is how HProject is currently implemented in HOccurs.hs: > class HProject l l' > where > hProject :: l -> l' > instance HProject l HNil > where > hProject l = HNil > instance ( HList l', HOccurs e l, HProject l l') > => HProject l (HCons e l') > where > hProject l = HCons (hOccurs l) (hProject l) The constraints on the non-trivial case seem to already use closed type classes; eg: *> hProject hNil :: HCons HNil HNil No instance for (Fail (TypeNotFound HNil)) My attempts to rewrite hProject to use the Fail class explicitly don't solve the problem. The best I have done is replace projections by membership in the powerset (implementation at the end of this message in case anybody's interested), but that just reduces the problem to trying to close HLookupByHNat when I try and get the appropriate subset out of the powerset. So what I'm wondering: is it possible to rewrite HProject in such a way as to allow the type checker to infer that the only possible projections from a list are its (non-proper) sublists? Jared Warren <warren(a)cs.queensu.ca> School of Computing, Queen's University ----- An Implementation of Power Sets on Heterogeneous Lists By the algorithm from http://www.haskell.org/pipermail/haskell-cafe/2003-June/004465.html: > class HPowerSet xs yss | xs -> yss where > hPowerSet :: xs -> yss > > instance HPowerSet HNil (HCons HNil HNil) > where > hPowerSet _ = hCons hNil hNil > > instance (HPowerSet xs yss, > HMapConst (HPrepend x) yss zss, > HAppend yss zss wss) > => HPowerSet (HCons x xs) wss > where > hPowerSet (HCons x xs) = let yss = hPowerSet xs > in hAppend yss (hMap (HPrepend x) yss) Partially-applied hCons: > data HPrepend x = HPrepend x > instance HList ys => Apply (HPrepend x) ys (HCons x ys) > where > apply (HPrepend x) = hCons x An alias for hMap's constraint: > class HFoldr (HMap f) HNil xs ys => HMapConst f xs ys | f xs -> ys > instance HFoldr (HMap f) HNil xs ys => HMapConst f xs ys

1 0

Create a List
by Jose manuel Hernando Cobeña 17 Nov '04

17 Nov '04

2 1

Unnamed fields
by Ian Lynagh 16 Nov '04

16 Nov '04

Hi all, Is there a good reason why I can't say data Bar = Bar { _ :: Int, _ :: Char, x :: Bool } ? (Or "data Bar = Bar { Int, Char, x :: Bool }" if you prefer, but that's susceptible to typos of the "x, y, z :: Int" syntax causing confusion). I have a large datastructure in which there is one field I wish to be able to use field reads and updates for, but I don't want to have to invent loads of names for the other fields. The only minor issue I can think of is that the derived Show instance would say Bar{_=5,_='c',x=True} but, while it's a bit odd, I don't think it's a problem. Thanks Ian

4 4

package with ghc and ghci
by Fred Nicolier 16 Nov '04

16 Nov '04

Hello, I have some packages for doing signal and image processing stuff. Here is a little test program : \begin{code} module Main where import Hips a = listSignal (1,10) [1..10] b = liftSignals (:+) a a c = fft b main = do putStrLn $ show a putStrLn $ show b putStrLn $ show c \end{code} 1/ Compiled with : ghc -package hips testFFT.hs 2/ interpreted with : ghci-package hips testFFT.h 1/ no problem 2/ dont execute and gives 'unknown package name: =Numeric' (Numeric is another package called by Hips, included in HaskellDSP). Any solution ? Fred

1 0

CfP reminder: LDTA 2005
by Thomas Noll 15 Nov '04

15 Nov '04

[Reminder: deadline Dec. 1st is approaching] ****************************************************************** *** CALL FOR PAPERS *** *** *** *** Fifth Workshop on *** *** Language Descriptions, Tools and Applications *** *** LDTA 2005 *** *** *** *** Satellite event of ETAPS 2005 *** *** April 3, 2005 *** *** Edinburgh, Scotland, UK *** *** *** *** http://www-i2.informatik.rwth-aachen.de/Events/LDTA2005/ *** ****************************************************************** SCOPE: The aim of this one-day workshop is to bring together researchers from academia and industry interested in the field of formal language definitions and language technologies, with a special emphasis on tools developed for or with these language definitions. This active area of research involves the following basic technologies: Program analysis, transformation, and generation Formal analysis of language properties Automatic generation of language processing tools For example, language definitions can be augmented in a manner so that not only compilers or interpreters can be automatically generated but also other tools such as syntax-directed editors, debuggers, partial evaluators, test generators, documentation generators, etc. Although various specification formalisms like attribute grammars, action semantics, operational semantics, and algebraic approaches have been developed, they are not widely exploited in current practice. It is the aim of the LDTA workshops to bridge this gap between theory and practice. Among others, the following application domains can benefit from advanced language technologies: Software component models and modeling languages Re-engineering and re-factoring Aspect-oriented programming Domain-specific languages XML processing Visualization and graph transformation Programming environments such as Eclipse, Rotor, SUN Java, etc. The workshop welcomes contributions on all aspects of formal language definitions, with special emphasis on applications and tools developed for or with these language definitions. INVITED SPEAKER: LDTA 2005 is going to feature an invited talk by Erik Meijer from Microsoft Research. SUBMISSION PROCEDURE AND PUBLICATION: Submission will be open from autumn 2004. Papers (of at most 15 pages) should be submitted electronically as (optionally compressed/gzipped) PostScript or PDF files to one of the program committee chairs. The message should also contain a text-only abstract and contact author information. Please use the ENTCS style available on the ENTCS Macro Home Page http://www.math.tulane.edu/~entcs/ for preparing your submission. Final versions of accepted papers must not exceed 20 pages and have to conform to the proceedings style. Accepted papers will be published and made available during the workshop. After revision, final copies of the accepted papers will be published in Electronic Notes in Theoretical Computer Science (ENTCS), Elsevier Science. Author's instructions are given here. The authors of the best papers will be invited to write a journal version of their paper which will be separately reviewed and, after acceptance, be published in a special issue devoted to LDTA 2005 of the journal Science of Computer Programming (Elsevier Science). PROGRAM COMMITTEE: John Boyland, University of Wisconsin-Milwaukee, USA (co-chair) <Boyland(a)cs.uwm.edu> G?rel Hedin, Lund Institute of Technology, Sweden (co-chair) <Gorel.Hedin(a)cs.lth.se> Shigero Chiba, Tokyo Institute of Technology, Japan Jim Cordy, Queen's University, Kingston, Canada Susan L. Graham, University of California, Berkeley, USA Adrian Johnstone, University of London, UK Paul Klint, CWI, Amsterdam, The Netherlands Jens Knoop, Vienna University of Technology, Austria Eric Madeleine, INRIA, Sophia Antipolis, France Arnd Poetzsch-Heffter, University of Kaiserslautern, Germany Ganesh Sittampalam, Oxford University, UK Anthony Sloane, Macquarie University, Sydney, Australia Doaitse Swierstra, Utrecht University, The Netherlands Kris de Volder, University of British Columbia, Vancouver, Canada Andrew Wendelborn, University of Adelaide, Australia ORGANIZING COMMITTEE: Thomas Noll, RWTH Aachen University, Germany Joost Visser, University of Minho, Braga, Portugal Eric van Wyk, University of Minnesota, Minneapolis, USA IMPORTANT DATES: Submission deadline: December 1, 2004 Notification: January 17, 2005 Final version due: February 15, 2005 Workshop: April 3, 2005

1 0