- Haskell-Cafe - Haskell.org

2 modules in one file
by Maurício 05 Sep '08

05 Sep '08

Hi, Is it allowed to write two different modules in a single file? Something like: module Mod1 (...) where { ... } module Mod2 (...) where { import Mod1; ... } I tried, and got an error, but would like to confirm that there's no way to do that. Thanks, Maurício

7 10

Re: [Haskell-cafe] Reducing code for efficient ShowS
by wren ng thornton 05 Sep '08

05 Sep '08

Sean Leather wrote: >> Why not use the dlist library: >> >> http://hackage.haskell.org/cgi-bin/hackage-scripts/package/dlist >> >> With something like (untested code): >> >> > xs +++ ys = shows xs `append` shows ys >> > x .++ ys = showChar x `cons` shows ys >> > xs ++. y = shows xs `snoc` showChar y >> > >> > ext3' = toList $ '(' .++ n +++ ' ' .++ s ++. ')' >> > > I think you're missing the fromList parts among other things. Ah yes, dlist uses a newtype instead of an alias so `shows` isn't enough. There's also the question of where exactly to hide the (Show a => a -> DList Char) conversions if you want to be more succinct than the (++) route. > That's an interesting idea. It appears to use the same idea as ShowS, but > more generally with lists and not just strings. The difference-list approach to solving the appending problem is classic. There's a variant for unification-based logic languages as well. Both are functional takes on the imperative approach of keeping a tail pointer. Dons just took the time to package it up for us all :) > I think there's an added benefit to not having to remember the the type of > the value being appended. It's one of the more convenient things about many > dynamically typed languages. So, I would still vote for the class-based > method, so that I can use (.+.) for both Char and everything else. Sure. If you're planning on releasing the code, I'd suggest a different spelling of (.+.) though. The (.X.) pattern for a family of operators is pretty common, so it's good to avoid it for modules that want to be used in combination with many others. YMMV and all that. -- Live well, ~wren

2 1

Re: [Haskell-cafe] Reducing code for efficient ShowS
by Sean Leather 05 Sep '08

05 Sep '08

> Why not use the dlist library: > > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/dlist > > With something like (untested code): > > > xs +++ ys = shows xs `append` shows ys > > x .++ ys = showChar x `cons` shows ys > > xs ++. y = shows xs `snoc` showChar y > > > > ext3' = toList $ '(' .++ n +++ ' ' .++ s ++. ')' > I think you're missing the fromList parts among other things. That's an interesting idea. It appears to use the same idea as ShowS, but more generally with lists and not just strings. I think there's an added benefit to not having to remember the the type of the value being appended. It's one of the more convenient things about many dynamically typed languages. So, I would still vote for the class-based method, so that I can use (.+.) for both Char and everything else. Sean

1 0

Reducing code for efficient ShowS
by Sean Leather 05 Sep '08

05 Sep '08

It happens very often that I want to convert a number of values to strings and concatenate those strings into one. No surprise there, of course. Well, I'd prefer to do it efficiently and with as little code as necessary. > {-# LANGUAGE TypeSynonymInstances #-} > module ShowsDemo where Let's say I want to generate the string "(42 abc)" starting with a number and a string stored in variables. > n = 42 :: Int > s = "abc" What are my options? There's the obvious approach that's described in every tutorial, book, and research paper (for didactic purposes, of course). > ex1 = "(" ++ show n ++ " " ++ s ++ ")" It's pretty concise, but it's horribly inefficient due to the use of (++). Then, there's the ShowS approach. > ex2 = showChar '(' . shows n . showChar ' ' . showString s . showChar ')' $ "" This is more efficient, but now the code has bloated up a lot. Why can't I have my cake and eat it, too? I want to write with as little code as |ex1| (or less if possible), and I want it to be as efficient as |ex2|. I propose this example as an improvement. > ex3 = '(' .+. n .+. ' ' .+. s .$. ')' It uses a class I'm calling |Shows|. The class has one method that simply converts a value to the type |ShowS|, where |ShowS| is a type synonym for |String -> String| and is defined in the Prelude. > class Shows a where > toShows :: a -> ShowS Notice the lack of context involving the |Show| class. That's important, because it allows us to create more instances than we could if we were restricted by |(Show a) => ...|, esp. the |ShowS| instance below. The instances for types are all very simple. Most will appear like the instance for |Int|. > instance Shows Int where > toShows = shows Since we don't have |Show| in the class context above, we can't make this a default method. We need a few special instances for |Char| and |String| to make these types convenient to use in the expected way. > instance Shows Char where > toShows = showChar > instance Shows String where > toShows = showString We also need an instance for |ShowS| in order to facilitate concatenation. > instance Shows ShowS where > toShows = id Now, we define a few operators that use |toShows| and make our lives easier and our code more concise. The |(.+.)| replaces list appending, |(++)|, in |ex1| and function composition, |.|, in |ex2|. > infixl 5 .+. > (.+.) :: (Shows a, Shows b) => a -> b -> ShowS > a .+. b = toShows a . toShows b The |(.$.)| replaces the need for |($)| in |ex2|. > infixl 4 .$. > (.$.) :: (Shows a, Shows b) => a -> b -> String > a .$. b = (a .+. b) "" I would find something like this very useful. I'm guessing the idea can be applied to |ByteString| as well. Does it exist in some other form? Sean

