- Haskell-Cafe - Haskell.org

Initial (term) algebra for a state monad
by oleg＠pobox.com 06 Jan '05

06 Jan '05

Andrew Bromage wrote: << -- WARNING: This code is untested under GHC HEAD data State s a = Bind :: State s a -> (a -> State s b) -> State s b | Return :: a -> State s a | Get :: State s s | Put :: s -> State s () instance Monad (State s) where (>>=) = Bind return = Return instance MonadState s (State s) where get = Get put = Put runState :: State s a -> s -> (s,a) runState (Return a) s = (s,a) runState Get s = (s,s) runState (Put s) _ = (s,()) runState (Bind (Return a) k) s = runState (k a) s runState (Bind Get k) s = runState (k s) s runState (Bind (Puts) k) _ = runState (k ()) s runState (Bind (Bind m k1) k2) s = runState m (\x -> Bind (k1 x) k2) s >> The following is the code that does run, on GHC 6.2.1. Typeclasses are just as good at pattern-matching as (G)ADT, and GHC is quite good at suggesting the constraints that I have missed. The latter comes quite handy when one programs half-asleep. {-# OPTIONS -fglasgow-exts #-} {-# OPTIONS -fallow-undecidable-instances #-} module B where import Control.Monad import Control.Monad.State hiding (runState) -- data State s a -- = Bind :: State s a -> (a -> State s b) -> State s b -- | Return :: a -> State s a -- | Get :: State s s -- | Put :: s -> State s () class RunBind t s a => RunState t s a | t s -> a where runst :: t -> s -> (s,a) data Bind t1 t2 = Bind t1 t2 data Return t = Return t data Get = Get data Put t = Put t instance RunState (Return a) s a where runst (Return a) s = (s,a) instance RunState Get s s where runst _ s = (s,s) instance RunState (Put s) s () where runst (Put s) _ = (s,()) instance (RunState m s a, RunState t s b) => RunState (Bind m (a->t)) s b where runst (Bind m k) s = runbind m k s class RunBind m s a where runbind :: RunState t s b => m -> (a->t) -> s -> (s,b) instance RunBind (Return a) s a where runbind (Return a) k s = runst (k a) s instance RunBind (Get) s s where runbind Get k s = runst (k s) s instance RunBind (Put s) s () where runbind (Put s) k _ = runst (k ()) s instance (RunBind m s x, RunState y s w) => RunBind (Bind m (x->y)) s w where runbind (Bind m f) k s = runbind m (\x -> Bind (f x) k) s data Statte s a = forall t. RunState t s a => Statte t instance RunState (Statte s a) s a where runst (Statte t) s = runst t s instance RunBind (Statte s a) s a where runbind (Statte m) k s = runbind m k s instance Monad (Statte s) where (Statte m) >>= f = Statte (Bind m (\x -> f x)) return = Statte . Return instance MonadState s (Statte s) where get = Statte Get put = Statte . Put test1 (a::a) = runst (do x <- (return a :: Statte Char a) y <- get put 'b' return (y,x)) 'a' test1' = test1 "ok" test2 = runst (return True :: Statte Char Bool) 'a'

4 3

Tutorial for server programming in concurrent Haskell
by Ahn Ki-yung 05 Jan '05

05 Jan '05

I've recently started a small tutorial for server programming in concurrent Haskell. http://kyagrd.dyndns.org/wiki/HaskellServerProgramming For newbies in Haskell and/or server programming, there should be an interoductory tutorial with concrete and simple examples before Simon Marlow's papers about web server implementation in Haskell. This tutorial consists of two famous examples, Echo and Chat, with the source code and makefile to be downloaded, compliled and tested right away. I hope this could be some helpt to those who want to start server programming in Haskell. Server programming in modern fucntional language with concurrency support is a real pleasure! You should also try Erlang if you havnt' tried yet.

2 1

Re: [Haskell-cafe] ReadS with Maybe
by Jon Cast 05 Jan '05

05 Jan '05

Henning Thielemann <lemming(a)henning-thielemann.de> wrote: > What is the reason for the definition > ReadS a = [(a, String)] > not being > ReadS a = Maybe (a, String) > ? The latter one reflects that either one or no value is read, whereas > the first definition allows an arbitrary number of read values which > is confusing and unsafe in my opinion. List is a backtracking monad, while Maybe is merely an error monad. You have to have backtracking to bet better than LL(1) or LR(1) parsing, and LL(1) is not an acceptable restriction for a fundamental function like read. Jonathan Cast

1 0

ReadS with Maybe
by Henning Thielemann 05 Jan '05

05 Jan '05

What is the reason for the definition ReadS a = [(a, String)] not being ReadS a = Maybe (a, String) ? The latter one reflects that either one or no value is read, whereas the first definition allows an arbitrary number of read values which is confusing and unsafe in my opinion.

4 3

RE: [Haskell-cafe] GHC for .NET?
by Simon Peyton-Jones 05 Jan '05

05 Jan '05

| Understandably, however, there is real resistance in language communities like Haskell's to changing | or even extending a language for the sake of interoperability and API access: instead people work | incredibly hard to encode interoperability via existing mechanisms. In the end, whoever picks up the | burden of doing Haskell.NET will face the same unenviable choice that every other .NET language | design group has faced: | | (a) do you modify and/or extend the language to make "the nicest possible Haskell-like language in | the context of .NET" | | or (b) do you implement Haskell faithfully without language extensions, but where using the .NET | libraries is in practice somewhat arcane and unpleasant, probably sufficiently so that you'll be unable | to attract .NET-savvy programmers to your language. | | Personally I think language designs in space (a) are more interesting, since perfectly good native | implementations of Haskell are already available on most platforms. I also think you learn a lot more | by trying to create something new, and you give yourself the maximum possible long-term chance of | rivalling other .NET languages (which I think should be an important goal for a Haskell.NET) I agree with all of that, including leaning towards (a) -- and it also helps to explain why we have moved so slowly on the GHC.net front. GHC is a big system already, and specifically tries to be multi-platform. Making substantial, but platform-specific, language changes is arguably the Right Thing (as Don says), but not so attractive for GHC. Simon

1 0

RE: [Haskell-cafe] Problem with fundeps.
by Simon Peyton-Jones 05 Jan '05

05 Jan '05

I can see why you think it "ought" to work. The instance decls instance (Vspace a v) => Vspace a (c->v) instance Num a => Vspace a a certainly overlap, but GHC does something sensible with the overlap, and that's presumably what you want. BUT the functional-dependency mechanism doesn't have the same resolution mechanism for overlap, and so it thinks both might match, and hence rejects the program. So yet another GHC enhancement might be to combine instance selection with the improvement coming from functional dependencies. Operationally, given a constraint, match it against possible instance decls using only the types *before* the arrow in the fundep (the 'v' in the case of Vspace) once an instance is chosen, the usual overlap-resolution stuff, use the fundep to force the other type(s) to match Hmmm. Has anyone else come across this? Meanwhile, why couldn't you have this: instance (Vspace a v) => Vspace a (c->v) instance Vspace Int Int instance Vspace Float Float etc That is, one instance for each base type? You only have a finite number of base types, so this might not be too bad. Simon | -----Original Message----- | From: haskell-cafe-bounces(a)haskell.org [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of | Jerzy Karczmarczuk | Sent: 03 January 2005 13:02 | To: haskell-cafe(a)haskell.org | Subject: Re: [Haskell-cafe] Problem with fundeps. | | Henning Thielemann cites myself | | >>I am afraid that something is wrong with my understanding of multi- | >>param classes with dependencies. I tried to generalize one of my old | >>packages for quantum *abstract* computations, where state vectors are | >>defined as functional objects,... | >> | >>class Vspace a v | v -> a | >>where | >> (<+>) :: v -> v -> v | >> (*>) :: a -> v -> v | >> -- etc. | >> | >>instance Vspace a a where | >> (<+>) = (+) | >> (*>) = (*) | >> -- etc. No problem. | >> | >>instance (Vspace a v) => Vspace a (c->v) where | >> f <+> g = \x -> f x <+> g x | >> (a *> f) x = a *> (f x) | >> -- ... | >> | >> | > | >I had the same problem with the same class | > http://www.haskell.org//pipermail/haskell-cafe/2004-March/005979.html | > and thus Dylan Thurston advised me to drop functional dependencies. | > | > | I can't... Otherwise I am killed by ambiguities, later. | | >Here are two implementations using multi-type classes without functional | >dependencies. (They wait for unification, yet, sorry.) | > http://cvs.haskell.org/darcs/numericprelude/VectorSpace.lhs | > http://cvs.haskell.org/darcs/numericprelude/physunit/VectorSpace.hs | > | > | I followed this discussion, and I know your and DT DARC project. | Unfortunately my ambitions are Gargantuan, I want to have | vector spaces which encompass functions over ADT (the config. | specification for a quantum system), functions over functions | (duals and operators), and also functional tensors, which makes | it possible to construct binary functions as a 'product' of two | unary functions; extensible. | | And all this over all kind of scalars. Principally complex, but | also some differential scalars (elements of a differential algebra, | permitting to do the 'automatic differentiation' of Dirac brackets | and also kets, which would permit to use constructively the | differential recurrential definitions of states (Hermite functions, | etc.) For the moment I am obliged to FIX the field of scalars, this | *partly* solves my mathematical troubles. | | I believe in almost all what Ashley Yakeley (and Marcin QK) say, | but in | | >>> instance (Num a)=>Vspace a (c->a) where | >>> instance (Vspace a v) => Vspace a (c->v) where | >> | >> | > | >These are also incompatible. ... | > | the word 'incompatible' should be understood as 'incompatible with | current Haskell', *not* with common sense. Pity. It is obvious that | both: a function any -> scalar, and (any->scalar)->any->scalar | with good arithmetic scalars permit to establish the vector structure. | | Actually, the instances as quoted above produces bizarrily an error | which says that something is less polymorphic than expected; the | overlapping is accepted (apparently). | | Sigh. | | Jerzy Karczmarczuk | | | | _______________________________________________ | Haskell-Cafe mailing list | Haskell-Cafe(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe

2 1

RE: [Haskell-cafe] Re: GHC for .NET?
by Don Syme 05 Jan '05

05 Jan '05

> I've heard complaints about the unsuitability of the Java VM for lazy > functional languages. I wonder if the CLR also has issues for this? The CLR has some technical features that make it more attractive than the JVM, e.g. pointer-based unsafe code (useful for some closure representations), tailcalls, generics, light-weight code generation (the latter can be used for mixed interpretation/compilation with code reclamation). But in the end it will depends on what your goals are - you will probably take a performance hit, but you will get a lot of benefits, e.g. loads of great libraries and tools. I think a variant of Haskell could find a niche in the context of either Java or .NET. Cheers Don -----Original Message----- From: haskell-cafe-bounces(a)haskell.org [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of Ashley Yakeley Sent: 04 January 2005 01:14 To: haskell-cafe(a)haskell.org Subject: [Haskell-cafe] Re: GHC for .NET? In article <5DCA48FADB33FF4D8C32A164DF24F2B0023C12C0(a)EUR-MSG-03.europe.corp.microso ft.com>, "Don Syme" <dsyme(a)microsoft.com> wrote: > We still frequently talk about doing either Haskell.NET or a strict > language much closer to Haskell (perhaps as a stepping stone to doing > Haskell). But neither are currently active projects. I've heard complaints about the unsuitability of the Java VM for lazy functional languages. I wonder if the CLR also has issues for this? -- Ashley Yakeley, Seattle WA _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

1 0

RE: [Haskell-cafe] GHC for .NET?
by Don Syme 05 Jan '05

05 Jan '05

> There is some good groundwork already done... I'd add that during my first effort to do GHC.NET I modified GHC to optionally preserve full type information through to the backend, including type applications. This is necessary if you're going to produce verifiable code. > The trouble here is that Haskell's type system is more expressive > than the CLR's in some ways, notably the use of higher-kinded > type variables. The problem with higher-kinded type variables is quite significant, and were one of the reasons I stopped work on ghc.net. It is an open question as to whether you can compile type parameters to .NET generics and higher-kinded parameters by some other means (i.e. to casts etc.) - I believe it is possible by passing term parameters in place of higher-kinded type variables, where the term parameters are called whenever the type function is applied. However when I tried to implement this scheme it got too complex, especially given how few uses of higher-kinded polymorphism there are in practice. It would probably be better to initially simply inline all higher-kinded code at the callsites. Cheers Don -----Original Message----- From: Simon Peyton-Jones Sent: 04 January 2005 12:18 To: Don Syme; John Goerzen; haskell-cafe(a)haskell.org Cc: GHC users Subject: RE: [Haskell-cafe] GHC for .NET? | "The GHC compiler for .NET is currently under development at | Microsoft Research, Cambridge". | | Hmm. That location sounds familiar :-) Does anyone know if this is | actually going to happen? Or if there's any code anywhere, however | experimental, to try? It'd make a lot of sense to give GHC a .NET back end, and it's a question that comes up regularly. The reason that we haven't done it here, at GHC HQ, is because it's a more substantial undertaking than might at first appear (see below). Furthermore, it'd permanently add a complete new back-end platform for us to maintain. Given our rather limited development effort (= Simon and me), we have so far not bitten the bullet, and we have no immediate plans to do so. It'd be a good, well-defined project for someone else to tackle, and there is some good groundwork already done: * Sigbjorn Finne did a simple interop implementation that allows a Haskell program to be compiled to native code (as now) but to call .NET programs via a variant of the FFI. I don't think this work is in active use, and I'd be surprised if it worked out of the box, but it could probably be revived with modest effort * Andre Santos and his colleagues at UFPE in Brazil are working on a .NET back end, that generates CLR IL, though I don't know where they are up to. * GHC.Net would be extra attractive if there was a Visual Studio integration for GHC. Substantial progress on this has been made in 2004 by Simon Marlow, Krasimir Angelov, and Andre Santos and colleagues. There may be others that I don't know of. If anyone wants to join in this effort, do contact the above folk. And please keep us informed! Simon Here's a summary of why it's a non-trivial thing to do: - The first thing is to generate native CLR Intermediate Language (IL). That's not really hard. Requires thinking about representations for thunks and functions, and it may not be particularly efficient, but it can surely be done. An open question is about whether to generate verifiable IL or not. The trouble here is that Haskell's type system is more expressive than the CLR's in some ways, notably the use of higher-kinded type variables. So, to generate verifiable IL one is bound to need some run-time casts, and it's not clear how to minimise these. At first blush this is *all* you need do. But it isn't! - Next, you need to think about how to inter-operate with .NET libraries. You don't really want to write "foreign import..." for each and every import. You'd like GHC to read the CLR meta-data directly. But there are lots of tricky issues here; see the paper that Mark Shields and I wrote about "Object-oriented style overloading for Haskell". - Now you need to figure out how to implement GHC's primitive operations: the I/O monad arbitrary precision arithmetic concurrency exceptions finalisers stable pointers software transactional memory Not all of these are necessary, of course, but many are used in the libraries. The CLR supports many of them (e.g. concurrency) but with a very different cost model. - Last, you have to figure out what to do for the libraries. GHC has a pretty large library, and you either have to implement the primops on which the library is based (see previous point), or re-implement it. For example, GHC's implementation of I/O uses mutable state, concurrency, and more besides. For each module, you need to decide either to re-implement it using .NET primitives, or to implement the stuff the module is based on. These challenges are mostly broad rather than deep. But to get a production quality implementation that runs a substantial majority of Haskell programs "out of the box" requires a decent stab at all of them.

