- Haskell-Cafe - Haskell.org

NewbieQ: colon prefix for operators, e.g., Ratio ?
by Brian Beckman 11 Oct '04

11 Oct '04

Apologies if this is the wrong mailing list in which to pester folks with Newbie Questions, but I couldn't find my answer after half an hour of scouring the Haskell Report, the Haskell Wiki, the School of Expression book and a couple of tutorials. The frustrating thing is that I know I saw the answer in ONE of those sources and it didn't stick at the time: what does it mean when an operator is prefixed by a colon? For instance, in the Ratio module, the meaning of x % y is clear, but x :% y appears in multiple places and I'm confused.

2 1

Re: Language extension idea (was Re: [Haskell-cafe] Re: OCaml list sees...)
by J.Garrett.Morris＠Dartmouth.EDU 10 Oct '04

10 Oct '04

--- Malcolm Wallace wrote: As an example, instead of the following list-only code, f :: List a -> ... f [] = ... f (h:t) = ... you could write this more general version, which assumes only some class Sequence with operations null, head, tail, etc. f :: Sequence s => s a -> ... f list | null list = ... | h <- head list, t <- tail list = ... --- end of quote --- I guess that's about half way there. I (and, I think, the original poster) was thinking more along the lines of generalizing the existing interface and considering lazy lists to be one implementation. It seems like the "list" syntax is general enough to apply to any ordered collection. Further, that would only require minimal changes in large amounts of existing code that relies on, for example, Strings being [Char]s were Strings changed to a more efficient representation. /gXm

1 0

Language extension idea (was Re: [Haskell-cafe] Re: OCaml list sees...)
by oleg＠pobox.com 09 Oct '04

09 Oct '04

Tom Pledger wrote: > Something along these lines: > > class List l a | l -> a where > nil :: l > cons :: a -> l -> l > > But that's not of much use, because there isn't a class method to > recover the elements of a List. We could add more methods (corresponding > to null, head, and tail) Actually we merely need to add a deconstructor. Also, we can leave the type of elements fully polymorphic. Something like this: > class List l where > nil :: l a > cons :: a -> l a -> l a > decon :: l a > -> w -- on empty > -> (a -> l a -> w) > -> w > > instance List [] where > nil = [] > cons = (:) > decon [] on_nil on_cons = on_nil > decon (h:t) on_nil on_cons = on_cons h t we can then write truly generic list-processing functions: > rev:: List l => l a -> l a > rev l = rev' l nil > where > rev' l acc = decon l acc (\h t -> rev' t (cons h acc)) not in a terribly convenient way though. *Foo> rev "abc" "cba"

2 1

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 08 Oct '04

08 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 08 Oct '04

08 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