2 1

Re: [Haskell-cafe] Consequences of implementing a library in Haskell for C consumption?
by Justin Bailey 05 Sep '08

05 Sep '08

On Thu, Sep 4, 2008 at 2:52 PM, Philippa Cowderoy <flippa(a)flippac.org> wrote: > Would writing Haskell to generate the C via Language.C be an option? > Effectively you'd be using Haskell as a typeful macro system. Interesting idea, and I've done similar things with haskelldb (generating SQL queries). Looking at the package, I think would be pretty painful though. It seems I'd have to build the AST by hand, and it doesn't seem to incorporate any type information in the AST items. In haskelldb, every expression carries its type around in a phantom type, which protects you from trying to compare a bool and a string, for intstance. I don't see anything similar in Language.C. I may be mistaken though! Justin

4 3

Is it usual to read a Maybe (IORef a) ?
by minh thu 05 Sep '08

05 Sep '08

Hi, I'd like to write a data structure to be used inside the IO monad. The structure has some handles of type Maybe (IORef a), i.e. IORef are pointers and the Maybe is like null pointers. So I came up with the following functions : readHandle :: Maybe (IORef a) -> IO (Maybe a) readField :: (a -> b) -> Maybe (IORef a) -> IO (Maybe b) readHandle Nothing = do return Nothing readHandle (Just r) = do v <- readIORef r return $ Just v readField f h = do m <- readHandle h return $ fmap f m Is it something usual ? Are there any related functions in the standard libraries ? Thanks, Thu

10 13

Re: [Haskell-cafe] Re: [Haskell] Top Level <-
by Ganesh Sittampalam 05 Sep '08

05 Sep '08

On Sun, 31 Aug 2008, Adrian Hey wrote: > Ganesh Sittampalam wrote: >> On Sun, 31 Aug 2008, Adrian Hey wrote: >> >>> Thanks for taking the time to do this Dan. I think the safety requirement >>> has been met, but I think it fails on the improved API. The main complaint >>> would be what I see as loss of modularity, in that somehow what should be >>> a small irrelevant detail of the implementation of some obscure module >>> somewhere has propogated it's way all the way upto main. >> >> That's the key point, as I see it - they aren't "irrelevant details of the >> implementation", they are requirements the implementation places on its >> context in order for that implementation to be correct. So they should be >> communicated appropriately. > > Eh? Please illustrate your point with Data.Unique. What requirements > does it place on it's context? (whatever that might mean :-) It requires that its context initialises it precisely once. Data.Unique is actually a poor example, as it is actually fine to initialise it multiple times as long as the resulting Unique values aren't treated as coming from the same datatype. But equally it can be implemented with IORefs, so it's not a good advert for the need for global variables. > The real irony of your remark is that making APIs this robust is > practically impossible *without* using global variables, and you're > now saying that because they've done this work to eliminate these > constraints they now have to be held to account for this with > an absurd API. I think there are two cases to consider here. A Data.Unique style library, which requires genuinely *internal* state, and which is agnostic to having multiple copies of itself loaded simultaneously. In that case, there is no requirement for a process-level scope for <-, just that each instance of the library is only initialised once - the RTS can do this, as can any dynamic loader. The other is some library that really cannot be safely loaded multiple times, because it depends on some lower-level shared resource. Such a library simply cannot be made safe without cooperation from the thing that controls that shared resource, because you cannot prevent a second copy of it being loaded by something you have no control over. If the <- proposal were only about supporting the first of these applications, I would have far fewer objections to it. But it would have nothing to do with process-level scope, then. Ganesh

5 11

Categorical language
by Maurício 05 Sep '08

05 Sep '08