1 0

RE: [Haskell-cafe] GHC for .NET?
by Don Syme 05 Jan '05

05 Jan '05

> Next, you need to think about how to inter-operate with .NET > libraries. You don't really want to write "foreign import..." > for each and every import. You'd like GHC to read the CLR > meta-data directly. But there are lots of tricky issues here; > see the paper that Mark Shields and I wrote about "Object-oriented > style overloading for Haskell". >From what I've seen, .NET interoperability (i.e. API access) is too important to simply encode into a language using existing language mechanisms. Let's be honest: there isn't a single language that has succeeded in giving decent inter-operability without modifying and/or substantially extending the language (there are several faithful language implementations, e.g. OCamlIL, but these efforts have not covered interoperability). I really don't see why Haskell will be any different. Of course no design group _wants_ to change or extend their existing language, and on the whole they do not end up doing it because of limitations in the CLR. Instead they eventually come around to the fact that there are big benefits to providing .NET API access that "feels right" to the programmer, rather than forcing the programmer to use arcane encodings into existing language constructs, even if that means changing and/or extending the language. Some see this as a weakness of the .NET approach to interoperability (because it forces too much on each language, e.g. generics, classes, interfaces, properties, namespaces). Some also see it as its strength (because it gives the API designer a better set of tools, all of which will be understood by each language - at least better when compared to COM or C). Many in the first camp are language designers and/or implementers, while many in the second are working programming teams who are very happy to be able to use high-level, extensible APIs from a number of programming languages. You can argue over whether .NET has made good choices for the primitives used to express APIs (some hate classes, some hate generics), but the fundamental principle won't change: if you want rich common constructs for expressing APIs, then the language designers and implementers pay the price (by having to support a common set of non-trivial constructs), while the programmers reap the benefits. Understandably, however, there is real resistance in language communities like Haskell's to changing or even extending a language for the sake of interoperability and API access: instead people work incredibly hard to encode interoperability via existing mechanisms. In the end, whoever picks up the burden of doing Haskell.NET will face the same unenviable choice that every other .NET language design group has faced: (a) do you modify and/or extend the language to make "the nicest possible Haskell-like language in the context of .NET" or (b) do you implement Haskell faithfully without language extensions, but where using the .NET libraries is in practice somewhat arcane and unpleasant, probably sufficiently so that you'll be unable to attract .NET-savvy programmers to your language. Personally I think language designs in space (a) are more interesting, since perfectly good native implementations of Haskell are already available on most platforms. I also think you learn a lot more by trying to create something new, and you give yourself the maximum possible long-term chance of rivalling other .NET languages (which I think should be an important goal for a Haskell.NET) But people devoted to the Haskell standard will no doubt prefer (b), as may people whose main interest is in presenting .NET functionality in a Haskell-esque way (e.g. via Fran-like libraries). Finally, all this just deals with "import" interoperability. Nearly as important in practice is "export" interoperability, i.e. how is your Haskell code going to look to other .NET languages, and is it going to be usable by those languages. Just my 2c worth for the New Year :-) Cheers Don -----Original Message----- From: Simon Peyton-Jones Sent: 04 January 2005 12:18 To: Don Syme; John Goerzen; haskell-cafe(a)haskell.org Cc: GHC users Subject: RE: [Haskell-cafe] GHC for .NET? | "The GHC compiler for .NET is currently under development at | Microsoft Research, Cambridge". | | Hmm. That location sounds familiar :-) Does anyone know if this is | actually going to happen? Or if there's any code anywhere, however | experimental, to try? It'd make a lot of sense to give GHC a .NET back end, and it's a question that comes up regularly. The reason that we haven't done it here, at GHC HQ, is because it's a more substantial undertaking than might at first appear (see below). Furthermore, it'd permanently add a complete new back-end platform for us to maintain. Given our rather limited development effort (= Simon and me), we have so far not bitten the bullet, and we have no immediate plans to do so. It'd be a good, well-defined project for someone else to tackle, and there is some good groundwork already done: * Sigbjorn Finne did a simple interop implementation that allows a Haskell program to be compiled to native code (as now) but to call .NET programs via a variant of the FFI. I don't think this work is in active use, and I'd be surprised if it worked out of the box, but it could probably be revived with modest effort * Andre Santos and his colleagues at UFPE in Brazil are working on a .NET back end, that generates CLR IL, though I don't know where they are up to. * GHC.Net would be extra attractive if there was a Visual Studio integration for GHC. Substantial progress on this has been made in 2004 by Simon Marlow, Krasimir Angelov, and Andre Santos and colleagues. There may be others that I don't know of. If anyone wants to join in this effort, do contact the above folk. And please keep us informed! Simon Here's a summary of why it's a non-trivial thing to do: - The first thing is to generate native CLR Intermediate Language (IL). That's not really hard. Requires thinking about representations for thunks and functions, and it may not be particularly efficient, but it can surely be done. An open question is about whether to generate verifiable IL or not. The trouble here is that Haskell's type system is more expressive than the CLR's in some ways, notably the use of higher-kinded type variables. So, to generate verifiable IL one is bound to need some run-time casts, and it's not clear how to minimise these. At first blush this is *all* you need do. But it isn't! - Next, you need to think about how to inter-operate with .NET libraries. You don't really want to write "foreign import..." for each and every import. You'd like GHC to read the CLR meta-data directly. But there are lots of tricky issues here; see the paper that Mark Shields and I wrote about "Object-oriented style overloading for Haskell". - Now you need to figure out how to implement GHC's primitive operations: the I/O monad arbitrary precision arithmetic concurrency exceptions finalisers stable pointers software transactional memory Not all of these are necessary, of course, but many are used in the libraries. The CLR supports many of them (e.g. concurrency) but with a very different cost model. - Last, you have to figure out what to do for the libraries. GHC has a pretty large library, and you either have to implement the primops on which the library is based (see previous point), or re-implement it. For example, GHC's implementation of I/O uses mutable state, concurrency, and more besides. For each module, you need to decide either to re-implement it using .NET primitives, or to implement the stuff the module is based on. These challenges are mostly broad rather than deep. But to get a production quality implementation that runs a substantial majority of Haskell programs "out of the box" requires a decent stab at all of them.

