- Haskell-Cafe - Haskell.org

Re: [Haskell-cafe] Re: OCaml list sees abysmalLanguage Shootoutresults
by MR K P SCHUPKE 09 Oct '04

09 Oct '04

>In general only specific *code* can be compiled more efficiently. I disagree - If GHC optimised as much as is _possible_ the code would be as fast and use as little memory as hand coded 'C' >It can't be transparent. A different type for semi-packed strings, Again I disagree... I dont see why you cannot change the "implementation" of lists without changing the "interface"... Good old lists will behave like good old lists - just the implementation would try and take advantage of blocking of the data wherever possible. Perhaps a pragma to change the implementation of lists would ne be a sensible way of selecting the implementation. If a clever way of encoding the node-size (for large cells) is used, then it would be no slower than normal list code... One way of doing this would be to only change the format of cells where the next link is null (IE the end of the list)... In this case normal cells would be encoded _exactly_ as they are at the moment (so no slowdown or increase in memory usage) - to encode a large cell, the next pointer is null, and then an extra data structure determines if this really is the end of the list, or if infact it is a large cell (so we need an item count, and a _real_ next cell link, plus the data block) Keean.

3 2

Re: IPv6?
by Dominic Steinitz 09 Oct '04

09 Oct '04

> ------------------------------ > > Message: 2 > Date: Fri, 8 Oct 2004 14:10:35 +0000 (UTC) > From: John Goerzen <jgoerzen(a)complete.org> > Subject: [Haskell-cafe] Re: IPv6? > To: haskell-cafe(a)haskell.org > Message-ID: <slrncmd7ur.6dr.jgoerzen(a)christoph.complete.org> > > On 2004-10-08, Simon Marlow <simonmar(a)microsoft.com> wrote: > >>On 07 October 2004 21:43, John Goerzen wrote: >> >> >>>Network.Socket in GHC6 seems to be restricted to IPv4, despite the >>>prsence of AF_INET6. How do I support IPv6 in Haskell? >> >>You write some code to handle IPv6 and send it to us for inclusion in >>Network.Socket ;-) > > > OK, fair enough, let's go down that path for a moment :-) > > I probably could figure out how to do that based on the existing IPv4 > code. Some small parts of IPv6 support are already there. > > However, I'd have two questions: > > 1. Wouldn't there need to be some sort of discussion first to ensure > that all the compiler/interpreter implementors do it the same way? > > 2. I don't know anything about the autotools stuff save that it does not > get along very well with me. If I submit a patch that assumes that IPv6 > support is available, would somebody be able to add the appropriate > tests and ifdefs around it to ensure that it really is? > > -- John > John, Maybe I'm badly informed but there is hardly any usage of IPv6. What's driving you to want to use it? Dominic.

1 0

ANN: MissingH
by John Goerzen 09 Oct '04

09 Oct '04

Hi, Well here is why I've been asking all these questions in here. Comments welcome. Thank you for all your help. Download or read docs at: gopher://quux.org/1/devel/missingh http://quux.org/devel/missingh Here are excerpts from the README file: ------------------------- Major Features ------------------------- * Powerful Logging Framework for Haskell This framework provides a system of hierarchical loggers and modular handlers permitting fine-grained logging with a great deal of control and yet a simple and fast interface. It's based on log4j for Java and logging for Python. Also included is a native-Haskell Syslog client. * IO utilities make it easier to work with line-based text files and binary files * List utilities including association list tools, list splitting, truncation, and delimiter joining * String utilities including removal of leading or trailing whitespace, joining, splitting, and truncation The entire library has no prerequisites save the Haskell standard library and is designed to install without complexity on a variety of systems. It could also easily be embedded within your own source trees so that users need not have it installed beforehand.

1 0

The State Monad
by John Goerzen 09 Oct '04

09 Oct '04

This thing is giving me fits. I need a global variable of sorts for an implementation of Syslog. (Yes, I really do.) It seems the right way to do that is the state monad. But I can't figure out how to do two simple things: * Read what is in there without modifying it * Modify it appropriately I looked at the examples in Control.State.Monad. We see: tick :: State Int Int tick = do n <- get put (n+1) return n Add one to the given number using the state monad: plusOne :: Int -> Int plusOne n = execState tick n Which looks nice enough, but completely useless. tick seems to be a very complex way to say ((+) 1) in this example. Oddly enough, I get a type error if I try this: tick :: Int -> State Int Int tick newval = do put newval return newval Or this: tick :: State Int Int tick = do n <- get return n That is even more incomprehensible to me -- why would removing a line before the return cause a type error?

4 4

OCaml list sees abysmal Language Shootout results
by Keith Wansbrough 09 Oct '04

09 Oct '04

I just saw this on the OCaml list (in a posting by "Rafael 'Dido' Sevilla" <dido(a)imperium.ph> in the "Observations on OCaml vs. Haskell" thread). I can't believe that a simple "wc" implementation should be 570 times slower in Haskell than OCaml - could someone investigate and fix the test? --KW 8-) http://caml.inria.fr/archives/200409/msg00485.html > > 2. Haskell strings are lists of characters > > > > It's annoying that strings aren't normally processed this way in OCaml, > > and even more annoying that (^) or (::) cannot be used in pattern > > matching over strings. I like Haskell's approach. The list > > concatenation operator is the same as the string concatenation operator > > in Haskell. > > > > This is something of an efficiency/elegance tradeoff. Making strings > act like lists means potentially boxing *every character in the string*. > In other words, it's potentially a very expensive way of doing business. > Paul Graham was mulling over this kind of tradeoff in his design of Arc, > as I recall. Another language that does this type of thing is Erlang, > and both languages seem to be significantly slower than OCaml in string > handling, at least as far as this site goes: > > http://shootout.alioth.debian.org/ > > For the word count benchmark OCaml scores 0.1850 seconds, while GHC is a > dismal last place at 105.2110 seconds! Even the bytecode ocaml is an > order of magnitude faster. The word frequency benchmark also shows this > kind of poor string handling performance for Haskell, with OCaml scoring > 0.5669 seconds, while GHC scores a truly dismal 6.4540, more than an > order of magnitude slower, and even the bytecode ocaml is faster at > 4.2644 seconds. > > All in all, it would appear that Haskell's approach has been expensive > in terms of performance, if the benchmarks are to be taken at face > value. Such are the tradeoffs language designers have to make.

