- Haskell - Haskell.org

Re: Problem with hierarchical libraries.
by Iavor S. Diatchki 11 Mar '03

11 Mar '03

hi, sorry for moving this back to the haskell mailing list, but i think the module system is part of the language and is not a library. Simon Marlow wrote: > [ moved to libraries(a)haskell.org ] > > >>why not fix the design to take this into account? one can >>have two ways >>to refer to modules - relative and absolute (just like in the file >>system, which years of experience show works pretty well). >> >>import .Test.A -- refers to an absolute path >> -- (relative to a user specified root) >> -- i.e. $HS_PATH/Test/A.hs >>import Test.A -- is a path relative to the location of >> -- the current module, i.e. >> -- [location of module]/Test/A.hs > > > 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? > 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 also have another question about the hirarchical modules >>design -- why >>does one have to duplicate the path to a particular file >>inside the file >>itself? i.e. what is the point of the module name within the file? >>it seems that all haskell implementations assume that the module name >>and file name are the same (and this seems perfectly reasonable), and >>with the hirarchical name space this is even more the case. and for >>example C programers never specify the name of the current >>file within >>the file. why do we want to do it? > > > 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 one has to do that anyways, even if the haskell report pretends that this can be ommited. in fact this is exactly what the initial poster was asking. this whole issue about realtive/absoulte paths is part of specifying the mapping between module names and file names. 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. if one wants to keep modules and file names comletely independent it seems that one should introduce some notion of a "project" or something, which specifies the above mentioned mapping. however i am not sure that the additional flexibility of such an approach would be useful, and i would be perfectly happy with a single fixed way to compute the maping between modules and files. > I agree that this leads to some redundancy, and it can be annoying that > moving modules from one place in the hierarchy to another requires > editing the source. > > Building knowledge of the filesystem into the spec is the wrong thing to > do, given that filesystems tend to have platform-specific differences > (eg. single quote is allowed in a module name - is it allowed in a > filename? on which operating systems?). making them the same seems wrong. the one being an abstraction of the other does not seem all that bad. for the particular problem you raise there are at least two more or less obvious choices: * disallow single quotes in module names (but not necessarily module name aliases) * say what should single quote be mapped to in the file system (e.g. _) i like the first one better. what does GHC do in this situation? bye iavor -- ================================================== | Iavor S. Diatchki, Ph.D. student | | Department of Computer Science and Engineering | | School of OGI at OHSU | | http://www.cse.ogi.edu/~diatchki | ==================================================

1 0

ANNOUNCE: GHC vesrion 5.04.3 released
by Simon Marlow 11 Mar '03

11 Mar '03