1 0

RE: [Haskell-cafe] GHC for .NET?
by Don Syme 04 Jan '05

04 Jan '05

That's out of date - I abandoned my first effort to do ghc.net in favour of doing a strict functional language first - F# is the result (http://research.microsoft.com/projects/fsharp) We still frequently talk about doing either Haskell.NET or a strict language much closer to Haskell (perhaps as a stepping stone to doing Haskell). But neither are currently active projects. Thanks Don -----Original Message----- From: haskell-cafe-bounces(a)haskell.org [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of John Goerzen Sent: 29 December 2004 00:51 To: haskell-cafe(a)haskell.org Subject: [Haskell-cafe] GHC for .NET? Over at http://www.gotdotnet.com/community/resources/Default.aspx?ResourceTypeDr opDownList=Language+vendors&SortDirection=Desc&SortColumnName=CreationDa te, I read: "The GHC compiler for .NET is currently under development at Microsoft Research, Cambridge". Hmm. That location sounds familiar :-) Does anyone know if this is actually going to happen? Or if there's any code anywhere, however experimental, to try? As a side note, the dotgnu project includes a C-to-CLR compiler, though it has trouble passing the autoconf stuff in ghc (and I may not have the expertise to fix it; it is crashing on the alignment tests). I figure that if I can get portable enough C code out of ghc, and a runtime compiled to CLR, it should be possible to compile Haskell to .NET that way. Anyway, it's just me off on a tangent again. Thanks, John _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

2 1

lazy readFile
by Henning Thielemann 03 Jan '05

03 Jan '05

I'm also interested, how to get this example working: http://www.haskell.org/pipermail/haskell/2001-November/008336.html This seems to be an old discussion: http://www.haskell.org/pipermail/libraries/2001-April/000358.html Was a strictReadFile implemented in the meantime?

2 1

Hassoal
by Henning Thielemann 03 Jan '05

03 Jan '05

Does someone know more about the Haskell interface to the Structured Audio Orchestra Language as presented at http://sourceforge.net/projects/hassoal/ ? I was not able to contact the author.

1 0

Associative array updating
by Dominic Fox 03 Jan '05

03 Jan '05

Another newbie question. The following is a naive attempt at a word count function, that takes a string and returns a list of word/count pairs. import Char isLetter c = isAlphaNum c || c=='\'' normalize = map toLower . filter isLetter isWord [] = False isWord s = True nwords = filter isWord . map normalize . words update w [] = [(w, 1)] update w ((x, n):xs) = if x==w then (x, n+1) : xs else (x, n) : (update w xs) wordCount = foldr update [] . nwords It works fine, but it's obviously very inefficient. I could make it less inefficient by implementing the word/count dictionary as a hash table or binary tree, but that's what standard libraries are for. So - what is there in the standard libraries that I could use in this scenario? I've looked at the Array module, but don't think it's quite suitable (we don't know the array bounds ahead of time, and the indices are strings). Data.HashTable looks better, but involves IO as it mutates the dictionary entries in place. Is there an alternative that could be used with a fold as in the code above? Dominic

2 2

Typed Lambda-Expressions with GADTs
by Ashley Yakeley 01 Jan '05

