- Haskell - Haskell.org

Re: encapsulation
by Ashley Yakeley 08 Jul '02

08 Jul '02

At 2002-07-07 16:30, Andrew J Bromage wrote: >It _is_ a matter of opinion, and people can agree to disagree on these >points. What it boils down to is: What do you _want_ from >encapsulation? I think it's a homework question... -- Ashley Yakeley, Seattle WA

1 0

encapsulation
by Mark Fielder 07 Jul '02

07 Jul '02

How does Haskell provide encapsulation? What mechanisms does it use? What are Haskell's encapsulation strengths and weaknesses? Thanks for the help! Mark __________________________________________________ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com

3 2

ANN: Generic Haskell, Beryl release
by Andres Loeh 05 Jul '02

05 Jul '02

Generic Haskell version 1.23 (Beryl) ==================================== We are happy to announce the second release of Generic Haskell, an extension of Haskell which facilitates generic programming. Generic Haskell includes the following features: * type-indexed values -- generic functions definable for all Haskell data types. * kind-indexed types -- for giving types to type-indexed values * type-indexed types -- types which are indexed over the type constructors underlying Haskell datatypes. The Generic Haskell compiler takes Generic Haskell source and produces Haskell code (which is in most cases Haskell 98 compliant). Changes since 0.99 (Amber) -------------------------- * The syntax for using the type Con and Label in generic functions has slightly changed; old programs have to be adapted to this change. * Constructor cases allow special behaviour of generic functions on specific constructors. * Default cases allow to incrementally build generic functions by adding or modifying single cases of existing functions. * A module system that mirrors Haskell's module system. * Demand-driven specialisation mechanism that is compatible with the module system and should generate less code than the mechanism used before. Download -------- The Generic Haskell compiler is available in source and binary distributions. Binaries for Linux, Windows, MacOSX, and Solaris are available. These are available from: http://www.generic-haskell.org/compiler.html The documentation is also available separately from that page. For more general information, point your browser to: http://www.generic-haskell.org Why Generic Haskell? -------------------- Software development often consists of designing datatypes, around which functionality is added. Some functionality is datatype specific, whereas other functionality is defined on almost all datatypes in such a way that it depends only on the structure of the datatype. A function that works on many datatypes in this way is called a generic function. Examples of generic functionality include storing a value in a database, editing a value, comparing two values for equality, pretty-printing a value. Since datatypes often change and new datatypes are introduced, we have developed Generic Haskell, an extension of the functional programming language Haskell that supports generic definitions, to save the programmer from (re)writing instances of generic functions. The design of Generic Haskell is based on recent work by Ralf Hinze. Pleasant programming, The Generic Haskell Team at Utrecht University (Dave Clarke, Johan Jeuring, Andres Loeh) info(a)generic-haskell.org

1 0

www.numeric-quest.com
by Eileen Head 05 Jul '02

05 Jul '02

Is the Haskell Companion that was at www.numeric-quest.com available any where on the web? thank eh

2 1

Re: Hugs for MacOS X
by Hans Aberg 02 Jul '02

02 Jul '02

