- Haskell-Cafe - Haskell.org

Yet another top-level state proposal
by Judah Jacobson 29 May '07

29 May '07

Hi all, Given the recent discussion about adding top-level mutable state to Haskell, I thought it might be a good time to throw my own proposal into the ring. If enough people think it's worth considering, I can add it to the wiki page. (http://www.haskell.org/haskellwiki/Top_level_mutable_state) In contrast to recent proposals, this one requires no extra syntax or use of unsafe functions by the programmer. Any nonstandard "magic" that might occur is kept within the compiler internals. Furthermore, top-level initializations are only executed when needed; merely importing a module does not cause any additional actions to be run at startup. The core idea, similar to that of "type-based execution contexts" on the above wiki page, is to associate each top-level action with its own type. For example, the current way to declare a source for unique integers is: ------------------------------------------------ {-# NOINLINE uniqueRef #-} uniqueRef :: IORef Integer uniqueRef = unsafePerformIO $ newIORef 0 uniqueInt :: IO Integer uniqueInt = do n <- readIORef uniqueRef writeIORef uniqueRef (n+1) return n ------------------------------------------------ Under this proposal, we would write instead: ------------------------------------------------ newtype UniqueRef = UniqueRef (IORef Integer) deriving OnceIO instance OnceInit UniqueRef where onceInit = liftM UniqueRef (newIORef 0) uniqueInt :: IO Integer uniqueInt = do UniqueRef uniqueRef <- runOnceIO n <- readIORef uniqueRef writeIORef uniqueRef (n+1) return n ------------------------------------------------ The above code uses two classes: class OnceInit a where onceInit :: IO a class OnceInit a => OnceIO a where runOnceIO :: IO a The OnceInit class lets the programmer to specify how a type is initialized; above, it just allocates a new IORef, but we could also read a configuration file or parse command-line arguments, for example. In contrast, instances of the OnceIO class are not written by the programmer; instead, they are generated automatically by a "deriving OnceIO" clause. Each type for which OnceIO is derived will have a special top-level action associated with it, which is accessed through the runOnceIO function. Its semantics are: - The first time that "runOnceIO" is called, it runs the corresponding "onceInit" action and caches and returns the result. - Every subsequent time that "runOnceIO" is called, it returns the cached result. This behavior is safe precisely because runOnceIO is an IO action. Even though one can't guarantee when in the program an initialization will occur, when the initialization does happen it will be sequenced among other IO actions. To illustrate this behavior, here are a couple sample implementations in plain Haskell. These do use unsafePerformIO, but in practice any such details would be hidden in the instance derived by the compiler (along with any related NOINLINE/NOCSE pragmas): instance Once UniqueRef where runOnceIO = return $! unsafePerformIO onceInit or (less efficient, but multithreaded safe): instance Once UniqueRef where runOnceIO = modifyMVar onceUniqueRef $ \mx -> case mx of Just x -> return (Just x, x) Nothing -> do {x <- onceInit; return (Just x, x)} onceUniqueRef = unsafePerformIO $ newMVar Nothing Finally, note that the deriving clause can easily check whether the type in question is monomorphic (as is necessary for type-safety), since it already has access to the type definition. Anyway, that's the gist of my proposal; I hope I've explained it well, but please let let me know if you have questions, suggestions or criticisms. Best, -Judah

6 6

Re: [Haskell-cafe] The C Equiv of != in Haskell
by PR Stanley 29 May '07

29 May '07

>Hi > >>What is the C equivalent of the inequality operator in Haskell? > >/= > >You can answer these sorts of questions yourself using Hoogle: And what makes you think I haven't tried Google already? Unlike you I only write to the list when I have a legitimate reason to do so.

9 12

Re: [Haskell-cafe] The C Equiv of != in Haskell
by PR Stanley 29 May '07

29 May '07

Thank you Neil, again I'm sorry for getting the wrong end of the stick. Cheers Paul At 02:50 29/05/2007, you wrote: >Hi Paul > >Sorry if you interpreted my answer as a symbol, I never use smilies so >didn't even consider that people may see it in another light! > >Thanks > >Neil > > >On 5/29/07, PR Stanley <prstanley(a)ntlworld.com> wrote: >> >> > > >Hi >> > > > >> > > >>What is the C equivalent of the inequality operator in Haskell? >> > > > >> > > >/= >> > > > >> > > >You can answer these sorts of questions yourself using Hoogle: >> > > >> > > And what makes you think I haven't tried Google already? >> > > Unlike you I only write to the list when I have a legitimate >> reason to do >> > > so. >> > >> >Just in case there was some sort of miscommunication, the actual answer to >> >your question is (/=) :: a -> a -> Bool, as Neil said. >> > >> >The /= wasn't some sort of frowny, quit-wasting-my-time emoticon. >> >_______________________________________________ >>Thank you, Dan. >>Regards >>Paul >> >>_______________________________________________ >>Haskell-Cafe mailing list >>Haskell-Cafe(a)haskell.org >>http://www.haskell.org/mailman/listinfo/haskell-cafe

1 0

Re: [Haskell-cafe] The C Equiv of != in Haskell (Apologies)
by PR Stanley 29 May '07

29 May '07