01 Jan '05

This compiled with today's CVS GHC 6.3. I don't think you can do this without GADTs. module Expression where { data Sym env r where { FirstSym :: Sym (r,xx) r; NextSym :: Sym env r -> Sym (a,env) r }; runSym :: Sym env r -> env -> r; runSym FirstSym (r,xx) = r; runSym (NextSym var) (a,env) = runSym var env; data OpenExpression env r where { Lambda :: OpenExpression (a,env) r -> OpenExpression env (a -> r); Symbol :: Sym env r -> OpenExpression env r; Constant :: r -> OpenExpression env r; Application :: OpenExpression env (a -> r) -> OpenExpression env a -> OpenExpression env r }; newtype Expression r = MkExpression (forall env. OpenExpression env r); runExpression :: Expression r -> r; runExpression (MkExpression expr) = runOpenExpression expr () where { runOpenExpression :: OpenExpression env a -> env -> a; runOpenExpression (Constant r) _ = r; runOpenExpression (Application ar a) env = (runOpenExpression ar env) (runOpenExpression a env); runOpenExpression (Lambda exp) env = \a -> runOpenExpression exp (a,env); runOpenExpression (Symbol var) env = runSym var env; }; sym0 :: OpenExpression (a,env) a; sym0 = Symbol FirstSym; sym1 :: OpenExpression (a,(b,env)) b; sym1 = Symbol (NextSym FirstSym); sym2 :: OpenExpression (a,(b,(c,env))) c; sym2 = Symbol (NextSym (NextSym FirstSym)); k :: Expression (a -> b -> a); -- k = \x.\y -> x = \.\.1 k = MkExpression (Lambda (Lambda sym1)); s :: Expression ((a -> b -> c) -> (a -> b) -> a -> c); -- s = \x.\y.\z -> x z (y z) = \.\.\.2 0 (1 0) s = MkExpression (Lambda (Lambda (Lambda (Application (Application sym2 sym0) (Application sym1 sym0))))); } -- Ashley Yakeley, Seattle WA

1 0

Haskell Pangolins
by Dominic Fox 01 Jan '05

01 Jan '05

Hi all, This is just a request for comment - I've written a short Haskell program, intended to demonstrate some of the basic features of the language (how to create a data structure, transform it, and run a user interaction loop). I would like to know if there are any obvious respects in which this program could be simplified, clarified or made more idiomatic. The code may be found here: http://codepoetics.com/code/pangolin.hs thanks, Dominic

4 3

re: Associative Array Updating
by Dominic Fox 01 Jan '05

01 Jan '05

On the other hand, given that a version of this using a btree just crunched through the whole of Joyce's Ulysses in a few seconds, maybe it doesn't matter that much... Dominic

1 0

coercion to Int
by james pentland 31 Dec '04

31 Dec '04

what coercion can i use to get the below program to compile? i see class (Real a, Fractional a) => RealFrac a where round :: (Integral b) => a -> b and class (Fractional a) => Floating a where sqrt :: a -> a various combinations of fromInteger, toInteger do not help. fnK_ :: Int -> Int fnK_ x = round (sqrt x) -- line 2 Hugs session for: H:\Program Files\Hugs98\lib\Prelude.hs Prelude> :load xva Reading file "xva.hs": Type checking ERROR "xva.hs":2 - Instances of (RealFrac Int, Floating Int) required for definition of fnK_ __________________________________ Do you Yahoo!? Yahoo! Mail - Find what you need with new enhanced search. http://info.mail.yahoo.com/mail_250

4 3

coercion to Int
by james pentland 30 Dec '04

30 Dec '04

what coercion can i use to get the below program to compile? i see class (Real a, Fractional a) => RealFrac a where round :: (Integral b) => a -> b and class (Fractional a) => Floating a where sqrt :: a -> a fillK_ :: Int -> Int fillK_ x = round (sqrt x) -- line 2 Hugs session for: H:\Program Files\Hugs98\lib\Prelude.hs Prelude> :load xva Reading file "xva.hs": Type checking ERROR "xva.hs":2 - Instances of (RealFrac Int, Floating Int) required for definition of fillK_ __________________________________ Do you Yahoo!? All your favorites on one personal page � Try My Yahoo! http://my.yahoo.com

1 0

coercion to Int
by lothar 30 Dec '04

30 Dec '04

what coercion can i use to get the below program to compile? i see class (Real a, Fractional a) => RealFrac a where round :: (Integral b) => a -> b and class (Fractional a) => Floating a where sqrt :: a -> a fillK_ :: Int -> Int fillK_ x = round (sqrt x) -- line 2 Hugs session for: H:\Program Files\Hugs98\lib\Prelude.hs Prelude> :load xva Reading file "xva.hs": Type checking ERROR "xva.hs":2 - Instances of (RealFrac Int, Floating Int) required for definition of fillK_

1 0

Utility functions
by Mark Carroll 30 Dec '04

30 Dec '04

I find myself writing things like, splitListOn :: Eq a => a -> [a] -> [[a]] splitListOn delimiter = unfoldr splitter . (delimiter :) where splitter [] = Nothing splitter xs = Just (span (/= delimiter) (tail xs)) This is a sort of intersperse-opposite, in that... myId delimiter = concat . intersperse [delimiter] . splitListBy delimiter ...myId foo turns into a sort of id for lists of the correct type. With this, and other things, I always have a feeling that it's probably in the standard library somewhere but I didn't notice - maybe because it's abstracted out of recognition, just like "sequence" does Cartesian products for us, but not so that I noticed right away. Is there a good place to put these things - little things that feel like that maybe they're already in the standard library, and maybe they should be? I'd hate to be unknowingly reinventing the wheel all the time. I don't see an obviously-appropriate page for these on the Haskell Wiki, but maybe I missed it, or maybe I should create one. -- Mark

4 7

RE: Haskell Pangolins
by Dominic Fox 30 Dec '04

30 Dec '04

The use of elem is certainly more concise. But this isn't quite right (Hugs rejects it): > isYes = `elem` ["y", "yes", "Y", "YES"] I think what's meant is: isYes = flip elem ["y", "yes", "Y", "YES"] and agree that isYes = flip elem ["y", "yes"] . (map toLower) is even better. > Of course, the very last "if" could be, > > if isYes playAgain > then play rewrittenNode > else putStr "Goodbye for now." I had it the other way around because of a vague notion about tail-recursion that perhaps doesn't apply here? It's useful to know where "do"s and parentheses are not needed. I agree about records; I thought they would be useful, and ended up not using them. Derek's use of LiftM is new to me, as most things in Haskell are. The @ operator (fullstring@(c:cs)) looks very handy. Thanks to all, Dominic

1 0

Re: dummy variables
by Serge D. Mechveliani 30 Dec '04

30 Dec '04

What I meant: is this reasonable for future Haskell to make a variable _foo equivalent to `_' ? In this case, one can use _foo as a self-commenting dummy variable: let (x, _newEqs, _newVars) = f a (y, _newEqs, newVars ) = f b in x:y:newVars These _foo help to recall the type of f (suppose f is in another file, so that one needs to search and recall). This makes it easier to read/understand the program. ----------------- Serge Mechveliani mechvel(a)botik.ru On Wed, Dec 29, 2004 at 06:17:30PM +0000, Keean Schupke wrote: > Except for GHC, where a variable staring with an '_' will not report a > warning > if it is unused in the body of a funtion: > > let _ = x in y -- no warning > let result = x in y -- waring about result being unused > let _result = x in y -- no warning, but variable can still be used. > > Keean. > > Duncan Coutts wrote: > > >In message <20041229115341.A431(a)botik.ru> "Serge D. Mechveliani" > ><mechvel(a)botik.ru> writes: > > > > > >>Dear Haskellers, dear GHC team, > >> > >>Is a variable `_x' equivalent to `_' > >> > >> > > > >No, '_x' is a perfectly ordinary variable. The only special "dummy variable" (a > >pattern that matches anything but does not bind a varialbe) is '_'. > > > > > > > >>Does really Haskell mean this? It this reasonable? > >>How to set self-commenting dummy variables? > >> > >> > > > >You can use them as dummy variables by never using them in an expression > >context, only in pattern/binding context. As you noted they should be unique > >withing each scope. > > > >Duncan > >_______________________________________________ > >Glasgow-haskell-users mailing list > >Glasgow-haskell-users(a)haskell.org > >http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > > > > >

1 0

Haskell Pangolins
by Derek Elkins 30 Dec '04

30 Dec '04

I've rewritten it closer to the way I would have written it. Most of the changes are minor syntactic changes that you may or may not agree with. Probably the most confusing part of the original code was the declaration of the Node datatype as a (sum of) record(s), then the subsequent ignoring of the fact that it is a record. In my experience, most Haskell programmer's would not (for better or worse) use a record in this case. The comments I've added are with regards to the original source code; compare this version and yours to see the differences. As far as how the code actually works, it seems to be the most natural implementation. -- Pangolins in Haskell -- A simple animal guessing game module Main ( main ) where import Control.Monad ( liftM ) -- declared as record, but not used as record data Node = Guess String | Question String Node Node -- putStrLn s == putStr s >> putStr "\n" ask question = do putStrLn question getLine -- m >>= return == m (one of the monad laws) isYes "y" = True isYes "yes" = True isYes "Y" = True isYes "YES" = True isYes _ = False withArticle fullstring@(c:cs) | c `elem` "aeiou" = "an " ++ fullstring | otherwise = "a" ++ fullstring rewrite (Guess name) = do reply <- ask ("Is it " ++ withArticle name ++ "?") -- superfluous parens if isYes reply -- superfluous parens then do putStr "Computer wins!\n" return (Guess name) else do newName <- ask "What is it, then?" newQuestion <- newQuestion name newName return newQuestion rewrite (Question text ifYes ifNo) = do reply <- ask text if isYes reply then liftM (flip (Question text) ifNo) (rewrite ifYes) else liftM (Question text ifYes) (rewrite ifNo) newQuestion a1 a2 = do -- superfluous parens text <- ask ("Tell me a question that can be used to distinguish between " ++ withArticle a1 ++ " and " ++ withArticle a2 ++ ".") answer <- ask ("What would the answer to your question be if it was " ++ withArticle a1 ++ "?") if isYes answer -- superfluous parens then return (Question text (Guess a1) (Guess a2)) else return (Question text (Guess a2) (Guess a1)) -- superfluous parens duck = Guess "duck" dog = Guess "dog" initialNode = Question "Does it quack?" duck dog -- superfluous 'do' main = play initialNode play :: Node -> IO () play node = do rewrittenNode <- rewrite node playAgain <- ask "Play again?" if not (isYes playAgain) then putStrLn "Goodbye for now." -- superfluous 'do' else play rewrittenNode -- superfluous 'do'

1 0

GUI
by Matthew Roberts 29 Dec '04

29 Dec '04

I know this question is probably going over old ground - so I apologise in advance. However, I want to know if there has been any practical standardisation in the GUI area. Last time I looked at this it seemed some decisions had been made (bind to existing api - wxWindows?). I am waiting for some real standardisation and a mature API before I jump ship from Java for my day-to-day programming. Has there been any progress? Matt

6 6

Named function fields vs. type classes
by John Goerzen 29 Dec '04

29 Dec '04

Hi, I often have a situation where I'm designing specialized components to do a more general task. Examples could include mail folder code (maildir, mbox, etc), configuration file parsing, protocol handlers for URL accesses, logging backends, etc. For some of these, I've used a data object with named fields, each one of them being a function that performs various tasks (open connection to the URL, read data, whatever.) So, I get a standard interface. The advantage of this approach is that I can build a list containing all sorts of different data objects in it. For others, I've used typeclasses, and made the different specialized components a member of the typeclass. This seems to provide a cleaner interface, and one that is more readily extended (maybe I want to support IMAP folders, and support all its searching capabilities too). On the other hand, it's difficult or impossible to make a list of a bunch of different types of things that have nothing in common save being members of the class. Is there any advice on the best way to do these things? Thanks, John

5 5

safe code to run in finalizers: ACIO revisited
by Robert Dockins 29 Dec '04

29 Dec '04

Due to one of the threads on cafe recently, I have been doing some thinking about finalizers. There is this sort of intuitive notion that some things shouldn't be done inside finalizers. For example, no output should be produced, because the output handles may have been finalized already, and finalizers can't be ordered. So, to be safe, the action of a finalizer must commute with every other finalizer (they must be central). And because the finalizers might not be run (compiler can't provide guarantees), their result should not be directly observable, and if the finalizer is not run, the program should still be correct (they must be affine). So a separate ACIO monad for affine central IO actions would be the appropriate context for finalizers. The orignial ACIO proposal was presented in the context of module initalization. http://www.haskell.org//pipermail/haskell-cafe/2004-November/007664.html It strikes me that "module init time" and "finalizer time" are very similar execution contexts. They are 1) outside the normal program flow 2) mostly intended to make the bookeeping work out 3) non-deterministic wrt when/if they will be run 4) if used in the "wrong" ways, they can break program safety. 5) they both are viewed with disfavor for the bad things people can do with them I'm not sure where I am going with this observation, but it seems that if some solution (such as an ACIO monad) could make both of these kinds of action safe, it would probably be worth a second thought.

3 4

Utility functions
by Derek Elkins 29 Dec '04

29 Dec '04

> I find myself writing things like, > > splitListOn :: Eq a => a -> [a] -> [[a]] > > splitListOn delimiter = > unfoldr splitter . (delimiter :) > where > splitter [] = Nothing > splitter xs = Just (span (/= delimiter) (tail xs)) > > This is a sort of intersperse-opposite, in that... > > myId delimiter = concat . intersperse [delimiter] . splitListBy > delimiter > > ...myId foo turns into a sort of id for lists of the correct type. > > With this, and other things, I always have a feeling that it's > probably in the standard library somewhere but I didn't notice - maybe > because it's abstracted out of recognition, just like "sequence" does > Cartesian products for us, but not so that I noticed right away. > > Is there a good place to put these things - little things that feel > like that maybe they're already in the standard library, and maybe > they should be? I'd hate to be unknowingly reinventing the wheel all > the time. I don't see an obviously-appropriate page for these on the > Haskell Wiki, but maybe I missed it, or maybe I should create one. I created a page a short while back that I haven't linked in anywhere (so it's currently an orphan page modulo being in CategoryCodeSnippet) called http://www.haskell.org/hawiki/CodeOnTheWiki that links to various parts of the wiki containing good chunks of code. The first three links seem most appropriate. A page about Haskell's "hidden" library functions may be useful. There are many functions that seem to be reimplemented that are, as you well put it, "abstracted out of recognition," to varying degrees and often reimplemented. For example, another is the mplus instance of Maybe which is useful but has no (other) equivalent library function and is often reimplemented (e.g. darcs' or_maybe http://www.haskell.org/pipermail/haskell-cafe/2003-December/005617.html)

2 1

GHC for .NET?
by John Goerzen 28 Dec '04

28 Dec '04

Over at http://www.gotdotnet.com/community/resources/Default.aspx?ResourceTypeDropD…, I read: "The GHC compiler for .NET is currently under development at Microsoft Research, Cambridge". Hmm. That location sounds familiar :-) Does anyone know if this is actually going to happen? Or if there's any code anywhere, however experimental, to try? As a side note, the dotgnu project includes a C-to-CLR compiler, though it has trouble passing the autoconf stuff in ghc (and I may not have the expertise to fix it; it is crashing on the alignment tests). I figure that if I can get portable enough C code out of ghc, and a runtime compiled to CLR, it should be possible to compile Haskell to .NET that way. Anyway, it's just me off on a tangent again. Thanks, John

1 0

Ignorant begginer question
by Maurício 24 Dec '04

24 Dec '04

Guys, What is wrong with this code? ************** import Complex roots :: (Complex, Complex, Complex) -> (Complex, Complex); roots (a,b,c) = (x1,x2) where { x1 = (b*b + (sqrt_delta))/(2*a); x2 = (b*b - (sqrt_delta))/(2*a); sqrt_delta = sqrt 4*a*c} ************** I load it into GHCi and get: ************** Kind error: `Complex' is not applied to enough type arguments In the type: (Complex, Complex, Complex) -> (Complex, Complex) While checking the type signature for `roots' Failed, modules loaded: none. ************** Thanks, Maurício

6 7

Problem with type signature in local function
by Christian Hofer 24 Dec '04

24 Dec '04