[I think that the appropriate newsgroup is probably hugs-bugs(a)haskell.org, so followups should probably only be set there.] At 12:24 +0800 2002/07/02, Lyndon While wrote: >We are considering applying to the Apple University Development Fund >for support to build an integrated development environment for MacOS >X based on the (already-ported) Hugs engine. There was a thread in the Hugs-Bugs list "Graphics with XDarwin on Mac OS X". Is this the "already ported" engine you are referring to (also see below)? >2. Is anyone working on this sort of environment already? The version that Pablo Azero and I made for MacOS pre-X is down, and I do not know anybody taking up a successor project for that platform. Johan Nordlander made his own version for use on the Hugs-Bugs site, but that was essentially starting from scratch version, ignoring the work that Pablo and I had made over the years. Over the years, a few, but not many, fellows expressed interest in working with the sources that Pablo Azero and I had developed, but I did not hear anything about outputs resulting from that. As for MacOS X, I have not heard of any such project. > We're not thinking of a >huge project: probably initially we will build something roughly like >the MacGofer environment (those were the days!), with an integrated >editor, command-line editing, colour-coded syntax a la the >Haskell-mode in emacs, etc. With the size (and general naivety) of >the class, the initial emphasis will be on reliability. > >My questions are: > >1. Would this be of interest to other groups who use Hugs on Macintoshes? > (Statements of interest may increase our chances of success with AUDF.) I think that there might be a general interest. My hope for the pre-X version was that it might be developed so that many might do develop the parts they were interest in, but in reality, only Pablo and I developed on the MacOS version. But perhaps this idea might be possible for MacOS X. >3. Does anyone know any reason that this sort of endeavour might be > harder than we expect? MacOS pre-X programming was extremely time-consuming: Kevin Hammond, who made the MacGofer, mentioned that he spent more time on the MacGofer MacOS GUI than what had been at that time been spent totally on developing the Hugs kernel itself. Because of this, I think that one should avoid doing anything with MacOS pre-X, when MacOS X now is widely available. The MacOS pre-X version that I and Pablo made is essentially dead, except for those that only has MacOS pre-X: Nearly all features were there in order to cover up for the fact that MacOS pre-X was not even UNIX like. The only exception was the experimental AppleEvent's feature; but I do not know how AppleEvent's work under MacOS X, and making the feature non-experimental would require to synch the Hugs kernel GC system with externally interrupting AppleEvent's sent to the Hugs kernel (or even better, making the Hugs kernel thread-proof). As for developing for MacOS X, which I think is a Objective C threaded version derived from the NeXT machine, those OO and threading features might cut down on development time. But I still suspect that the best strategy might be to do as little MacOS X GUI work as possible. So I think that the first question that you should consider is whether the program should be wholly independent of X-windows or not: As mentioned above, it seems that one has been able to run the Hugs X-Windows version on XDarwin. You might want to check if it is not best to have all versions requiring XDarwin, and then merely do the MacOS X additions that fall without that. This could be things like adding Haskell control over AppleEvent's and multimedia features not available via X-Windows. But if requiring XDarwin is not feasible, then you might do a wholly new MacOS X Darwin GUI. Building a wholly new editor is probably going to be very time consuming: In the MacOS pre-X version, we modified the wondows console that came with the CcodeWarrior compiler. It is better to wrok with proper editor sources, though. But unless you find some good source to start with, it may becoe very time consuming, I suspect. If you work with XDarwin, then perhaps XEmacs is available as well, and you can work with that one, just building some extra Macish hooks. Richard Stall said he want to enhance Emacs so that it has the capacity of IDE (Integrated Development Environment) like CodeWarrior. Again, it is important to cut development time. If you want to make a wholly Macish version, then perhaps you can find a suitable program to integrate your Hugs version with. For the MacOS pre-X, I considered BBEdit and Alpha, but it turned out to be simpler to merely modify and enhance the compiler console sources. -- But I would discourage you to modify console sources, as they will outdate, and further may not be efficiently written for modification. I just did that in order to quickly get a working interface. Perhaps you will decide to make both versions: But choosing development strategy will depend a lot on how much programming time you have available. Summing it up, I suspect that choosing development strategies will depend a lot on how to cut development time, even though MacOS X programming in itself should be interesting, in view that it is now one of the more advanced OS's available. Hans Aberg

1 0

Hugs for MacOS X
by Lyndon While 02 Jul '02

02 Jul '02

