- Haskell-Cafe - Haskell.org

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

12 Oct '04

I though clean was always strict, and that was the major difference between clean and haskell (that and the fact clean is a proprietry language) Keean.

13 15

Being Compatible
by John Goerzen 11 Oct '04

11 Oct '04

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?

3 2

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

11 Oct '04

>No, you still have to copy "aaaa" so you can change the tail pointer Do you? If "aaaa" is treated as a single buffer contents (IE implemented as a UArray Int Char for example) then as our 'new' list implementation# can have cells which are single elements of buffers of elements, we simply 'cons' the buffer onto the beginning of the list (IE the next pointer is not in the constants string but the cell containing it) Keean.

1 0

empty Array?
by Abraham Egnor 11 Oct '04

11 Oct '04

As a project mostly motivated by personal curiosity, I've been implementing a Sequence class: class Sequence s where front :: s a -> (a, s a) back :: s a -> (s a, a) null :: s a -> Bool empty :: s a prepend :: a -> s a -> s a append :: s a -> a -> s a concat :: s a -> s a -> s a The intent is to make it almost as easy to use, via pattern guards, as pattern matching on lists: map :: (a -> b) -> [a] -> [b] map _ [] = [] map f (x:xs) = f x:map f xs smap :: Sequence s => (a -> b) -> s a -> s b smap f s | null s = empty | (a, s') <- front s = prepend (f a) $ smap f s' It is, of course, trivial to implement this for lists. I've run into a snag, however, when trying to implement this for Arrays (as in Data.Array) - I can't seem to find a way to represent an empty array, which makes implementing 'empty' and 'null' impossible. Suggestions? Abe

2 1

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

11 Oct '04

> - take this further and have list cells with 2 (or more) unboxed > characters, or even a full buffer. This sounds like the best idea to me... with each list cell being a full buffer you could effectively write nieve [Char] code and have it implemented in about as fast a way as possible... A little improvement on this would be to do a bit of read ahead, so that the filesystem latency can be hidden. (ie one thread reads the next buffer, whilst the application thread processes the previous buffer)... This would also benefit string processing... Imagine: test = "aaaa" ++ "bbbb" This could be implented as two list cells, one for each string, anf the cost of the "++" becomes the same as the cost of ":" test = 'a' : "bbbb" could be implemented in exactly the same way (a cell of size one and a cell of size 4) In this way with the cell size dependant on the source, lists generated by prepending characters would remain exactly as they are. The only slight complexity would be allowing 'next' pointers to point halfway through a cell, so that if you start with "dddd" remove the first character and prepend 'c' the original list "dddd" could still be in scope. Keean.

4 3

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