Hi, in order to understand the reason for strange compiler error messages, I often find it convenient to add type signatures to every function. But sometimes this seems to be impossible when using type variables. I try to give a very easy example: add :: Num a => a -> a -> a add n1 n2 = addToN1 n2 where addToN1 :: Num a => a -> a addToN1 number = n1 + number ghc says "Inferred type is less polymorphic than expected", and justly so, because the type variable "a" in addToN1 must of course be the same as in add. Is there a way to specify this? Regards, Chris

3 3

ANN: MissingH 0.8.0 ("Festive Lambda")
by John Goerzen 24 Dec '04

24 Dec '04

MissingH 0.8.0 -- the "Festive Lambda" release New feature summary: * Virtualized I/O system Use familiar functions to work on not just Handles but all sorts of other types, including in-memory buffers. (HVIO module) * Virtualized filesystem Extends the virtual I/O concept to the filesystem, supporting entire virtual filesystems, and operations such as renames, stat(), etc. on them. (HVFS module) * Network server infrastructure Makes it easy to write a network server in Haskell. Functional interface permits easy adding of things such as multithreading, logging, etc. Functions to do these things are provided. Patterned loosely after Python's SocketServer system. (SocketServer module) * Full, pure-Haskell FTP server Provides a full FTP server over a real or virtual (HVFS) filesystem. It's a SocketServer server, so you get multithreading for free. Supports passive eand port modes. See below for an example: * Many path/file manipulation functions imported from Volker's HsShellScript. * Existing MissingH.IO functions updated to be HVIO compatible. MissingH 0.8.0 is available from: gopher://gopher.quux.org/1/devel/missingh or http://gopher.quux.org:70/devel/missingh ------------------------------------------------------------ Here is an example of a fully self-contained FTP server that serves up the local filesystem in read-only mode: import MissingH.Network.FTP.Server import MissingH.Network.SocketServer import MissingH.Logging.Logger import MissingH.IO.HVFS import MissingH.IO.HVFS.Combinators main = do updateGlobalLogger "" (setLevel DEBUG) updateGlobalLogger "MissingH.Network.FTP.Server" (setLevel DEBUG) let opts = (simpleTCPOptions 12345) {reuse = True} serveTCPforever opts $ threadedHandler $ loggingHandler "" INFO $ handleHandler $ anonFtpHandler (HVFSReadOnly SystemFS)

1 1

Re: [Haskell-cafe] Why no IO transformer monad?
by Keean Schupke 20 Dec '04

20 Dec '04

Udo Stenzel wrote: >Keean Schupke <k.schupke(a)imperial.ac.uk> schrieb am 20.12.04 14:20:54: > > >>Perhaps you would care to explain this then? >> >> > >Damn, I read a pair parens in there where there was none. The result still >stands as is: no transformer version of IO is possible. > > But is that beacuse it really isn't (theoretically) possible, or just not possible to write in Haskell (because it would involve new primitives)? Surely if IO is (ST RealWorld a) then (StateT RealWorld m a) is more or less the right thing? Keean.

4 4

Re: [Haskell-cafe] Why no IO transformer monad?
by Udo Stenzel 20 Dec '04

20 Dec '04

Keean Schupke <k.schupke(a)imperial.ac.uk> schrieb am 20.12.04 15:17:14: > Surely if IO is (ST RealWorld a) then (StateT RealWorld m a) is more or > less the right thing? Not at all, since ST and StateT are completely unrelated. What signature would runSTT have? Either it exposed the contained state (the RealWorld!): runSTT :: Monad m => STT s m a -> m (a,s) or it drops the state: runSTT :: Monad m => STT s m a -> m a The former is a bad idea, the latter is useless as it can be implemented by running the ordinary runST inside m. Note that runStateT uses the former signature and would expose RealWorld, if it could be instantiated at RealWorld. Udo. __________________________________________________________ Mit WEB.DE FreePhone mit hoechster Qualitaet ab 0 Ct./Min. weltweit telefonieren! http://freephone.web.de/?mc=021201

2 1

Re: [Haskell-cafe] Why no IO transformer monad?
by Keean Schupke 20 Dec '04

20 Dec '04

Perhaps you would care to explain this then? class Runnable m n where run :: m -> n class (Monad m,Monad (t m)) => MonadT t m where up :: m a -> t m a down :: t m a -> m a instance (Monad m,MonadT t m,Monad (t m)) => Runnable (t m a) (m a) where run = down Or perhaps look at the type of the state transformer monad: newtype StateT st m a = ST { runST :: st -> m (st,a) } To me it is quite clear that the return type runST returns "m (st,a)" where m is the _base_ monad so lifting IO through the state-transformer gives: StateT st IO a and applying runST to this type gives: IO (st a)... Keean. Udo Stenzel wrote: >Keean Schupke <k.schupke(a)imperial.ac.uk> schrieb am 20.12.04 12:13:08: > > >>I thought you would get the following if you have a transformer 'M': >> >> runM :: M IO a -> IO a >> >> > >That's what I thought, too. But it's the other way 'round. >Well, I can't comment on _why_ it's so counter-intuitive, but I'm pretty >sure, the outermost transformer appears innermost in the final type. >It all makes sense somehow, you just have to remember that >transformer types are somehow written backwards. > > >Udo. >__________________________________________________________ >Mit WEB.DE FreePhone mit hoechster Qualitaet ab 0 Ct./Min. >weltweit telefonieren! http://freephone.web.de/?mc=021201 > > >

1 0

Re: [Haskell-cafe] Why no IO transformer monad?
by Udo Stenzel 20 Dec '04

20 Dec '04

Keean Schupke <k.schupke(a)imperial.ac.uk> schrieb am 20.12.04 10:25:36: > > What about: > > runIOT :: Monad m => IOT m a -> IO (m a) I have a gut feeling that this is unimplementable. However, IO (m a) is what you get using the transformer version of m over IO. Udo. __________________________________________________________ Mit WEB.DE FreePhone mit hoechster Qualitaet ab 0 Ct./Min. weltweit telefonieren! http://freephone.web.de/?mc=021201

2 1

Re: [Haskell-cafe] Why no IO transformer monad?
by Udo Stenzel 20 Dec '04

20 Dec '04

Henning Sato von Rosen <henning.von.rosen(a)gmail.com> schrieb am 18.12.04 18:31:11: > For each basic monad there seems to be a corresponding transformer, > e.g. 'StateT' for 'State' and so on. To be useful every transformer has a "run" method of some kind. For a hypothetical IO transformer it would look like runIOT :: Monad m => IOT m a -> m a ...which is basically the same as unsafePerformIO and defeats the purpose of having an IO Monad at all. If you want to retain the IO-type in the result, then you don't need IOT at all, layering any transformer on top of IO is exactly what's needed. Udo. __________________________________________________________ Mit WEB.DE FreePhone mit hoechster Qualitaet ab 0 Ct./Min. weltweit telefonieren! http://freephone.web.de/?mc=021201

2 1

FFI woes!
by Sebastian Sylvan 20 Dec '04

20 Dec '04

Hi! I've been trying to use the C library FMOD in Haskell for about an hour now. The first test was the simple FSOUND_Init(int,int,uint) function which I got working by doing the following: foreign import ccall "fmod.h FSOUND_Init" fsound_Init :: CInt -> CInt -> CUInt -> IO CChar Which appeared to work just fine (the call went through, and I got sensible return values). Then I wanted to play some music so I tried to bring in the function FMUSIC_LoadSong which has the following C prototype (copy-pasted from the API): FMUSIC_MODULE * F_API FMUSIC_LoadSong( const char *name ); By doing this in Haskell: data MusicModule = MusicModule foreign import ccall "fmod.h FMUSIC_LoadSong" fmusic_LoadSong :: CString -> IO ForeignPtr MusicModule) I assume that this is how the ForeignPtr is meant to be used (with a dummy data type). Now if I compile this (under windows) with: ghc -fglasgow-exts --make FMODTest.hs -o test.exe -Llib -Iincludes -lfmod I get the following error: ./FMOD.hs:9: Unacceptable result type in foreign declaration: IO (ForeignPtr MusicModule) When checking declaration: foreign import ccall safe "static fmod.h &FMUSIC_LoadSong" fmusic_LoadSo ng :: Ptr CChar -> IO (ForeignPtr MusicModule) That's not a very helpful error message! Any ideas? /S -- Sebastian Sylvan +46(0)736-818655 UIN: 44640862

