From: Adrian Hey <a...@NoSpicedHam.iee.org>
Date: Wed, 22 Apr 2009 10:11:11 +0100
Local: Wed, Apr 22 2009 5:11 am
Subject: Re: Haskell bashing (was Re: F# vs OCaml vs Python vs Haskell: hash table performance)
Ertugrul Söylemez wrote:Have you ever written an IO lib? A non-trivial FFI binding perhaps?
> Perhaps it's just me, but I've never used the unsafePerformIO hack.
I'm not saying that even if you have you would necessarily have needed
to use the unsafePerformIO hack. Sometimes you don't need it, but
often use of a top level MVar or something (to implement a lock
say) really is the *only* semantically correct and safe solution,
unless you're going to just say the lib is not thread safe and
should not be used in concurrent apps (a pretty severe limitation
IMO). Unfortunately Haskell provides no safe way to do this.
Even some of those that have managed to avoid it only do so by
BTW, anyone who has ever used stdout has used a "global variable"
> It has been shown that a complete operating system can be implementedYou mean the "Principled Approach to Operating System Construction in
> entirely in Haskell. Have a look at House .
Again, perhaps you should take a look at the source. Even for this
Some conclusions re. the suitablility of Haskell in it's current form
No real surprises there, but strangely neither of these papers mentions
It all adds to my suspicion that there is a real conspiracy of silence
> Of course as well I might be misunderstanding your idea of modularity.I mean that without top level state (a lock say) I have to provide a
library API that is not only less excessively complex and less
convenient to use and maintain, it is also less safe.
For the lock example, instead of this..
module LockDemo (doSomething) where
lock :: MVar ()
doSomething :: IO Whatever
...I have to use something like this..
module LockDemo (Lock,newLock,doSomething) where
newtype Lock = Lock (MVar ())
-- | If you make more than one of these you're screwed
doSomething :: Lock -> IO Whatever
I have now have no static guarantee that only one lock will be created.
Furthermore, assuming everybody has respected the uniquiness properties,
Other libs might well be modified to make use of my services too at some
And no, I don't think exotic library or application level monads help
And no again (before anybody says it), the problem is not with "badly
Haskell should be able to safely interface to any "badly designed"
> There is something wrong with global variables in the Haskell paradigm,Sorry I don't really know how to answer this, but it looks to me as if
> because since everything is pure, a global modifyable variable isn't
> even expressable. If you really need them, either you use StateT, which
> is perfectly safe, pure and modular (remember that multiple StateTs can
> be combined) or you use the ugly variant of essentially the same, an
> unsafePerformIO hack.
you don't understand the problem people are trying to solve when they
use the unsafePerformIO hack. If so, you would certainly not be the
first to misunderstand this which is why it is so hard to have a
sensible discussion about this problem (people have already made up
their minds about the "right way to do it" before they've even taken
the time to understand the problem). I don't know if my words above have
clarified this at all :-)
Remember the concurrency semantics of MVars, Chans and functions like
> For some reason, people refrain from using StateT here, but prefer toI think they use they unsafePerformIO hack because it is the only way
> use unsafePerformIO.
to get a unique MVar or whatever at the top level and that is what they
> Honestly I've never tried JHC. I'll give it a shot, when I've got someWell I don't use it myself either. I think at the moment it's very much
> time. =)
work in progress, so I don't know if it really is realistically useable
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.