- Haskell - Haskell.org

functor
by Chen Yu 30 Oct '01

30 Oct '01

3 3

Haskell Communities Survey - LAST CALL
by C.Reinke 29 Oct '01

29 Oct '01

Dear Haskellers, over the last weeks, more and more of you have (been;-) volunteered to provide short summaries of recent and planned activities in your area of work with or on Haskell (for details, and for the current status, see http://www.haskell.org/communities/) Those summaries, as far as they haven't reached me already, are due in this week (rather sooner than later), and after putting everything together, the first edition of the collective report should get out to this list next week. The web pages shows which areas are covered, and which summaries have reached me. So, please, have a last look at the web page, and check for: missing topics? If your favourite Haskell topic isn't covered yet, get in touch with me as soon as possible (preferably by sending in a summary, but at least by naming possible contacts) micro-reports? late-breaking news?-) If you don't have any big project/group/area to report on, you might still want to let the Haskell community know that you're there and what you are working on. Just drop me a line or two on your work, and a link to your home page. missing reports? If you've promised a report, remember to send it to me!-) missing emails? If I've asked for your help, could you please let me know whether or not you'll be able to provide a report?-( Cheers, Claus

1 0

Positions at the Technical University of Denmark
by Hanne Riis Nielson 29 Oct '01

29 Oct '01

A number of positions are available at the Department of Informatics and Mathematical Modelling at the Technical University of Denmark: - one or more associate professorships (tenured) within the area of secure and reliable systems (comprising real-time systems, programming languages, security and reliability); see http://www.adm.dtu.dk/nyheder/job/sos0312_e.htm for more details - a PhD scholarship (3 years) associated with the static analysis workpackage of the upcoming EU project DEGAS; see http://www.imm.dtu.dk/~riis/degas.jpg for a brief description of the project - a postdoc/research assistant position (1 year, possibly with extension to 2 years) associated with the static analysis workpackage of the EU project SECSAFE; see http://www.imm.dtu.dk/~riis/secsafe.jpg for a brief description of the project Apologies for multiple copies of this message. -- -------------------------------------------------------------------- Hanne Riis Nielson direct phone: (+45) 4525 3736 Informatics & Mathematical Modelling mailto:riis@imm.dtu.dk Technical University of Denmark http://www.imm.dtu.dk/~riis --------------------------------------------------------------------

1 0

RE: rank 2-polymorphism and type checking
by Ashley Yakeley 29 Oct '01

29 Oct '01

At 2001-10-24 01:08, Simon Peyton-Jones wrote: >So I'm interested to know: if GHC allowed arbitrarily-ranked types, who >would use them? I would. Right now I have a class for 'IO lifted monads', that is, monads from which one can call IO actions: class (Monad m) => IOLiftedMonad m where { callIOWithMap :: ((m a -> IO a) -> IO b) -> m b; callIO :: IO a -> m a; callIO = callIOWithMap . const; }; The 'callIOWithMap' function allows such things as 'catch' to be defined over the monad: class (IOLiftedMonad m) => IsJVMMonad m where ... jvmCatch :: (IsJVMMonad m) => m a -> (JThrowable -> m a) -> m a; jvmCatch foo catchClause = callIOWithMap (\map -> catch (map foo) (\x -> map (do { exRef <- callIOWithEnv vmGetClearException; noEx <- callIO (getIsNothing exRef); if noEx then (callIO (ioError x)) else catchClause (MkJVMRef exRef); }))); Now this is fine, because both occurences of 'map' have the same type. But I recently discovered this doesn't work if the map is used with different types. For instance, GHC 5.02 won't compile this: test :: (IOLiftedMonad m) => m a -> m b -> m (a,b); test ma mb = callIOWithMap (\map -> do { a <- map ma; b <- map mb; return (a,b); }); It looks like what I really need is this: callIOWithMap :: ((forall a. (m a -> IO a)) -> IO b) -> m b; Is that correct? But GHC doesn't allow it... -- Ashley Yakeley, Seattle WA

1 0

Re: Multi-parameter OOP
by Richard Uhtenwoldt 28 Oct '01

28 Oct '01

Ashley Yakeley: >I think existential types are arranged so that Haskell never needs to >store type information in them at run-time. So you'll never be able to do >dynamic OOP with them. > >One possible extension to Haskell for dynamic OOP, which I never tire of >suggesting, is the extensible datatype, for instance: > > module P > data BaseType = B1 | B2 | _ > > module Q > data DerivedType = D1 | D2 > data BaseType |= BD DerivedType That rubs me the wrong way in that it invents new notions, eg, "| _" and "|=" when I get the feeling extant notions can be reused. Eg, why not try to replace the equality with an implication (both equality and implication being notions we already need to know), eg, >data BaseType <= B1 | B2 >data BaseType <= D1 | D2 Of course, that is just an untested idea. My reason for posting is to bring attention to how something similar is done in the language merd, whose designer posts here under the name pixel, and which is actually implemented I think. Having just found this, I do not understand it, but it sure has the look, tone and feel of a good design. merd has a notation a !< b which means that values of type "a" can be used when expecting a value of type "b" --ie, it is a subtype. (note the similarity to "<=".) Haskell's data declaration makes a sum-of-products type, eg, data Maybe a=Nothing|Just a In contrast, merd has sum types written a|b and product types written (a,b) and data constructors which are capitalized, eg, True, Just. So this next is the definition of Maybe in merd: (Maybe,x) = Nothing | (Just,x) (I've simplified and renamed constructors a little.) I believe that factoring Haskell's datatypes into constituent parts, which merd does, is essential to a good subtyping design. Haskell's datatypes are too specialized for particular patterns of uses. In addition, merd has a type called a struct, written a |&| b. For reasons I do not understand, instead of defining, eg, point = (double,double) or point = (Point,double,double) pixel prefers to define point = (X,double) |&| (Y,double) That last way is the standard way of declaring a record type, says pixel. The fact that none of the types introduced so far can be built from the other 3 types is made clear by the rules for subtypes, some of which are (a0, ..., an) !< (b0, ..., bn) <=> ai !< bi (forall i) a !< a | b a |&| b !< a i !< a and i ! i !< a |&| b i !< a or i ! i !< a | b i !> a and i !> b <=> i !> a | b i !> a or i !> b <=> i !> a |&| b i !< a | b|&|c <=> i !< a|b |&| a|c i !> a |&| b|c <=> i !> a|&|b | a|&|c i !> i | a => i !> a i ! i !> a i ! i !< a i !> i |&| a => true i !> i|&|a | b => i !> b i !< i|a |&| b => i !> a and i !b !< a->b !< a->b|d A->B !> x->x <=> (exists x. A !< x and B !> x) The words "covariant" and "contravariant" are mentioned, whatever they are. More at http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/~checkout~/merd/ merd/subtyping.me?content-type=text/plain and http://merd.sourceforge.net/types.png

2 1

GHC modules and packages
by Wolfgang Jeltsch 28 Oct '01

28 Oct '01

Hello, is there some documentation about which modules reside in which packages in GHC? Wolfgang

2 1

Re: GHC modules and packages
by Ashley Yakeley 28 Oct '01

28 Oct '01

At 2001-10-28 00:32, Wolfgang Jeltsch wrote: >Hello, >is there some documentation about which modules reside in which packages in >GHC? Here, where the packages are called 'categories': http://haskell.org/ghc/docs/latest/set/book-hslibs.html Unfortunately 'category std' is missing from this. But you can find some slightly less useful documentation on that here: http://haskell.org/onlinelibrary/libindex.html Unfortunately the Prelude is missing from this. But you can find some considerably less useful documentation on that here: http://haskell.org/onlinereport/standard-prelude.html Quite apart from the documentation, the Haskell library situation in general seems to be widely acknowledged as a bit of a shambles, and a serious improvement effort is ongoing. -- Ashley Yakeley, Seattle WA

1 0

Subject prefixes (was: RE: suggestion)
by Simon Marlow 27 Oct '01

27 Oct '01

> > What do you all think about activating the mechanism that > > automatically includes the name of the list before the subject > > of a mailing list email? > > For example: > > "[hugs-users] Installation problems" or "[haskell] newbie > > question". > > I don't like the extra prefixes, but if most folk would > prefer them then > I can turn them on. Let me know if you have a preference one > way or the > other (don't mail to the list). Thanks to all those who replied. The results were: 9 in favour of adding a '[haskell]' prefix, and 15 against. So I won't make any changes this time. For those who were in favour of adding the prefix, the preferred solution is to have your mail reader automatically sort Haskell mail into a separate folder. There are plenty of useful headers in the messages from haskell.org which make it possible to do just that - eg. List-Id is a good one. Cheers, Simon

1 0

Haskell Communities Survey - Second Call for Contributions
by C.Reinke 26 Oct '01

26 Oct '01

Dear Haskellers, after the first rush of volunteers seems to have ebbed away, it is probably time for a reminder. First, the good news: We have just about enough topics covered to convince me that it makes sense to go ahead. So the Haskell Communities page has moved to a more permanent location at http://www.haskell.org/communities/ and any further documents will appear there as well. I even have the first reports coming in already (thanks very much!). If everyone else could please send in their reports over the next two weeks, i.e., before *** Monday, 29. October 2001 ***, then I could try to edit everything together in the following week (modulo my own deadlines..) and put out the first version of the collective Haskell Communities Status Report early in November. Simon Marlow sent a nice example of a (more frequent) report from the FreeBSD community, which might give an idea of how a collection of brief summaries can help to get and keep an overview of a field: http://www.geocrawler.com/archives/3/159/2001/9/150/6646127/ So far, so good. The not so good news is that there are still some quite important areas uncovered, so *** we are still looking for active Haskellers *** *** to write (and send to me) brief summaries. *** Below, you'll find first a list of topics I would like to see covered, then the list of topics for which we already have volunteers. If you think you can help out with information on one or more of the outstanding topics, please let me know. If you have the information, but are unsure about what would be a useful summary for the report, get in touch with me and we'll see what we can do. Cheers, Claus ------------------------------------ contacts still needed: ------------ core * Haskell Central changes over the last year, plans for the next few months? * Hugs often feared to be dying, but kept very much alive by enthusiasts; Currently, OGI and other enthusiastic volunteers are supporting. Any ideas about the future? What about the new release (when, what)? * nhc98 lots of new work there, though much of it will probably be covered by Olaf's report on tracing and debugging? !! for all implementations, it would be nice to know the !! position and status regarding recent extensions that !! need support to be portable, such as FFI, hierarchical !! modules namespace, portable libraries, GUI API & libraries. ------------ others * non-sequential Haskell This is an important and active area, and we seem to have lots of projects there. Ideally, someone in the field could give an overview of the state-of-the-art, but I would also be happy to get summaries from individual projects (we've got Concurrent Haskell, but nothing else yet; what about GPH, port-based distributed Haskell, ..?). [and why is there no dedicated mailing-list for the collection of non-sequential Haskell projects?] * meta programming support for Haskell Tim Sheard would like to start a project on a Haskell version of Meta ML. Any progress there? Meanwhile, there are a small number of Haskell parsers and pretty-printers around. But how complete are they, are they being kept up to date, what about language extensions? What about a standard AST format? What about static analysis and type checking/inference? A standard interface to symbol table information? Partial evaluation for Haskell?-) Reification/reflection (Bernard Pope and Lee Naish have done some work here in the context of declarative debugging)? Why all the extra tools, btw? Could we not have a standard interface to the parsers, type checkers, symbol tables that exist in our Haskell implementations (as is the case for other respectable languages?-) * lightweight modules for Haskell At this year's Haskell workshop, Mark Shields asked those interested to cooperate on this topic to contact him, mentioning that he was working on the topic. It would be useful to have an idea of the plans there. Aha, I've just found a brand new paper on that, perhaps Mark could give a brief summary of that and the implementation plans?-) * Haskell libraries collection will that be covered in the report on hierarchical module namespaces or do we need a separate report? Simon? * FFI tools Manuel will cover FFI language extensions and libraries, as well as his own C->Haskell, but what about the other tools built on top of the FFI basis? What is the status of Greencard, Hdirect & co? What about all that recent talk about new Haskell to Java connections?-) If anything is still (or newly) active: summaries&pointers, please! * Documentation tools earlier this year, there was some work and discussion on this. Anyone willing to summarise the results? * Applications Perhaps someone at Galois Connections could summarise their recent successes and immediate plans (I've heard lots of good news from that direction recently)? Haskell in hardware specification and verification? ..others.. * Formal basis The effective lack of a formal semantics for Haskell has been a constant source of embarrassment (functional languages: solid theoretical basis, effective reasoning about programs, ...; Haskell: ???, ahem, oops). There seems to have been some progress recently, and it would be nice to hear more about all that. E.g., what state the work is in, what the immediate plans are, where to get the (draft) deliverables, if any: - Karl-Filip Faxen, KTH Stockholm, has been working on a formalisation of Haskell's static semantics. - the Programmatica project at OGI, Oregon, has been working on an implementation of Haskell's static semantics in Haskell; and had to ask for clarification of ambiguities in the ongoing revisions of the Haskell 98 language report. - Andrew Tolmach, OGI, has been working on a formal specification of GHC's version of core Haskell, the subset into which full Haskell is translated for definition, compilation and optimisation. - the functional programming group at York has been working on operational semantics for Haskell to support their work on profiling and tracing, to enable reasoning about time and space behaviour, and about execution traces. - .. other work in this area..? ------------------------------------ volunteers so far: GHC Simon Peyton-Jones Foreign function interface (language extensions & libraries) Manuel Chakravarty Hierarchical module namespaces Simon Marlow GUI library API new task force [summarised by Manuel's recent announcement] Concurrent Haskell Simon Marlow Generic programming Johan Jeuring [report done!] Tracing and debugging Olaf Chitil Happy Simon Marlow C->Haskell Manuel Chakravarty Functional Reactive Programming (at Yale) John Peterson

3 2

RE: bug in displaying fixed numbers
by Simon Marlow 26 Oct '01

26 Oct '01

> I was very surprised when I discovered (writing a bit more complicated > program) that a program like > > > import Numeric ( floatToDigits ) > > print $ showFFloat Nothing 0.01 "" > > enters in to infinite loop. I found that (formatRealFloat FFFixed > Nothing) do not like displaying numbers less than 0.1. Yes, the code was recently discovered to be buggy and has been fixed in the revised Haskell 98 report. GHC 5.02 is using the fixed version. Cheers, Simon

1 0