7 32

Why no IO transformer monad?
by Henning Sato von Rosen 20 Dec '04

20 Dec '04

Hi all! For each basic monad there seems to be a corresponding transformer, e.g. 'StateT' for 'State' and so on. I guess the reason lies in the fact that if there were an IO Transformer monad, one might run it and get the 'Universe' out of the IO monad. But, I am working on understanding IO magic, on a much more concrete level, so I am am looking for a really good explanation of the above. (And the IO monad in general.) Thanks! /Henning

3 2

code example
by armin langhofer 20 Dec '04

20 Dec '04

hi all i'm going to write an exam in haskell tomorrow (monday) and i therefore i have to understand what this does: repeat_until::(a->Bool)->(a->a)->a->a repeat_until crit change x |crit x = x --zufrieden |otherwise = repeat_until crit change (change x) --weiter fix::(Float->Float)->Float->Float fix f = repeat_until pred f where pred x = (abs(f x -x) <= 0.01) square::Float->Float square x = x*x this is the use: ================ Prelude> :l e:\haskell\burstall.hs Main> fix square 0.01 0.01 (56 reductions, 80 cells) Main> fix square 0.1 0.01 (92 reductions, 128 cells) Main> fix square 1 1.0 (54 reductions, 77 cells) Main> Main> it seems that i dont have a clue how it works. maybe some of you could explain it to me that i can pass the exam tomorrow, thanx and best regards, armin. -- armin langhofer snail: fischer von erlachstr. 29 snail: a-5020 salzburg phone: +43 699 11648495 email: office(a)langhofer.at gnupg: http://langhofer.at/pubkey.txt

2 1

Seeking comments on this IO proposal
by John Goerzen 17 Dec '04

17 Dec '04

Hello, One of my favorite features from Python is its notion of "file-like objects". For those of you unfamiliar with Python, here's a quick backgrounder: anything can present a file-like interface. It could be a file, socket, an interface to a gzip/gunzip processor, character set codecs, in-memory buffers, etc. File-like objects are used in Python for everything from gzip files to certain network data. The memory buffers are great for unit testing. As I've started working on some gzip stuff in Haskell, I've developed a prototype for a similar concept in Haskell. One of my main goals is to keep is as compatible with standard Haskell as I possibly can. To that end, a Handle is still acceptable as a parameter to any of the functions I'm proposing. My proposal is here: http://www.complete.org/~jgoerzen/t/MissingH.IO.HVIO.html I'm aware that others have been working on IO proposals; specifically, Simon Marlow's here: http://www.haskell.org/~simonmar/io/System.IO.html I'm especially interested in their feedback on my proposal, and I'm wondering: * Do you think HVIO has merit? * Would I be better advised to try to implement some existing ideas instead? * Are there any other implementations of these things that are ready to use? (With code) One note: I'm trying to keep the interface and behavior as identical to the normal System.IO interface as possible. So I'm still using Strings, raising the same exceptions, etc. In fact, the Handle instance of these classes looks like: instance Handle HVIOReader vGetChar = hGetChar ... -- John

6 7

Question regarding theis mailing list and Google Groups
by Arjun Guha 16 Dec '04

16 Dec '04