>Hi > >> >You can answer these sorts of questions yourself using Hoogle: >>And what makes you think I haven't tried Google already? > >Hoogle, starting with 'H'. Follow the link I gave you, which is a >search engine for Haskell functions, by type and name. If you search >for "a -> a -> Bool" (a likely type that the != would have) then >Hoogle gives you an answer. > >>Unlike you I only write to the list when I have a legitimate reason to do so. > >I am not suggesting you have no legitimate reason, just trying to help >you find the information you need quicker in future. I was in no way >trying to suggest you shouldn't have posted - its a fair question >given its a different choice to most other languages. > >Thanks > >Neil Thank you,Neil. I apologise for my sharp response. It's been a long day. However, I don't think these other individuals had any business poking their hooters into this. All the best, Paul

2 1

Re: [Haskell-cafe] The C Equiv of != in Haskell
by PR Stanley 29 May '07

29 May '07

At 03:02 29/05/2007, you wrote: >On 5/29/07, PR Stanley <prstanley(a)ntlworld.com> wrote: >>What is this, the Haskell Cafe Gang? > >Maybe. Moreover this list is not a prepaid service in which you can >unpolitely _demand_ answers. > >You got your question answered still complain ... I don't get it. Yes, the question has been answered but you still feel the need to keep the thread alive, hmm, you're right, it is very strange behaviour indeed.

1 0

The C Equiv of != in Haskell
by PR Stanley 29 May '07

29 May '07

Hi What is the C equivalent of the inequality operator in Haskell? Thanks Paul

2 1

Bug in GADT Implementation?
by Dominic Steinitz 28 May '07

28 May '07

I would expect foo r@(Range BITSTRING _ _) x = [] to give an error but it doesn't. Writing t = Range BITSTRING gives one so why not the pattern match? Dom. data BitString = BitString [Bool] deriving Show data ConstrainedType :: * -> * where INTEGER :: ConstrainedType Int BITSTRING :: ConstrainedType BitString Seq :: ConstrainedType a -> ConstrainedType b -> ConstrainedType (a,b) Range :: Ord a => ConstrainedType a -> a -> a -> ConstrainedType a foo :: ConstrainedType a -> a -> [Int] foo BITSTRING (BitString x) = map fromEnum x foo INTEGER x = [x] foo r@(Range INTEGER _ _) x = [upperInt r,x] foo r@(Range BITSTRING _ _) x = [] r1 = Range INTEGER 20 40 r2 = Range r1 25 45 upperInt :: ConstrainedType Int -> Int upperInt INTEGER = 256 upperInt (Range t l u) = min u (upperInt t)

6 7

Curiose types
by Andrew Coppin 28 May '07

28 May '07

As I lay in bed last night, a curios fact occurred to me. (Yes, I don't get out very much...) Consider the map function: map :: (a -> b) -> [a] -> [b] There are two ways you can think about this function. First, you can see it as meaning map :: (a -> b) -> ([a] -> [b]) Which is beautifully symmetric. Alternatively, you can think about how you actually use it: map :: ((a -> b) -> [a]) -> [b] Now this got me thinking: is (->) associative? x_x Well now, let's consider a general 3-argument function: foo :: a -> b -> c -> d According to the rules, this is of course equivilent to foo :: a -> (b -> (c -> d)) If you understand what currying is and how it works, this makes perfect sense. Now let's bracket that the other way: foo :: ((a -> b) -> c) -> d Well, while that type *does* make sense, it's clearly a completely *different* type! So, clearly, (->) is not associative. Now I'm left wondering why you can bracket the type for map in two different ways, but not in general. Hmm...

8 9

Re: [Haskell-cafe] Language extensions
by Andrew Coppin 28 May '07

28 May '07

Chaddaï Fouché wrote: > 2007/5/28, Andrew Coppin <andrewcoppin(a)btinternet.com>: >> Then again, later on in the very same book there's a chapter entitled >> "Fun with Phantom Types", which made precisely no sense at all... >> > > You seem to think you're extremely clever since if something doesn't > make sense to you it _obviously_ doesn't make sense at all... Well it > at least made sense for the authors of the article, and lots of person > who read it. Surely it makes sense to someone. (But then, there are people to whom number theory makes sense.) I didn't mean to imply that it is *impossible* to comprehend the article, only that it's very greatly beyond my capabilities. I like to think I'm an intelligent, but... maybe I'm just kidding myself...

2 1

Random ramble
by Andrew Coppin 28 May '07

28 May '07

[You may want to just hit delete now? ;-) ] I don't know where everybody else is, but where I live, we have various science programs on TV from time to time. (Horizon being a fairly regular one.) They grab a bunch of eggheads, and try to get them to explain (in soundbites) some topic or other. Sometimes it's string theory, or quantum dynamics, or chaos theory, or something like that. (And sometimes it's economics - and then I change channel.) Usually the producers go to great lengths to make the subject seem "interesting" - that is, try to be as over-dramatic as possible. Often accompanied with copious computer graphics, which mainly just look pretty. Anyway, I was sitting here thinking to myself "hey, what if they got a bunch of people to talk about Haskell?" (That's *one* way to get publicity...!) I don't know how many of you are as neurotically familiar with The Matrix as I am, but... I found myself visualising that scene from about mid-way through the film. Morpheus: "This may feel... a little weird." [6 inch metal plug injected into the back of Neo's skull] Neo: "AAAAAAAAAAARRGH!!" [They turn on the computer.] [Neo finds himself floating in a sea of lambda functions, higher-kinded class instances and parametric polymorphism.] ...and then I find myself thinking of http://xkcd.com/c224.html Erm... OK, I'll go sit in the corner and be quiet now.

1 0