October 2001 - Haskell

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

Re: Incoherence
by John Hughes 26 Oct '01

26 Oct '01

John Hughes wrote: | `x := []' wouldn't be problematic, just monomorphic. | That is, x must be used consistently as a list of a | particular type. Just to check if I understand you correctly. In your proposal, does the following thing share `x'? let x = fac 100 in x + x (My understanding is that, in order to do this in your proposal, we have to say: let x := fac 100 in x + x Correct?) Correct. Does this also mean that it becomes impossible to share polymorphic values? I.e. the following contrived example will not behave as usual: wrong :: Either String a wrong = Left (show (fac 100)) -- not shared? example1 :: Either String Int example1 := do wrong return 1 example2 :: Either String Char example2 := do wrong return 'a' (With the usual Either monad instance.) Also true. Of course, in this case, there is a perfect remedy, just lifting out `show (fac 100', which is a monomorphic expression. However, this is not always possible, we might have a datatype like this: data PolyMonoList a = Poly Int (Foo a) | Mono a (Foo a) | Nil We can construct rather large polymorphic values, which have to be converted in linear time to the same value of a different type. Yup. I guess we already have the problem of not being able to share monomorphic values polymorphically. In fact, the Either monad instance is a good example: instance Monad (Either e) where return = Right Left x >>= k = Left x Right a >>= k = k a In the definition of `>>=', it is impossible to share `Left x'. /Koen. All true, but I doubt whether any of this is a big deal. MLers already live with their "value restriction", which has similar penalties, so there is a precedent. John

2 1

Re: Deprecated feature section
by John Hughes 26 Oct '01

26 Oct '01

George Russel proposed a search for things which should be deprecated. I have a very distinct unfondness for contexts in algebraic data type declarations. They make absolutely no difference except move type errors to a different part of a program (or rather, they add type errors). In that sense they could be said to be quite harmless, but they dramatically complicate the typing rules for everything involving algebraic data types, especially when combined with labelled fields. Cheers, /kff Seconded! There is a sensible meaning for contexts on data-type declarations, but Haskell ones don't have it. (See my paper "Restricted Data Types" in the Haskell workshop a couple of years ago). At present they are simply useless. John

1 0