- Haskell-Cafe - Haskell.org

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 29 Dec '04

29 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 25 Dec '04

25 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 21 Dec '04

21 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