============================================================== The (Interactive) Glasgow Haskell Compiler -- version 5.04.3 ============================================================== We are pleased to announce a new patchlevel release of the Glasgow Haskell Compiler (GHC), version 5.04.3. This is a bugfix-only release. For all the changes since 5.02.3, see the release notes: http://www.haskell.org/ghc/docs/latest/html/users_guide/release-5-04.htm l How to get it ~~~~~~~~~~~~~ The easy way is to go to the WWW page, which should be self-explanatory: http://www.haskell.org/ghc/ We supply binary builds in the native package format for various flavours of Linux and BSD, and in InstallShield form for Windows folks. Binary builds for other platforms are available as a .tar.gz which can be installed wherever you want. The source distribution is also available from the same place. Once you have the distribution, please follow the pointers in the README file to find all of the documentation about this release. Background ~~~~~~~~~~ Haskell is a standard lazy functional programming language; the current language version is Haskell 98, agreed in December 1998. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating good code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces (C, whatever). GHC is distributed under a BSD-style open source license. A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page (see below). On-line GHC-related resources ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Relevant URLs on the World-Wide Web: GHC home page http://www.haskell.org/ghc/ Haskell home page http://www.haskell.org/ comp.lang.functional FAQ http://www.cs.nott.ac.uk/~gmh/faq.html System requirements ~~~~~~~~~~~~~~~~~~~ To compile programs with GHC, you need a machine with 64+MB memory, GCC and perl. This release is known to work on the following platforms: * i386-unknown-{linux,*bsd,mingw32} * sparc-sun-solaris2 * alpha-dec-osf3 * powerpc-apple-darwin (MacOS/X) Ports to the following platforms should be relatively easy (for a wunderhacker), but haven't been tested due to lack of time/hardware: * hppa1.1-hp-hpux{9,10} * i386-unknown-solaris2 * mips-sgi-irix{5,6} * {rs6000,powerpc}-ibm-aix The builder's guide on the web site gives a complete run-down of what ports work; it can be found at http://www.haskell.org/ghc/docs/latest/building/building-guide.html Mailing lists ~~~~~~~~~~~~~ We run mailing lists for GHC users and bug reports; to subscribe, use the web interfaces at http://www.haskell.org/mailman/listinfo/glasgow-haskell-users http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs There are several other haskell and ghc-related mailing lists on www.haskell.org; for the full list, see http://www.haskell.org/mailman/listinfo/ Please report bugs using our SourceForge page at http://sourceforge.net/projects/ghc/ or send them to glasgow-haskell-bugs(a)haskell.org. GHC users hang out on glasgow-haskell-users(a)haskell.org. Bleeding edge CVS users party on cvs-ghc(a)haskell.org.

1 0

CHARME 2003
by Tronci Enrico 11 Mar '03

11 Mar '03

---------------------------------------------------------------------- We apologize if you receive multiple copies of this announcement. ---------------------------------------------------------------------- *********************************************************************** C A L L F O R P A P E R S *********************************************************************** CHARME 2003 The 12th Advanced Research Working Conference on: Correct Hardware Design and Verification Methods 21-24 October 2003, University of L'Aquila, L'Aquila, Italy http://www.di.univaq.it/charme2003 Co-sponsored by the IFIP TC10/WG10.5 Working Group on Design and Engineering of Electronic Systems CHARME 2003 is the twelfth in a series of working conferences devoted to the development and use of leading-edge formal techniques and tools for the design and verification of hardware and systems. It has been the aim of the conference to expand its interest to software as well when the technology is related. Previous conferences have been held in Darmstadt, Edinburgh, Grenoble, Glasgow, Leuven, Torino, Arles, Frankfurt, Montreal, and Bad Herrenalb, and Edinburgh. It is the biennial counterpart of FMCAD, which takes place every even year in the USA. The aim of CHARME 2003 is to bring together researchers and users from academia and industry working in this active area of research. The conference will cover original research results, case studies, use of technologies across application domains, and reports on practical experiments. Papers describing original work in all aspects of formal hardware and system design and verification methods are invited. Papers related to formal modeling and verification of concurrent software are also welcome. The event will be held 21-24 October 2003 and hosted by University of L'Aquila, Italy. L'Aquila can be easily reached from Rome Airport. Topics of interest include, but are not limited to: * usage of semi-formal methods (combining simulation methods with formal verification) * high level design modeling languages and high level design constructs * formal verification of hybrid systems * timing verification * formal methods for commercial hardware description languages * correctness preserving transformations * formal synthesis methods * use of theorem provers for verification * BDD and FSM based approaches, including model checking and SAT checking * correctness aspects in HW/SW co-design * abstraction and compositional techniques * formal verification of protocols * diagnosis of design errors * coverage directed verification and other semi-formal verification methods * use of formal specification languages in simulation * formal verification of concurrent software * practical and industrial applications of formal techniques The conference proceedings will appear as a volume in Springer-Verlag's Lecture Notes in Computer Science series and will be available at the conference. Papers should not exceed 15 pages, formatted as specified by Springer-Verlag in the Authors Instructions page, and submitted electronically following the procedure given on the submissions page of the conference website, http://www.di.univaq.it/charme2003. Selected contributions may be invited for publication in STTT (International Journal on Software Tools for Technology Transfer, Springer-Verlag). ****************************************************************************** Author's Schedule: * 11 April 2003 - Deadline for paper submission * 6 June 2003 - Notification of acceptance * 11 July 2003 - Deadline for final version ****************************************************************************** Chairs Enrico Tronci (conference chair) (University of Rome, Italy) Daniel Geist (programme chair) (IBM, Israel) ****************************************************************************** Programme Committee Alan Hu (University of British Columbia, Canada) Alan Mycroft (University of Cambridge, UK) Anna Slobodova (Intel, USA) Armin Biere (Swiss Federal Institute of Technology, Switzerland) Byron Cook (Microsoft Corporation, USA) Carl Pixley (Synopsys, USA) Daniel Geist (PC Chair) (IBM, Israel) Dominique Borrione (University of Grenoble, France) Eli Singerman (Intel, Israel) Enrico Tronci (Conference Chair) (University of Rome, Italy) Ganesh Gopalakrishnan (University of Utah, USA) Hans Eveking (T.U. Darmstadt, Germany) John O'Leary (Intel, USA) Ken McMillan (Cadence, USA) Laurence Pierre (University of Marseille, France) Limor Fix (Intel, Israel) Mark Aagaard (University of Waterloo, Canada) Mary Sheeran (Chalmers Univ. and Prover Technology, Sweden) Moshe Vardi (Rice University, USA) Ofer Strichman (Carnegie-Mellon University, USA) Steve Johnson (Indiana University, USA) Thomas Kropf (Bosch, Germany) Tiziana Margaria (Univ. of Dortmund and METAFrame Techn., Germany) Tom Melham (University of Oxford,UK) Warren Hunt (University of Texas at Austin, USA) ******************************************************************************

