- Haskell-Cafe - Haskell.org

List of instantiated types
by Mirko Rahn 30 Mar '06

30 Mar '06

Hello, please suppose the following setting: (see [1] too) {-# OPTIONS_GHC -fglasgow-exts #-} module C where class C a where name :: a -> String ; pre :: a -> a data Cs = forall a . (C a) => Cs a instance C Cs where name (Cs a) = name a ; pre (Cs a) = Cs (pre a) mkCs :: C a => a -> Cs mkCs = Cs instance C Int where name = show ; pre = \ _ -> 0 instance C Char where name = return ; pre = \ _ -> 'A' all_Cs = [ mkCs (undefined :: Int), mkCs (undefined :: Char) ] Note that despite I served undefined values only I can type *C> map (name . pre) all_Cs ["0","A"] to extract some information. But, when several instances spreads over some modules, writing down 'all_Cs' is an error-prone task, in particular when using some third party modules. So my question is: Is it possible to construct 'all_Cs' automatically? I think such a list cannot be constructed at compile-time, but at link- and run-time a complete list of instantiated types should be available. But is this list accessible somehow? Is there a possibility to write foreach type t that is an instance of C: return (mkCs (undefined :: t)) What is the general problem? Thanks, MR [1] http://www.haskell.org/pipermail/haskell-cafe/2006-March/014947.html -- -- Mirko Rahn -- Tel +49-721 608 7504 -- --- http://liinwww.ira.uka.de/~rahn/ ---

2 1

Haskell saves lives :)
by Bulat Ziganshin 30 Mar '06

30 Mar '06

-- i think that this may be interesting for other haskellers Hello Wolfgang, Wednesday, March 29, 2006, 8:24:09 PM, you wrote: >> so, the concurrent programming, may be, the only area at now, where >> real-world, commercial programmers should prefer Haskell over all >> other languages. > are you a real-world, commercial programmer? If yes, I'd like to know the yes > reason(s) for you programming in Haskell. Was it Haskell's support of > concurrency? Just interested… 1. i don't write commercial apps with Haskell. although it's not entirely impossible. i've written in cafe (search for subject "Haskell's market") that i think about this now 2. programming languages is my hobby. in my feeling the main problem with C++ and Delphi (i don't used Java/C#) is that working with complex datatypes is not simple and straightforward, another problem is lack of support for anonymous code blocks (closures). even Perl beats them in these areas! Haskell attracted me due to the great type system, great closures support, type inferencing, good syntax. Having the full power of functional language to write most complex parts of code (i mean they require most complex algorithms) is very helpful. at the same time, for 80% of program speed is not matter, and FP/laziness again helps here, allowing just to write faster these parts of program. in addition, Haskell is very strong-typed language what allows to catch much more errors at compile time. these all results in what i wrote in less than one year program that is close in functionality to that others wrote in C++ during several years. this program required to write several general purpose libs and bindings to C libs, so i enlarged HCAR's hall of fame with some new entries :) about Concurrency - i was amazed how easy to use it. my first experience in this area was carrying out part of algorithm to another thread and it was implemented with just about 30-40 lines of code! i then enclosed this technique in the module that allows to use threads as message-processing systems - each has an "stdin", "stdout" and so on and there are functions that can create networks of arbitrary complexity from individual threads. again, the Haskell's type system greatly helps me here, allowing to pass between threads structured values of arbitrary types instead of just bytes - i can't imagine whether i will have enough patience to express in another language requirement that "stdout" of each thread should produce values of exact the same type as accepted by "stdin" of next thread in the pipe/network. again, Haskell saves lives :) - i mean that its powerful type system and type inferencing allowed to write type-safe code in the area where any other language would fail. -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

1 0

Re: Equirecursive types?
by lee marks 29 Mar '06

29 Mar '06

John Hughes wrote: > ... > > > Indeed, error messages in common cases would be worsened significantly, > because as Ross says, common errors (such as forgetting a parameter in a > recursive call) would lead to legal definitions that cause a type error > when applied. Partly for this reason, OCaml permits recursion only in > object types, if I remember rightly, where it's most useful. In other > cases the occurs check is still used. > Couldn't this be mitigated by requiring an explicit type annotation on the function being called recursively? In other words infinite types are never silently inferred, but can only coincide with explicit signatures. So this is legal: type Fix s a = s a (Fix s a) fold :: Functor (s a) => (s a b -> b) -> Fix s a -> b fold f = f . fmap (fold f) but this is not: fold f = f . fmap (fold f) I guess it just seems that banning infinite types altogether is throwing the baby with the bath. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

