November 2004 - Haskell

FroCoS 2005: First Call for Papers
by Bernhard Gramlich 19 Nov '04

19 Nov '04

[Apologies for multiple copies] ---------------------------------------------------------------------------- FroCoS 2005: FIRST CALL FOR PAPERS ---------------------------------------------------------------------------- 5th International Workshop on Frontiers of Combining Systems (FroCoS 2005) Vienna, Austria, September 19-21, 2005 http://www.logic.at/frocos05/ ---------------------------------------------------------------------------- BACKGROUND In various areas of computer science, such as logic, computation, program development and verification, artificial intelligence, and automated reasoning, there is an obvious need for using specialized formalisms and inference mechanisms for special tasks. In order to be usable in practice, these specialized systems must be combined with each other, and they must be integrated into general purpose systems. The development of general techniques and methods for the combination and integration of special formally defined systems, as well as for the analysis and modularization of complex systems has been initiated in many areas. The International Workshop on Frontiers of Combining Systems (FroCoS) traditionally focuses on this type of research questions and activities and aims at promoting progress in the field. The previous FroCoS workshops were held in Munich (1996), Amsterdam (1998), Nancy (2000) and Santa Margherita Ligure (2002). In 2004, FroCoS joined IJCAR 2004, the 2nd International Joint Conference on Automated Reasoning. Like its predecessors, FroCoS 2005 wants to offer a common forum for research activities in the general area of combination, modularization and integration of systems (with emphasis on logic-based ones), and of their practical use. TOPICS Typical topics of interest include (but are not limited to): * combination of logics (e.g., modal logics, logics in AI, ...); * combination of decision procedures, of satisfiability procedures, and of constraint solving techniques (e.g. unification and matching algorithms, general symbolic constraints, numerical constraints); * combinations and modularity in term rewriting; * integration of equational and other theories into deductive systems (e.g. theory resolution, constraint resolution, constraint paramodulation, ...); * combination of deduction systems and computer algebra; * integration of data structures (e.g., sets, multisets, lists) into CLP formalisms and deduction processes; * model/problem analysis and decomposition (e.g. isolating tractable or loosely connected sub-problems, global constraints design, etc.) * hybrid methods for deduction, resolution and constraint propagation (e.g., combinations of local and global, complete and propagation techniques) * hybrid systems in computational linguistics, knowledge representation, natural language semantics, and human computer interaction; * logical modelling of multi-agent systems; * logical aspects of combining and modularizing programs and specifications. INVITED TALKS t.b.a. SUBMISSIONS The programme committee seeks high-quality submissions that are original and not submitted for publication elsewhere. Submission is electronic in postscript or PDF format. Submitted papers must conform to the Springer LNCS style, preferably using LaTeX2e and the Springer llncs class files. Submission categories include full papers, for work on foundations, applications, implementation techniques, and problem sets (up to 15 pages), as well as system descriptions (up to 8 pages), for describing publicly available systems. The submission deadline is May 2, 2005 for titles and abstracts, and May 9, 2005 for papers. For further information and submission instructions see the FroCoS 2005 web page: http://www.logic.at/frocos05/. PROCEEDINGS Accepted papers will appear in the proceedings of the conference, published as a volume of the Lecture Notes in Artificial Intelligence (LNAI) series, Springer-Verlag. Proceedings will be available at the time of the conference. IMPORTANT DATES May 2, 2005: Deadline for electronic submission of abstract May 9, 2005: Deadline for electronic submission of papers June 20, 2005: Notification of acceptance/rejection Jul 11, 2005: Deadline for final versions of accepted papers Sep 19-21, 2005: Conference PROGRAM COMMITTEE * Alessandro Armando (U Genova) * Franz Baader (TU Dresden) * Clark W. Barrett (NYU New York) * Frederic Benhamou (LINA, U Nantes) * Michel Bidoit (LSV, CNRS & ENS Cachan) * Jacques Calmet (U Karlsruhe) * Juergen Giesl (RWTH Aachen) * Bernhard Gramlich (chair) (TU Wien) * Deepak Kapur (UNM Albuquerque) * Maarten Marx (U Amsterdam) * Joachim Niehren (INRIA Futurs, U Lille) * Christophe Ringeissen (LORIA-INRIA Nancy) * Manfred Schmidt-Schauss (U Frankfurt) * Cesare Tinelli (U Iowa) * Ashish Tiwari (SRI Menlo Park) * Frank Wolter (U Liverpool) ORGANIZING COMMITTEE * Aneta Binder * Bernhard Gramlich * Franziska Gusel * Genot Salzer PROGRAM COMMITTEE AND CONFERENCE CHAIR Bernhard Gramlich TU Wien, Fakultaet fuer Informatik, Theory and Logic Group Favoritenstr. 9 - E185/2, A-1040 Wien, Austria Email: gramlich(a)logic.at FURTHER INFORMATION FroCoS'05 web page: http://www.logic.at/frocos05/ ----------------------------------------------------------------------------

1 0

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