1 0

ANNOUNCE: Helium, for Learning Haskell, version 1.1
by Arjan van IJzendoorn 11 Mar '03

11 Mar '03

Dear all, We are proud to announce version 1.1 of Helium. It can be found at the Helium website: http://www.cs.uu.nl/~afie/helium/ Version 1.1 has the following improvements: - An installer for Windows systems for an improved out-of- the-box experience. - A cool Java-based graphical interpreter called Hint written by a student at our institute. It has a nice GUI with colours, toolbar buttons and menu's. The best feature is that it integrates with your favourite editor and you can jump to the exact locations of messages by clicking on them! - New warnings and hints for common mistakes: "sin .3", "X = 5" (see below for examples of messages) - Completely new presentation of type errors with more information - Much improved syntax error messages thanks to a new lexer. And thanks to Parsec we can tell not only what was unexpected, but also what would be legal at that position. - The command-line interpreter is now called 'texthint' to avoid conflicts with hmake's 'hi' (sorry!). TextHint is improved in many ways. For one, it now accepts file paths after :l. Other improvements can be found if you type :? - User manuals for the different tools (helium, hint, texthint) and other helpful information on the Helium website - We've compiled Helium with Oxygen (ghc -O2) and this makes the compiler twice as fast. Great work, GHC people! - One well-placed 'seq' makes Helium another 25% faster. - Very many minor bug fixes - The webpage is simpler, wider and easier to navigate thanks to a road map Have fun! the Helium team -- Examples of Helium messages These messages where generated by typing expressions on the texthint prompt. If you compile a file with these errors you will get exact error locations. Prelude> [(1, 3] Unexpected close bracket ']' Hint: Expecting a close bracket for '(' Prelude> sinn .2 Warning: Function composition (.) immediately followed by number Hint: If a Float was meant, write "0.2" Otherwise, insert a space for readability Undefined variable "sinn" Hint: Did you mean "sin" ? Prelude> map [1..10] even Type error in application expression : map [1 .. 10] even term : map type : (a -> b) -> [a] -> [b] does not match : [Int] -> (Int -> Bool) -> c probable fix : re-order arguments Prelude> let X = 5 in X Left hand side pattern defines no variables Undefined constructor "X" Hint: Use identifiers starting with a lower case letter to define a function or a variable Undefined constructor "X" Prelude> 1+chr '0' Type error in variable expression : chr type : Int -> Char expected type : Char -> Int probable fix : use ord instead