18 43

Re: [Haskell-cafe] Re: OCaml list sees abysmal Language Shootoutresults
by MR K P SCHUPKE 09 Oct '04

09 Oct '04

Doubly linked lists do not work very well in functional languages.# when you have a list [1,2,3] and you prepend a value [9,1,2,3] the language relies on the fact that the list tail [1,2,3] is not chainged by this operation. This means the list can be "prepended-in-place". With a doubly linked list the [1] cell would be changes (the 'left' pointer is changed from null to point to the [9] cell)... The result of this is that with a doubly linked list the _whole_ list must be copied when prepending a single value. In other words in a functional language, a doubly linked list will make ':' as hard as '++' and not the other way round! Keean.

1 0

RE: [Haskell-cafe] Re: OCaml list sees abysmalLanguage Shootoutresults
by Simon Marlow 08 Oct '04

08 Oct '04

On 08 October 2004 13:36, Robert Dockins wrote: > BTW can you give some references to these known techniques? Hmm, well here's some folklorish ideas. I'm sure there are references for most of these, but I don't know them off hand. - Have another list constructor that has 2 (or more) elements. Prelude funnctions can take advantage of this, but the constructor can magically transform itself into ordinary cons cells when it is examined by an ordinary pattern match. - take this further and have list cells with 2 (or more) unboxed characters, or even a full buffer. - use space-saving techniques for storing list cells: eg. remove the tail pointer when cells appear next to each other in the heap, or have a memory page just for list cells and omit the info pointers. Or just improve cache behaviour by trying to store list cells adjacent in the heap. Cheers, Simon

1 0

A Typing Dilemma
by John Goerzen 08 Oct '04

08 Oct '04

Thanks so much for all the help many of you have provided. I have one (heh) more question: I have this code: defaultHandler :: LogHandler b => IO (a -> IORef b) defaultHandler = do h <- (streamHandler stdout WARNING) r <- newIORef h return (\x -> r) The idea is to create a new IORef to something in the LogHandler class and return a function that returns it. The thing returned by that call to streamHandler is in the LogHandler class. Specifically, its declaration looks like this: instance LogHandler (GenericHandler a) where ... and streamHandler returns a "GenericHandler Handle" object. Now, when compiling that defaultHandler code, the compiler complains: Cannot unify the type-signature variable `b' with the type `MissingH.Logging.Handler.Simple.GenericHandler Handle' Expected type: IORef b Inferred type: IORef (MissingH.Logging.Handler.Simple.GenericHandler Handle) In a lambda abstraction: \ x -> r In the first argument of `return', namely `(\ x -> r)' I'm stumped. Can anyone shed some light on that for me? Thanks, -- John

2 1

RE: [Haskell-cafe] Being Compatible
by Simon Peyton-Jones 08 Oct '04

08 Oct '04

John Yes, I think your best route is cpp-ery, horrible though it is. I suggest you use ghc6.2.1 (or 6.2.2 when it comes out, which will be Monday-ish), rather than some ghc5.x version. Otherwise you risk investing work in making a library incompatible with the current story. Simon | -----Original Message----- | From: haskell-cafe-bounces(a)haskell.org [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of John | Goerzen | Sent: 07 October 2004 15:35 | To: haskell-cafe(a)haskell.org | Subject: [Haskell-cafe] Being Compatible | | Hi, | | I have appreciated some of the comments here about what exactly is | standardized. My next question is how to work at the greatest number of | places. | | I am working on a library of Haskell-related utilities. There is some | code in there that works with binary I/O, and some code that works with | rawSystem(), etc. | | Some of these are not supported on Hugs, nhc98, or ghc5 to varying | degrees. | | My initial thought was to use the cpp-style ifdefs I've seen elsewhere | to mask those unsupported features on those particular systems. But | Hugs at least doesn't support that, and I've found it extremely | difficult to find a list of predefined macros for the other systems | anyway. | | What is the suggested way to work around these problems? | | | _______________________________________________ | Haskell-Cafe mailing list | Haskell-Cafe(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe

1 0

RE: [Haskell-cafe] Re: IPv6?
by Simon Marlow 08 Oct '04

08 Oct '04

On 08 October 2004 15:11, John Goerzen wrote: > I probably could figure out how to do that based on the existing IPv4 > code. Some small parts of IPv6 support are already there. > > However, I'd have two questions: > > 1. Wouldn't there need to be some sort of discussion first to ensure > that all the compiler/interpreter implementors do it the same way? We all share libraries, so anything you do to Network.Socket will appear in all the compilers, provided it is portable enough. If there are issues about how the interface to IPv6 should be exposed to the programmer, then the best place to discuss it is libraries(a)haskell.org. I suspect that it'll be pretty straightforward, though - Network.Socket is a low level interface that just tries to re-expose the OS primitives as a Haskell library. > 2. I don't know anything about the autotools stuff save that it does > not get along very well with me. If I submit a patch that assumes > that IPv6 support is available, would somebody be able to add the > appropriate tests and ifdefs around it to ensure that it really is? Probably... we have one or two autoconf-compliant hackers amongst the GHC regulars. Cheers, Simon

1 0