Does anybody out there use Google Groups Beta to post to the `fa.haskell' group? I am directly subscribed to the email list, however I was trying some new things and it seemed like `fa.haskell' was vaguely related to the Haskell Café list. However, my post has not shown up on Haskell Café. Does anyone here know what's going on? I posted the following code to the `Haskell problem please help' thread: > rotations:: [a] -> [[a]] > rotations xs = rotate (xs ++ xs) len where > len = length xs > rotate _ 0 = [] > rotate ys n = (take len ys):(rotate (tail ys) (n - 1)) Did anyone receive this? -Arjun

1 0

Re: Haskell problem please help
by Christian Maeder 16 Dec '04

16 Dec '04

N.B. if you want a faster answer such questions are best posted to haskell-cafe(a)haskell.org My answer: I asume that your function all_rotations somehow needs to be called recursively for the rest of the input list xs. Cheers Christian imranazad wrote: > Hi, > > im not very good with haskell, i barely know the basics, my coursework > requires me to genereate a vigenere square....... > well anyway at the moment im trying to define a functin all_rotations > which for any list returns the list of all its rotations, so far i've made > an attempt but it only rotates once....any ideas? i dont want the complete > solution just help thats all, much appreciated. > > all_rotations :: [a] -> [[a]] > all_rotations [] = [] > all_rotations (x:xs) = reverse (x:xs) : [] >

4 3

Re: [Haskell-cafe] FFI woes!
by Udo Stenzel 16 Dec '04

16 Dec '04

Robert Dockins <robdockins(a)fastmail.fm> schrieb am 16.12.04 14:56:49: > This is exactly the guarantee you _don't_ have. The only guarantee you > have is that it _won't_ be run if the Ptr _is_ being referenced. >From the GHC library documentation: newForeignPtr :: FinalizerPtr a -> Ptr a -> IO (ForeignPtr a) [...] The only guarantee is that the finaliser runs before the program terminates. So it seems, finalization *is* guaranteed, just not promptness of finalization. > My concern is that this approach is a little too non-deterministic. > Because playing sound involves HW resources, [...] If I understand correctly, the OP is dealing with library resources (mainly memory) while the library is managing the hardware ressources. Udo. __________________________________________________________ Mit WEB.DE FreePhone mit hoechster Qualitaet ab 0 Ct./Min. weltweit telefonieren! http://freephone.web.de/?mc=021201

3 2

Parse text difficulty
by Douglas Bromley 15 Dec '04

15 Dec '04

Hi Everyone My first post to the mailing list is a cry for help. Apologies for that. I've seen an example of how this is done in the archives but I'm afraid I'm a bit more behind than the person who seemed to understand the answer so if someone could help me?? The problem is this: I've show(n) a particular data type and it shows up as: [([2,6],"British"),([1],"Charles"),([1,8],"Clarke"),([2,6],"Council"),([2],"Edinburgh"),([1],"Education"),([4],"Increasingly")] What I want to do is format that nicely into a table. The best way of doing (I thought) was to: Remove the first "[(" and final ")]" Then replace "),(" with a newline(\n) Which would give: [2,6],"British" [1],"Charles" [1,8],"Clarke" [2,6],"Council" ......etc I get the impression I may find it easier adding newlines earlier on in my program but I thought this may be the easiest way. I'll include all the code for the whole program in case it helps to see where I'm coming from. It takes an input file of text and outputs an index to an output file. My soul question and drive is to lay out the index in a nicely formatted fashion. Any help would be very much appreciated. module TextProc where -- import Prelude hiding (Word) import IO import List type Word = String -- define types type Line = String type Doc = String start :: IO () start = do putStrLn "******** Enter Choice *********" putStrLn "1. Enter Input and Output files" putStrLn "2. Exit" putStrLn "*******************************" choice <- getLine if (choice == "1") then ( do putStrLn "Type input file name:" fileNameI <- getLine text <- readFile fileNameI putStrLn "Type output file name:" fileNameO <- getLine writeFile fileNameO (makeIndex text) ) else ( do return() ) makeIndex :: Doc -> Doc -- changed so output can be written to file makeIndex = show . shorten . -- [([Int], Word)] -> [([Int], Word)] amalgamate . -- [([Int], Word)] -> [([Int], Word)] makeLists . -- [(Int, Word)] -> [([Int], Word)] sortLs . -- [(Int, Word)] -> [(Int, Word)] allNumWords . -- [(Int, Line)] -> [(Int, Word)] numLines . -- [Line] -> [(Int, Line)] splitUp -- Doc -> [Line] splitUp :: Doc -> [Line] splitUp [] = [] splitUp ls = takeWhile (/='\n') ls : -- first line (splitUp . -- split up other line dropWhile (=='\n') . -- delete 1st newLine(s) dropWhile (/='\n')) ls -- other lines numLines :: [Line] -> [(Int, Line)] numLines lines -- list of pairs of = zip [1 .. length lines] lines -- line no. & line splitWords :: Line -> [Word] -- split up lines into words splitWords [] = [] splitWords line = takeWhile isLetter line : -- first word in line (splitWords . -- split other words dropWhile (not.isLetter) . -- delete separators dropWhile isLetter) line -- other words where isLetter ch = ('a' <= ch) && (ch <= 'z') || ('A' <= ch) && (ch <= 'Z') || ('-' == ch) numWords :: (Int, Line) -> [(Int, Word)] -- attach line no. to each word numWords (number, line) = map addLineNum (splitWords line) -- all line pairs where addLineNum word = (number, word) -- a pair allNumWords :: [(Int, Line)] -> [(Int, Word)] allNumWords = concat . map numWords -- doc pairs sortLs :: [(Int, Word)] -> [(Int, Word)] sortLs [ ] = [ ] sortLs (a:x) = sortLs [b | b <- x, compare b a] -- sort 1st half ++ [a] ++ -- 1st in middle sortLs [b | b <- x, compare a b] -- sort 2nd half where compare (n1, w1) (n2, w2) = (w1 < w2) -- 1st word less || (w1 == w2 && n1 < n2) -- check no. makeLists :: [(Int, Word)] -> [([Int], Word)] makeLists = map mk -- all pairs where mk (num, word) = ([num], word) -- list of single no. amalgamate :: [([Int], Word)] -> [([Int], Word)] amalgamate [ ] = [ ] amalgamate [a] = [a] amalgamate ((n1, w1) : (n2, w2) : rest) -- pairs of pairs | w1 /= w2 = (n1, w1) : amalgamate ((n2, w2) : rest) | otherwise = amalgamate ((n1 ++ n2, w1) : rest) -- if words are same grow list of numbers shorten :: [([Int], Word)] -> [([Int], Word)] shorten = filter long -- keep pairs >4 where long (num, word) = length word > 4 -- check word >4

17 25

convergence of functions of Complex variables
by William Lee Irwin III 15 Dec '04

15 Dec '04

This does not work as expected on Complex numbers due to some odd typechecking hassles apparently associated with abs. How do I get this to typecheck for both real (e.g. Double) and Complex arguments? \begin{code} module Jacobi (sn, cn, dn, sd, cd, nd, cs, ds, ns, sc, dc, nc) where scd x k | abs k < 1e-14 = (sin x, cos x, 1) | otherwise = ((1+m)*s/(1+m*s^2), c*d/(1+m*s^2), (1 - m*s^2)/(1+m*s^2)) where k' = cos $ asin k m = -tanh(log(k')/2) (s, c, d) = scd (x/(1+m)) m sn x k = let (s,_,_) = scd x k in s cn x k = let (_,c,_) = scd x k in c dn x k = let (_,_,d) = scd x k in d sd x k = (sn x k)/(dn x k) cd x k = (cn x k)/(dn x k) nd x k = 1/(dn x k) cs x k = (cn x k)/(sn x k) ds x k = (dn x k)/(sn x k) ns x k = 1/(sn x k) sc x k = (sn x k)/(cn x k) dc x k = (dn x k)/(cn x k) nc x k = 1/(cn x k) \end{code}

4 4

Re: [Haskell-cafe] The difference between ($) and application
by Jon Cast 15 Dec '04

15 Dec '04

Derek Elkins <ddarius(a)hotpop.com> wrote: > Personally, I would mind ($) being magical. One of the nice things > about Haskell is there is practically no magic. The last thing I want > is Haskerl (http://www.dcs.gla.ac.uk/~partain/haskerl.html) runST > simply had a rank-2 type that is not expressible in Haskell 98, it > seems getting ($) to "work" would be qualitatively different. No. All that is needed for ($) to work is impredicativity (or, more precisely, for the foralls in ($)'s type to be impredicative). That is something that could easily be implemented in a compiler. I'm not clear on why it hasn't been, but the type system, in relation to an arbitrary-rank predicative system, is no more of a jump that higher-rank types were. Jonathan Cast

2 1

Monads vs. qualified types
by William Lee Irwin III 15 Dec '04

15 Dec '04

To my chagrin, I discovered that the following code was not accepted while attempting to monadify a small interpreter for a language used for calculations in permutation representations of groups. One of the critical notions here is of closure under composition, e.g. a transcript of a command to generate a set via distinguished elements is: 20> <(1 2),(1 2 3)> {(), (1 2), (1 2 3), (1 3), (1 3 2), (2 3)} and augmenting the semantics with group-theoretic joins and intersections and the like look verbose and redundant, with monadic properties to exploit for brevity readily apparent. \begin{code} data Eq t => Set t = Set [t] deriving (Ord, Read, Show) instance Eq t => Eq (Set t) where (Set xs) == (Set ys) = all (`elem` ys) xs && all (`elem` xs) ys instance Functor Set where fmap f (Set xs) = Set . nub $ map f xs instance Monad Set where return = Set . (:[]) (Set xs) >>= f = Set $ foldr union [] [ys | Set ys <- map f xs] \end{code} This, of course, presents me immediately with some nightmare where transitive closure semantics and the like are unimplementable as direct data structure properties within any monad, as constraints on the argument types of the monadic constructor are (for the moment) verboten. Is anyone looking into dealing with this so that I can do this? If not, where (which files) do I hack it into ghc? Are there already patches? -- wli

1 0

The difference between ($) and application
by Derek Elkins 15 Dec '04

15 Dec '04

> On Mon, Dec 13, 2004 at 07:49:00PM -0800, oleg at pobox.com wrote: > > The operator ($) is often considered an application operator of a > > lower precedence. Modulo precedence, there seem to be no difference > > between ($) and `the white space', and so one can quickly get used > > to treat these operators as being semantically the same. However, > > they are not the same in all circumstances. I'd like to observe an > > important case where replacing the application with ($) in a > > fully-parenthesized expression can lead to a type error. > > I think this post should go under the heading "($) considered > harmful". I've been bitten by this, and I never use ($) anymore in > place of parentheses because it's too tempting to think of it as > syntax. (Of course, it's still useful, by itself or in a slice, as a > higher-order operator.) > > Andrew I find this position ridiculous. I don't recall anyone ever posting a message about this (though I'd be far from surprised if someone did). It seems that the people who decide they need higher-rank types are capable of handling type errors involving them, and they certainly don't confuse ($) for syntax. Unless there's a realistic scenario where one suddenly decides one needs some higher-rank types and has to remove a bunch of uses of ($) but otherwise make no changes, I don't see any reason not to use ($) when you can (if you like) and not when you can't. If you ever make a mistake one way the type checker will tell you.

3 2

Re: [Haskell-cafe] local loops
by Jon Cast 14 Dec '04

14 Dec '04

Per Larsson <per(a)L4i.se> wrote: > I often use local loops in monadic code, e.g. > > main = do > ... > let loop = do > ... > if cond then loop else return () > loop > > It seems that I can encode this idiom slightly more concise with the 'fix' > operator (from Control.Monad.Fix), i.e. > > main = do > ... > fix (\loop -> do > ... > if ...) > > But is it really semantically equivalent? Is it as efficient? > > Per It is semantically equivalent. I don't know if it is as efficient; looking at the source code, I would expect GHC to inline fix anywhere it occurs, which yields your original version. Jonathan Cast

1 0

The difference between ($) and application
by Derek Elkins 14 Dec '04

14 Dec '04

> Derek Elkins wrote: > >Andrew Pimlott wrote: > >>I think this post should go under the heading "($) considered > >>harmful". I've been bitten by this, and I never use ($) anymore in > >>place of parentheses because it's too tempting to think of it as > >>syntax. > > > >I find this position ridiculous. [...] If you ever make a mistake > >one way the type checker will tell you. > > For what it's worth, this is not true in the presence of implicit > parameters: > > f :: ((?p :: Int) => Int) -> Int > f g = let ?p = 1 in g > > x,y :: Int > x = let ?p = 2 in (f ?p) ==> 1 > y = let ?p = 2 in (f $ ?p) ==> 2 > > I wouldn't mind ($) being magical, along the lines of the magical > runST in a rank-1 type system. It would be nice to be able to use it > in patterns too. > > -- Ben Moral of the story, and if I'm not mistaken, in your opinion, is not to use implicit parameters (as currently formulated). I.e. the consensus seems to be that this is implicit parameters' fault not ($)'s. Personally, I would mind ($) being magical. One of the nice things about Haskell is there is practically no magic. The last thing I want is Haskerl (http://www.dcs.gla.ac.uk/~partain/haskerl.html) runST simply had a rank-2 type that is not expressible in Haskell 98, it seems getting ($) to "work" would be qualitatively different.

1 0