John Goerzen [EMAIL PROTECTED] writes:
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
On 07 October 2004 18:23, Ketil Malde wrote:
Couldn't readFile et al. provide the standard interface, but use
hGetBuf tricks (e.g. from your 'wc' entry) behind the curtains?
readFile does do buffering behind the scenes, that's not the problem.
The problem is doing the computation on a [Char]
Ketil Malde ([EMAIL PROTECTED]) wrote:
As somebody just said, you get to chose between speed and
simplicity/clarity of code. I would like both.
Me too.
Simplicity/calrity of code is, imho, one of the strong point in using Haskell.
Couldn't readFile et al. provide the standard interface,
Ketil Malde writes:
Couldn't readFile et al. provide the standard interface,
but use hGetBuf tricks (e.g. from your 'wc' entry) behind
the curtains?
No amount of hGetBuf'ing will speed the program up if the
problem is the algorithm. I/O comes _sequentially_, and
every program that doesn't
On 07 October 2004 20:53, Robert wrote:
I've been playing around with the Hashes, Part II code from the
shootout. I wanted to try to implement this test using Data.HashTable
instead of Data.FiniteMap to see if that would buy us anything. In
fact, the HashTable implementation is consistantly
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 ;-)
Cheers,
Simon
Actually, I've been wondering about this. If my understanding is
correct, Haskell lists are basicly singly-linked lists of cons cells (is
that correct?) A simple (I think) thing to do would be to make the
lists doubly-linked and circular. That would let us do nice things like
have O(1)
On Fri, Oct 08, 2004 at 08:35:40AM -0400, Robert Dockins wrote:
Actually, I've been wondering about this. If my understanding is
correct, Haskell lists are basicly singly-linked lists of cons cells (is
that correct?) A simple (I think) thing to do would be to make the
lists doubly-linked
lists doubly-linked and circular.
Erm, this just increases overhead, and file access is linear
anyway. Singly linked is good enough. What would make a difference
is if each 'node' in the listwas allowed to be larger that '1'
item. For example reading a file with 4k buffers, would work much better
Andrew Butterfield [EMAIL PROTECTED] writes:
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)
No - Clean is pure and lazy like Haskell,
But it uses explicit strictness annotations a lot, and
Actually, I've been wondering about this. If my understanding is
correct, Haskell lists are basicly singly-linked lists of cons cells (is
that correct?) A simple (I think) thing to do would be to make the
lists doubly-linked and circular. That would let us do nice things like
have O(1)
At some point in the past, someone wrote:
Actually, I've been wondering about this. If my understanding is
correct, Haskell lists are basicly singly-linked lists of cons cells (is
that correct?) A simple (I think) thing to do would be to make the
lists doubly-linked and circular. That
William Lee Irwin III [EMAIL PROTECTED] writes:
Actually, I've been wondering about this. If my understanding is
correct, Haskell lists are basicly singly-linked lists of cons cells (is
that correct?) A simple (I think) thing to do would be to make the
lists doubly-linked and circular.
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)
On 2004-10-08, Simon Marlow [EMAIL PROTECTED] 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
At 03:32 PM 10/8/2004, Marcin Kowalczyk wrote:
Andrew Butterfield [EMAIL PROTECTED] writes:
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)
No - Clean is pure and lazy like Haskell,
But it uses
William Lee Irwin III [EMAIL PROTECTED] writes:
Ugh, lousy cache properties... try rank-ordered B+ trees. There are
probably better choices than that even. It's probably best Simon point
us to references to what's actually useful here.
On Fri, Oct 08, 2004 at 03:55:05PM +0200, Ketil Malde
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
At 03:32 PM 10/8/2004, Marcin Kowalczyk wrote:
Andrew Butterfield [EMAIL PROTECTED] writes:
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)
No - Clean is pure and lazy like Haskell,
But it uses
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
|
Robert Dockins wrote:
Actually, I've been wondering about this. If my understanding is
correct, Haskell lists are basicly singly-linked lists of cons cells (is
that correct?) A simple (I think) thing to do would be to make the
lists doubly-linked and circular. That would let us do nice
On 2004 October 08 Friday 09:57, John Goerzen wrote:
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
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.
- 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
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
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
At some point in the past, someone's attribution was stripped from:
It can't be transparent. A different type for semi-packed strings,
On Fri, Oct 08, 2004 at 07:28:53PM +0100, MR K P SCHUPKE wrote:
Again I disagree... I dont see why you cannot change the implementation
of lists without
Marcin 'Qrczak' Kowalczyk writes:
Peter Achten [EMAIL PROTECTED] writes:
It is of course not the language that uses strictness annotations.
But the language encourages to use them much more often than in
Haskell. They can be declared in types, there is a short syntax for
strict let, and various
On Fri, 8 Oct 2004, Marcin 'Qrczak' Kowalczyk wrote:
If the representation of some lists was changed, it would complicate
all code which works on lists. Or maybe only polymorphic code, but
it's still much. I don't believe it would be practical.
That's true in OCaml but not in the STG-machine,
Sorry to nit-pick, but state monads are NOT syntactic sugar -- they're
just an example of good old data/functional abstraction, that also
happens to be in the form of a monad.
On the other hand, Haskell's do notation -- now THAT'S syntactic sugar :-)
-Paul
Ben Lippmeier wrote:
John Goerzen
On 07/10/2004, at 11:51 AM, Peter Simons wrote:
The problem is not Haskell, nor is it the implementation.
The problem is that beginners, including yours truly, tend
to write awfully inefficient code once you give them a
String and tell them: Here, that's the contents of your
file. The lazy API
On Fri, Oct 08, 2004 at 12:43:45PM -0400, Robert Dockins wrote:
x = [3,5,7]
primes = 2:x
odds = 1:x
You can't do sharing like this if your lists are doubly-linked; lots
of cool algorithms depend on this sharing.
That constraint makes various other things painful. I suppose there is
no
On 08-Oct-2004, Andre Pang [EMAIL PROTECTED] wrote:
I believe that Marcin wishes to prove the same point that I want to:
namely, Clean encourages use of strictness by making it easier to use
(via language annotations). At the risk of sounding ignorant and
arrogant, I think the Haskell
G'day all.
Quoting Paul Hudak [EMAIL PROTECTED]:
Sorry to nit-pick, but state monads are NOT syntactic sugar -- they're
just an example of good old data/functional abstraction, that also
happens to be in the form of a monad.
Right.
State monads help to future-proof your code because you
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
35 matches
Mail list logo