1 0

RE: polymorphic type in state of state monad
by Simon Peyton-Jones 11 Mar '03

11 Mar '03

| | > type State = Term a => [a] | | > data M a = M (State -> IO(State,a)) | | | | GHC yields a error message "Illegal polymorphic type". | | How to resolve this? I can tell you what it happening. If you have -fglasgow-exts on, the type for State is short for type State = forall a. Term a => [a] And then you can't use that polymorphic type in the argument of a tuple, as you are doing in the next line. Without -fglasgow-exts (i.e. in Haskell 98) the first line is plain illegal: 'a' is not in scope. But GHC may not produce as perspicuous a message as it should for that. Simon

1 0

AADBUG 2003: Reminder
by nilsson＠cs.yale.edu 10 Mar '03

10 Mar '03

Dear All, The deadline for submisson to AADEBUG'2003, the Fifth International Workshop on Automated and Algorithmic Debugging, is approaching. Papers and demos should be received by 22 March, 2003. Please find the CFP enclosed. See http://aadebug2003.elis.rug.ac.be/ for further details. Best regards, /Henrik -- Henrik Nilsson Yale University Department of Computer Science nilsson(a)cs.yale.edu AADEBUG'2003 Fifth Int. Workshop on Automated and Algorithmic Debugging Ghent, Belgium, September 8-10, 2003 Call for papers and demos Over the past decades automated debugging has seen major achieve- ments. However, as debugging is by necessity attached to particu- lar programming paradigms, the results are scattered. The aims of the workshop are to gather common themes and solutions across programming communities, and to cross-fertilize ideas. We seek papers describing original research as well as reports on practi- cal experience. We also welcome demonstrations of tools and re- search prototypes. Typical topics of the workshop include (but are not limited to): automated debugging declarative debugging type debugging knowledge-based debugging algorithmic debugging assertion-based debugging trace analysis software testing program slicing monitoring performance debugging parallel and distributed debugging debugging by simulation debugging using record/replay for any kind of programming paradigms (sequential, parallel, dis- tributed, real-time, logic programming, functional, object-ori- ented, imperative, visual languages). Accepted papers and demo descriptions will be included in the workshop proceedings, distributed locally on paper and CD, and will also be published on the CoRR (Computing Research Reposito- ry) website. Authors of the best papers will be invited to submit journal versions of their papers to a special issue of the Jour- nal of Automated Software Engineering on automated debugging. Demonstration of tools and research prototypes that implement new ideas in debugging automation will be part of the AADEBUG2003 technical program. Demos will be given in sessions together with technical paper presentations. Both demos and regular papers will receive a 30' time slot. Submission of Papers Contributors should be aware that the prospective audience will not necessarily be familiar with the addressed programming paradigms, which should, therefore, be briefly introduced. Papers should be no longer than 5000 words in length, including a 150 to 200 word abstract. Submit papers by uploading a PDF file to http://aadebug2003.elis.rug.ac.be/. Concurrently send an e-mail to aadebug2003(a)elis.rug.ac.be with the title of the paper, names of the authors, full address of the correspondent and a 150 to 200 word abstract of the paper. Submission of Demos Demo descriptions should be no longer than 2000 words including a 150 to 200 word abstract. Submit demos by uploading a PDF file to http://aadebug2003.elis.rug.ac.be/ Concurrently send an e-mail to aadebug2003(a)elis.rug.ac.be containing the title of the demo, names of the authors, full address of the correspondent and a 150 to 200 word abstract of the paper. Clearly mention the fact that you submit a demo and not a regular paper in your email. Authors having problems to submit using the web server can send the paper to aadebug2003(a)elis.rug.ac.be. Conference Information The website for AADEBUG2003 containing this Call for Papers and more info can be found at http://aadebug2003.elis.rug.ac.be/. If you encounter any kind of problem or need more information mail to aadebug2003(a)elis.rug.ac.be. Important Dates Paper and demo submission before March 22, 2003 Notification of acceptance by May 15, 2003 Final version of paper before June 30, 2003 (this applies to the local and the CoRR proceedings) Conference Information The website for AADEBUG2003 containing this Call for Papers and more information about the conference can be found at http://aadebug2003.elis.rug.ac.be/. If you encounter any kind of problem or need more information mail aadebug2003(a)elis.rug.ac.be. General Conference Chair Koen De Bosschere Ghent University, Belgium Email: kdb(a)elis.rug.ac.be Program Chair Michiel Ronsse Ghent University, Belgium Email: ronsse(a)elis.rug.ac.be Program Committee Members Mikhail Auguston New Mexico State University, USA Koen De Bosschere Ghent University, Belgium Jacques Chassin de Kergommeaux LSR/ENSIMAG, France Jong-Deok Choi IBM T.J. Watson Research Center, USA Mireille Ducassé IRISA/INSA, France Peter Fritzson Linköpings Universitet, Sweden Michael Gerndt Tech. Universität München, Germany Gerda Janssens Katholieke Universiteit Leuven, Belgium Clinton L. Jeffery New Mexico State University, USA Mariam Kamkar Linköpings Universitet, Sweden Dieter Kranzlmüller Joh. Kepler University Linz, Austria Raimondas Lencevicius Nokia Research Center, Boston Edu Metz Nokia Research Center, Boston Henrik Nilsson Yale University, USA Michiel Ronsse Ghent University, Belgium Gary Sevitsky IBM T.J. Watson Research Center, USA Markus Stumptner University of South Australia, Australia Kazunori Ueda Waseda University, Japan Roland Wismüller Technische Univ. München, Germany About Ghent Ghent is one of the oldest cities in Flanders, the Dutch speaking northern part of Belgium. Through the Middle Ages, it was among the most important economic centres of Western Europe and the historic city centre still reminds us of this period through its beautiful medieval towers. There are several trains an hour that connect Ghent to the closest international airport (Brus- sels, 60km). Other closeby airports are Schiphol (The Nether- lands, 200km) and Lille (France, 90km), both having easy train connections to Ghent.