haskell programming guidelines
by Christian Maeder 29 Mar '06

29 Mar '06

Hi, haskell admits many programming styles and I find it important that several developers of a prject agree on a certain style to ease code review. I've set up guidelines (still as plain text) for our (hets) project in http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/het… These were inspired by C programming guidelines, http://haskell.org/hawiki/ThingsToAvoid and the problems I came across myself. It like to get comments or proposals for our or other haskell grogramming guidelines. Thanks Christian

10 31

planet.haskell.org? for Haskell blogs
by Isaac Jones 28 Mar '06

28 Mar '06

I think someone should volunteer to set up "Planet Haskell" ala Planet Debian, Planet Gnome, Planet Perl, etc. These sites are "Blog aggregators". Basically they just collect the RSS feeds of the community and post their blogs to a web page in a cute format (the gnome one is especially cute, but you probably could have guessed that). There's already software out there for this, so nothing new needs to be written. I think we need a volunteer to set this up somewhere? Preferably someone with their own server, and we'll worry about setting up the DNS later :) peace, isaac See: http://planet.debian.org/ http://planet.gnome.org/ http://planet.perl.org/

3 9

Defining instance needs allow-undecidable-instance?
by Daniel McAllansmith 28 Mar '06

28 Mar '06

Hi, folks. I've got a working class and instances thereof. I would now like to change the class such that error behaviour is specified by MonadError, for the moment throwing String errors. When I try to add MonadError into the types I eventually hit the requirement for allow-undecidable-instances. Is there some way I can I avoid having to use this extension? My starting point consists of: class (Num i, Bounded i, Monad m) => MonadSource i m | m -> i where ... newtype SourceT i m a = SourceT (StateT (Store i) m a) deriving (Functor, Monad, MonadIO, MonadTrans) instance (Num i, Bounded i, Monad m) => MonadSource i (SourceT i m) where ... I changed it to: class (Num i, Bounded i, Monad m, MonadError String m) => MonadSource i m | m -> i where .... newtype SourceT i m a = SourceT (StateT (Store i) m a) deriving (Functor, Monad, MonadIO, MonadTrans, MonadError e) instance (Num i, Bounded i, Monad m, MonadError String m) => MonadSource i (SourceT i m) where ... Thanks Daniel

2 2

Eval of a syntax tree for reduction
by Steve Downey 28 Mar '06

28 Mar '06