Hi, I’ve been thinking about this and would like your opinion: what could be a “categorical language”? Something like a language where categories and functors are first class; does that makes sense at all? (Sorry if this is insane, I'm a begginer in categories, I've read just the first chapter of Mac Lane's book.) Thanks, Maurício

4 3

Linux version of ghc-6.8.3 won't intall or run for me: "Floating point exception".
by Alan Mackenzie 05 Sep '08

05 Sep '08

Hi, Haskell! I've downloaded the ghc-6.8.3-i386-unknown-linux.tar.bz2 tarball, which I expected to work on my GNU/Linux box (1.2 GHz Athlon, Debian Sarge). I'm new at this game, though I'm thoroughly experienced with (and bear deep battle scars from) GNU software in general. ./configure fails with "checking for path to top of build tree... configure: error: cannot determine current directory". This has been reported before in this list, but I don't think anybody ever explained the fault. Further delving finds that the following statement in the configure script triggers it: hardtop=`utils/pwd/pwd forwardslash` . utils/pwd/pwd, no matter how I call it, always crashes with "Floating point exception". Surely real numbers aren't involved in determining a configuration - probably some floating point library or other is missing from my system. What is utils/pwd/pwd? What's its purpose? It's 460kB large (compared with 14kb for /bin/pwd). Is it a haskell implementation of Unix's pwd, primarily intented for non-unixy OSs? configure is supposed to ascertain my machine's config, so it's particularly disappointing that it crashes because my config isn't what it expects. Should I report this as a bug? ######################################################################### Anyhow, I hacked the configure script by replacing the above line by a hard-coded value, thusly: hardtop=/home/acm/haskell/ghc-6.8.3 , and the configure script finished. ;-) So I did "make install", and the turgid messages rolled up my screen until it crashed, the last few lines being: nstall/lib/ghc-6.8.3"' -DPKG_DATADIR='"/home/acm/haskell/ghc-install/share/ghc-6.8.3"' package.conf.in \ | grep -v '^#pragma GCC' \ | sed -e 's/""//g' -e 's/:[ ]*,/: /g' \ | /home/acm/haskell/ghc-6.8.3/utils/ghc-pkg/ghc-pkg.bin --global-conf /home/acm/haskell/ghc-install/lib/ghc-6.8.3/package.conf update - --force make[1]: *** [install] Error 136 make[1]: Leaving directory `/home/acm/haskell/ghc-6.8.3/rts' make: *** [install] Error 2 Ah yes! Error 136. ;-) Don't we just love GNU bread and butter software? It's not documented on the install man page either - or the info page. Neither is Error 8. Hey, you've all been through this too: enthusiasm -> 0 as t -> infinity. :-( ######################################################################### So, I thought, who needs to install? It's a binary package, so somewhere there's going to be a top-level callable program, probably called something like "ghc". Hey, yes, compile/Stage3/ghc-6.8.3. Guess what: "Floating point exception". :-( I hate binary packages - I utterly loathe them. They never work. At least they never work for me. Or the distro package manager stuffs your cron config with resource hoggers you really don't want, and forgets to ask you first. I suppose they might work if your OS has been installed or updated within the last few months; otherwise, forget it. Source distributions are so much faster and easier to install because the cranial clutter you have to cope with is that much less. Trouble is, to build haskell from source, you need a working haskell to build it with. Presumably, sometime in the recent past (as measured on archaeological time scales), ghc was bootstrapped from C (or some other lowest common denomiator language). Is this route still available? Some proto-proto haskell written in C, sufficiently powerful to build a proto-haskell, sufficiently powerful to build the compiler? ######################################################################### I'd really love to play with haskell. But the time I've wasted so far, trying to get it working, is almost at the stage where I just can't be bothered any more. I've been here before, and I can see that I've got 1 - 3 days x 8 hours of grinding drudgery before I finally get ghc-6.8.3 working. I suppose that's just the way GNU systems are. If anybody could give me some tips as to getting a decent haskell running on my system in a reasonable, predictable amount of time, in a way which doesn't involve diagnosing and fixing problems, I'd be very grateful indeed. Thanks! -- Alan Mackenzie (Nuremberg, Germany).

5 7

Consequences of implementing a library in Haskell for C consumption?
by Justin Bailey 04 Sep '08

04 Sep '08

I am thinking of writing a simple library in Haskell which would be useful in a number of different scenarios, and not always with programs written in Haskell. That makes me think the library should be C-compatible and able to link with C programs. Reading over chapter 9 of the GHC manual ("Foreign function interface"), it seems simple to do. However, what are the consequences of such an implementation? Would any program using my library need to link the entire GHC runtime? The library will not expose any higher-order functions or other business. It would be straightforward but tedious to write in C, which is why I'd rather use Haskell. Thanks in advance for any thoughts. Justin

2 1