1 0

palm?
by John Meacham 10 Mar '03

10 Mar '03

This may be an intractable goal, but is any project out there anywhere close to a working haskell 98(ish) implementation for the Palm Pilot? There would probably have to be some compromises, like 16 bit Ints and perhaps some other restrictions, but i don't think its impossible to get some sort of lazy implementation to work on such a resource starved architecture so has anyone given it a shot? for those that don't know, the palm pilot is based on the 68k processor family similar to what was used in early macintoshs. (and a whole lot of other things..) John -- --------------------------------------------------------------------------- John Meacham - California Institute of Technology, Alum. - john(a)foo.net ---------------------------------------------------------------------------

10 10

Help on handles
by Yeo Gek Hui 10 Mar '03

10 Mar '03

Hi, Has anyone have experience reading from a handle using hGetContents when the handle is still open and receives input from outside? I need to do some manipulation to the contents and I can't afford to close this handle. for example, an infinite stream "abcabc..." is written from outside to this handle and I know that 'c' means the termination and I want to get "abc", "abc" and the rest coming. I have used no-buffering for my handle and have written a function,extractC to extract the string end with the terminating character c. There is one more function, keepRest to keep the remainder of the stream. However, let's say response <- hGetContents handle and the response still has "abcabc...". I know in imperative language, response can be reassigned globally. How can I do that in Haskell? This is because I want to avoid duplications and ensure the program terminates. Thanks a lot. Cheers, Gek ,-.___,-. \> , , </ ( Y ) .->-._.-<- / / \ \ ,' ( ) `. (_,' )--._.--( `._) ,-' / \ `-. (,-. ,' `.,-. )

1 0

Postdoc & PhD positions in Datatype-Generic programming
by Jeremy Gibbons 10 Mar '03

10 Mar '03

[We apologize if you receive multiple copies of this announcement.] Postdoctoral research fellow (University of Nottingham) Doctoral studentship (University of Oxford) in DATATYPE-GENERIC PROGRAMMING The Universities of Nottingham and Oxford have positions available to work on an EPSRC-supported project entitled "Datatype-Generic Programming", running for three years and starting on or shortly after 1st August 2003. There is a postdoctoral research fellowship at Nottingham, and a DPhil studentship at Oxford. The project is to develop a novel mechanism for parametrizing programs, namely parametrization by a datatype or type constructor. The mechanism is related to parametric polymorphism, but of higher order. We aim to develop a calculus for constructing datatype-generic programs, with the ultimate goal of improving the state of the art in generic object-oriented programming, as occurs for example in the C++ Standard Template Library. Further details of the project can be obtained from the contacts listed below. Applicants for the postdoctoral fellowship should have completed (or be about to complete) a PhD degree. Preference will be given to applicants with an excellent knowledge of the calculational style of reasoning. Expertise in functional programming, object-oriented programming and the mathematics of program construction is required. Send a detailed curriculum vitae and the names and addresses of two referees to Professor Roland Backhouse, School of Computer Science and Information Technology, University of Nottingham, Jubilee Campus, Wollaton Road, Nottingham NG8 1BB, UK, rcb(a)cs.nott.ac.uk, www.cs.nott.ac.uk/~rcb, from whom further details can also be obtained. Electronic applications should be sent in PDF format; other formats will not be accepted. The ideal applicant for the DPhil studentship would have (or be about to obtain) a first- or upper-second class honours degree or equivalent in computer science, with expertise in functional programming, object-oriented programming and the mathematics of program construction. The studentship pays for all university and college fees, in addition to the standard EPSRC maintenance grant. Applicants should follow the procedure described at www.comlab.ox.ac.uk/oucl/courses/grad02-03/dphil/requirements.html, but should also mention this position in the application. For further details contact Dr Jeremy Gibbons, Oxford University Computing Laboratory, Wolfson Building, Parks Road, Oxford OX1 3QD, UK, jeremy.gibbons(a)comlab.ox.ac.uk, www.comlab.ox.ac.uk/oucl/people/jeremy.gibbons.html. The closing date for applications for both positions is Monday 14th April 2003. Roland Backhouse Jeremy Gibbons -- Jeremy.Gibbons(a)comlab.ox.ac.uk Oxford University Computing Laboratory, TEL: +44 1865 283508 Wolfson Building, Parks Road, FAX: +44 1865 273839 Oxford OX1 3QD, UK. URL: http://www.comlab.ox.ac.uk/oucl/people/jeremy.gibbons.html

1 0

FFI Tutorial / Examples
by Matthew Donadio 10 Mar '03

10 Mar '03

Hi all, I may be being a bit dense about this, but I am having some trouble understanding how to use FFI, especially with respect to interfacing Haskell lists/arrays to C arrays. For example, say I have the C functions void foo (double *input, double *output, int N); double bar (double *input, int N); and I want to create an FFI interface and have the resulting type signatures be > foo :: Array Int Double -> Array Int Double > bar :: Array Int Double -> Double where the bounds of the arrays are (0,N-1), and both foo and bar are pure. I read through the FFI docs, but I am still confused about how to do this. Can anyone point me to an FFI tutorial, or some examples? I have a feeling that once I see some examples using lists and arrays that things will fall into place. Thanks. -- Matthew Donadio (m.p.donadio(a)ieee.org)

2 1