I'm working through Pierce's Types and Programming Languages on my own. I'm attempting to write the typecheckers in Haskell, instead of ML. However, when it comes to his eval function, I'm a little stuck. The original is let rec eval t = try let t' = eval1 t in eval t' with NoRuleApplies -> t Where eval1 is a single step evaluation of the abstract syntax tree, and NoRuleApplies is an exception that's raised if there are no rules that can reduce the expression. Now, there's a footnote that it isn't good style in ML. It seems even less natural in Haskell, at least to me, but I still don't know the language that well. The natural equivalent to what Pierce has in ML is something along the lines of data ArithExpr = TmTrue | TmFalse | TmIfExpr ArithExpr ArithExpr ArithExpr | TmZero | TmSucc ArithExpr | TmPred ArithExpr | TmIsZero ArithExpr deriving (Show, Eq) eval1 :: ArithExpr -> ArithExpr eval1 (TmIfExpr TmTrue t _) = t eval1 (TmIfExpr TmFalse _ t) = t eval1 (TmIfExpr t1 t2 t3) = let t1' = eval1 t1 in TmIfExpr t1' t2 t3 -- and so on But, how to terminate the recursion in the full eval? I'm considering changing eval1 to be ArithExpr->Maybe ArithExpr If the expression is reducible, then I return Just t, and if it's not reducible, then Nothing It makes eval1 a bit more complicated, and not as straightforward translation from the type system being described, though. e.g reducing If looks more like eval1 (TmIfExpr t1 t2 t3) = let t1' = eval1 t1 in case t1' of { Just t1'' -> Just $ TmIfExpr t1'' t2 t3 ; Nothing -> Nothing } and eval then looks like eval t = let t' = eval1 t in case t' of { Just t'' -> eval t'' ; Nothing -> t' } I'm looking for some suggestions on the direction to proceed.

3 2

Bit streams programs in Haskell
by Per Gustafsson 28 Mar '06

28 Mar '06

Haskell gurus, We have made a proposal to extend the Erlang `binary' data type from being a sequence of bytes (a byte stream) to being a sequence of bits (a bitstream) with the ability to do pattern matching at the bit level. This proposal has now been fully implemented all these at the level of the BEAM virtual machine and in the HiPE compiler. Most probably, they will be part of the next major Erlang/OTP open source release. (We write "most probably" because we do not really control what Ericsson desides to release as part of its open source system.) We wanted to evaluate the performance of our implementation and the succintness of our syntax, particularly against other `similar' languages. For this reason, we wrote five reasonably representative benchmarks, showing the things that one could employ bit stream pattern matching and bit-level comprehensions for. The benchmarks (drop3, five11, huffman, uudecode, and uuendode) have all been written in Erlang, O'Caml and Haskell. For some of them, C and Java versions exist. They can be found in the following homepage: http://bitbenches.infogami.com/ As you will see there, the Haskell numbers are significantly slower than those of Erlang and O'Caml. We are wondering why this is so. For each language, we have spent a considerable effort in writing the benchmarks in -- at least what we feel -- is the most natural and efficient way one can write them. The only constraint we impose is that for functional languages, data structures without any explicit mutation have to be used in the part of the program for which measurements are taken. Our experience in writing efficient (and beautiful) Haskell programs is close to (if not below) zero. Also, perhaps our mind might be suffering from severe case of strictness and might be completely unable to `think lazily'. So, we request your help in noticing obvious NO-NOs and stupid mistakes that we might have made. We even welcome completely different Haskell programs provided they adhere to the constraint mentioned above -- no mutation. Best regards, Kostis Sagonas and Per Gustafsson

5 6

Re: Equirecursive types?
by John Hughes 27 Mar '06

27 Mar '06

>From: Ross Paterson <ross(a)soi.city.ac.uk> > >On Sun, Mar 26, 2006 at 01:22:17PM -0500, Jim Apple wrote: > > >>According to Pierce's book, O'Caml has an optional equirecursive type >>extension that turns off the occurs check. Is there any particular >>reason Haskell doesn't have that available? >> >> > >It's certainly feasible, though turning off the occurs check doesn't >do it: you need to use the unification algorithm for regular trees (see >e.g. section 6.7 of the revised Dragon Book). You also need to decide >what to do about > > type T = T > >I think the arguments against it are: > * many common errors will lead to perfectly legal types. > * it adds convenience, but not expressive power. > * it only works for regular types, where the arguments of uses of the > type constructor on the rhs are the same as (or a permutation of) > the arguments on the lhs, so this is out: > > type T a = Either a (T (a,a)) > > > Indeed, error messages in common cases would be worsened significantly, because as Ross says, common errors (such as forgetting a parameter in a recursive call) would lead to legal definitions that cause a type error when applied. Partly for this reason, OCaml permits recursion only in object types, if I remember rightly, where it's most useful. In other cases the occurs check is still used. John

1 0

(!!) operator usage
by Neil Rutland 27 Mar '06

27 Mar '06

Hi there, I hope i have sent this in the right format - i gather i may have been rude by sending it incorrectly - if this is still wrong give me a shout. Anyway today i am enquiring about how to use the !! operator - i have looked at Zvons Haskell refeernce and it says that it takes a list( like newLine below) and an Integer for the location of the item you wish to return. Basically in this example i would like to return the value 4 type Bob = [(Int, Int)] newLine :: Bob newLine = [(1,4)] i have tried to use the follwing but it returns the error below it. newLine !! 0 - (so that should give it the newLine list and try and return the 1st element of the list) the error reads thus ERROR file:.\VicotriaLine.txt:107 - Type error in final generator *** Term : newLine !! 0 *** Type : (Int,Int) *** Does not match : IO a Could someone please try and tell me what thats all about because i can't see what i am doing wrong based on the examples i have found from the website i detailed about. Cheers everyone Neil

3 3