At The University of Western Australia, we use Hugs 98 on Macintoshes to teach Foundations of Computer Science to approximately 300 first-year students (http://undergraduate.cs.uwa.edu.au/courses/230.123) Currently we use Hugs 98 on MacOS 8.6. We're likely to change to MacOS X for 2003, and we're likely to continue using Hugs 98 on that platform. We are considering applying to the Apple University Development Fund for support to build an integrated development environment for MacOS X based on the (already-ported) Hugs engine. We're not thinking of a huge project: probably initially we will build something roughly like the MacGofer environment (those were the days!), with an integrated editor, command-line editing, colour-coded syntax a la the Haskell-mode in emacs, etc. With the size (and general naivety) of the class, the initial emphasis will be on reliability. My questions are: 1. Would this be of interest to other groups who use Hugs on Macintoshes? (Statements of interest may increase our chances of success with AUDF.) 2. Is anyone working on this sort of environment already? 3. Does anyone know any reason that this sort of endeavour might be harder than we expect? Thanks for any input. -- Dr. Lyndon While -------- Email - lyndon(a)cs.uwa.edu.au ,-_|\ Phone - +61 8 9380 2720 / \ Fax - +61 8 9380 1089 *_,-._/ Web - http://www.cs.uwa.edu.au/~lyndon v

4 4

Research Job: Compositional Analysis & Reasoning for Software Systems @ Heriot-Watt U., Scotland, UK
by Joe Wells 30 Jun '02

30 Jun '02

Research Position Useful Logics, Types, Rewriting, and their Automation (ULTRA) Group Computer Science Department School of Mathematical and Computer Sciences Heriot-Watt University Edinburgh, Scotland, UK The HTML version of this job posting can be found at: http://www.cee.hw.ac.uk/~jbw/position-ad.html Description of the Position A research position is available working on modular reasoning and compositional analysis for software at Heriot-Watt University working with Joe Wells. The position is in the ULTRA (Useful Logics, Types, Rewriting, and their Automation) group in the Computer Science Department in the School of Mathematical and Computer Sciences (formerly the Department of Computing and Electrical Engineering) at Heriot-Watt University in Edinburgh, the capital of Scotland. The position involves close collaboration with both the EC-funded DART (Dynamic Assembly, Reconfiguration, and Type-checking) project (members: Genova Univ., Heriot-Watt Univ., Imperial Coll., and Torino Univ.) and the EC, EPSRC, NATO, and NSF-funded Church Project (members: Boston Coll., Boston Univ., Harvard Univ., Heriot-Watt Univ., Wellesley Coll., etc.). It will be helpful if the researcher is competent in 1 or more of the following knowledge areas which are likely to be used in the project. * Formal calculi for reasoning about the meaning of computer systems (including computer programs), especially those with aspects of (a) modules, linking, and loading, (b) concurrency, (c) mobility, (d) staged compilation, (e) objects, (f) resource usage, etc. * Analysis of systems represented in formal calculi. * Constraint solving and unification. * Type systems, especially those with intersection and union types. * Programming languages used for any of the above. The duration of the position is from 6 months to 2.5 years, depending on the circumstances of the researcher, with extensions possible depending on salary, experience, performance, and funding. Applications to spend a shorter period (e.g., the sabbatical leave of an established academic) will be considered. The initial salary will be commensurate with qualifications and experience in the range from 19681 GBP to 26491 GBP per year. The position is available immediately, with the ideal start date being 2002-09-01. It is preferred that before starting the researcher will have completed a Ph.D. in a relevant discipline within Computer Science. Very good Ph.D. students who want to spend a year of their studies this way will be considered. Applicants from outside the European Economic Area (EEA) will be considered. The researcher will probably collaborate on 1 or more of the following activities. The specific activities will be matched to the strengths of the researcher. * Designing new type systems for compositional (modular) analysis of systems that may involve one or more aspects of concurrency, mobility, modularity, objects, run-time code generation, etc. * Designing analysis algorithms for the new type systems. * Designing theories (e.g., "calculi") for reasoning about the meaning of dynamic software assembly, i.e., doing in a non-traditional order one or more of type checking, code generation, linking, loading, etc. * Making software systems incorporating the new type systems, algorithms, and calculi. * Writing scientific reports on the work done. Contact Information Informal inquiries should be directed to Joe Wells at: web: http://www.cee.hw.ac.uk/~jbw/ e-mail: jbw(a)cee.hw.ac.uk fax: +44 131 449 3834 Formal applications should be directed to the Heriot-Watt Personnel Office at: web: http://www.hw.ac.uk/personnel/ e-mail: personnel(a)hw.ac.uk voice mail: +44 131 451 3475 fax: +44 131 451 3475 minicom: +44 131 451 8212 post: The Personnel Office Lord Balerno Building Heriot-Watt University EDINBURGH EH14 4AS GREAT BRITAIN Applying for the Position Please use the reference code 106/02/L to help prevent your application from getting mixed up. Please convert Microsoft Word documents to a public, standard, and non-proprietary format. The best format is PDF, because some of our staff will encounter difficulties with HTML or PostScript. To formally apply for this position, please do as many as possible of the items in the following list by 2002-07-24. The first 2 are absolutely necessary and the 4th is quite important. * Cause 3 reference letters to be sent. (If someone in the Heriot-Watt Personnel Office tells you the letters are not needed yet, please ignore them, because we want to see the letters before choosing who to interview.) * Send the following yourself: + your complete curriculum vitae, and + contact details for the people writing your reference letters. * Optionally, also send either of the following: + a brief statement about why your research accomplishments and interests are a good match for the position, and + up to 3 relevant publications of yours. * Get the Heriot-Watt Personnel Office to send you an "application pack". (This contains an application form, an equal opportunities monitoring form, information for applicants with disabilities, and some additional information about Heriot-Watt and the position.) Fill out and return the application form and optionally the equal opportunities monitoring form. If your curriculum vitae is well constructed, then some information requested will be redundant, so just write "see c.v." in those blanks, but return the form anyway. * It is helpful to inform Joe Wells that you are applying so that he knows to ask our personnel office for your application materials. * Anyone who might need a work permit if hired (usually someone who is not a citizen of an EEA country) should also do the following. In addition to possibly being e-mailed or faxed, each letter of reference should also be sent by post on official-looking headed stationery paper and should include details on your whereabouts over the last two years. A work permit application also needs copies of any degree certificates, so it is a good idea to send those also at the same time as you send the rest of your application. For your information, the standard solicitation for a reference letter by Heriot-Watt Personnel Office asks the letter writer for details of: * the capacity in which they know the candidate, * the candidate's skills, abilities and performance in relation to the post applied for, * the candidate's employment record including details of the candidate's role and service dates, * their view of the candidate's suitability for the post as a whole, in light of the attached details and their knowledge of the candidate's experience and abilities, * any further relevant information which would assist us in making an appointment.

1 0

Re: arrows
by Ashley Yakeley 29 Jun '02

29 Jun '02

At 2002-06-07 06:18, Wolfgang Jeltsch wrote: >Of course! My Parser type. What's its implementation? -- Ashley Yakeley, Seattle WA

2 1

Re: Haskell digest, Vol 1 #656 - 3 msgs
by Zdenek Dvorak 29 Jun '02

29 Jun '02

Hello. >Can I write dependencies like this: > > > class C x y z | x -> (y, z) > > class D x y z | (x, y) -> z > >in hugs? in ghc? The ghc doc refers to >Mark Jones: "Type Classes with Functional Dependencies", >http://www.cse.ogi.edu/~mpj/pubs/fundeps.html >where this seems to be allowed (section 4, page 9) > >Especially, I would need class D above. class C can be rewritten to >class C x y z | x -> y, x -> z concerning class D, I used (in GHC) >class D x y z | x y -> z and it seemed to do what I wanted. I guess >class C x y z | x -> y z would work too. Zdenek Dvorak _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx

1 0

functional dependencies
by Johannes Waldmann 29 Jun '02

29 Jun '02

Can I write dependencies like this: > class C x y z | x -> (y, z) > class D x y z | (x, y) -> z in hugs? in ghc? The ghc doc refers to Mark Jones: "Type Classes with Functional Dependencies", http://www.cse.ogi.edu/~mpj/pubs/fundeps.html where this seems to be allowed (section 4, page 9) Especially, I would need class D above. -- -- Johannes Waldmann ---- http://www.informatik.uni-leipzig.de/~joe/ -- -- joe(a)informatik.uni-leipzig.de -- phone/fax (+49) 341 9732 204/252 --

1 0