- Haskell-Cafe - Haskell.org

Re: ACIO versus Execution Contexts
by George Russell 30 Nov '04

30 Nov '04

Adrian Hey wrote (snipped): > I've been looking at your global variables library. Thanks. > In particular, the purpose of top level <- bindings IMO is *not* to > provide "global variables" (though they could be abused this way). > If you consider the example.. > > userInit <- oneShot realInit > > ..the top level MVar created is not global. It doesn't even scope over > an entire module, it's buried in a closure. This kind of use would be > pretty typical I think. Even when you do have top level IORefs (or > more complex mutable data structures) scoping over an entire module, > generally they won't be exported by that module. Instead access is > strictly limited to a few carefully defined IO actions, and these > are exported. I think you must mean by "global variable" something different to what I mean by "global variable". It is precisely such uses as you describe above which I would anticipate being supported by the Execution Contexts proposal. Of course good structured programming would hide a module's use of execution contexts or top-level variables. > Also, we don't want different threads to have their own versions of > these. There seems to have been some confusion on this point, so I should make it clear that by default, with my proposal, threads *do*not* each have their own versions of the variables. This only happens if you explicitly create a new execution context and run an action within it; that action, and the threads it forks off, will then use the new execution context. > They are for use in situations where you need to represent > state associated with a genuinely unique resource (eg top level > stateful C library or hardware IO device). In my experience this is only true quite rarely. I think Keean and Lennart have already said most of what I have to say here.

3 2

[Fwd: Re: [Haskell-cafe] Re: ACIO versus Execution Contexts]
by Lennart Augustsson 30 Nov '04

30 Nov '04

1 0

RE: Efficient or predictable Ord for Typeable
by Simon Peyton-Jones 30 Nov '04

30 Nov '04

The trouble is that *any* "function" can now deliver unpredictable results. Can I rely on the fact that foo :: Int -> Int will always give the same answer given the same input. Not any more. I think the strongest argument here is that it's like a more benign version of unsafePerformIO, whose existence also threatens foo's predictability. | -----Original Message----- | From: George Russell [mailto:ger@informatik.uni-bremen.de] | Sent: 30 November 2004 09:55 | To: haskell-cafe(a)haskell.org; Simon Peyton-Jones; John Meacham | Subject: Efficient or predictable Ord for Typeable | | Simon PJ wrote (snipped): | > This unfortunate observabilty of an ordering (or hash value) that is | > needed only for efficient finite maps, is very annoying. I wish I knew | > a way round it. As it is we can pick | > a) expose Ord/Hash, but have unpredictable results | > b) not have Ord/Hash, but have inefficient maps | | In this case there is a simple solution. Simply define | | newtype FastUnpredictableInstances a = FastUnpredictableInstances a | | and define the fast Ord and Hash only for FastUnpredictableInstances. | People who manage to type all that then have no grounds to grumble | if they get bitten. For something as basic as implementing execution | contexts, FastUnpredictableInstances is acceptable.

4 4

RE: [Haskell-cafe] Re: [Haskell] Re: Global Variables and IOinitializers
by Simon Peyton-Jones 30 Nov '04

30 Nov '04

| > In fact GHC at least *already* generates a unique integer for each | > TypeRep. A good idea, since it means comparisons can be done in unit | > time. Thus indexing can be done trivially using this integer as a | > hash function. | | Yes, I have seen this in the code, too. The Ord and Typeable instances | should be trivial. Take care here. There is no guarantee that the unique number generated will be the same in each run. So if you have Ord Typeable, this program may give unpredictable results: main = print (typeOf True < typeOf 'x') This unfortunate observabilty of an ordering (or hash value) that is needed only for efficient finite maps, is very annoying. I wish I knew a way round it. As it is we can pick a) expose Ord/Hash, but have unpredictable results b) not have Ord/Hash, but have inefficient maps Simon

4 3

Efficient or predictable Ord for Typeable
by George Russell 30 Nov '04

30 Nov '04

Simon PJ wrote (snipped): > This unfortunate observabilty of an ordering (or hash value) that is > needed only for efficient finite maps, is very annoying. I wish I knew > a way round it. As it is we can pick > a) expose Ord/Hash, but have unpredictable results > b) not have Ord/Hash, but have inefficient maps In this case there is a simple solution. Simply define newtype FastUnpredictableInstances a = FastUnpredictableInstances a and define the fast Ord and Hash only for FastUnpredictableInstances. People who manage to type all that then have no grounds to grumble if they get bitten. For something as basic as implementing execution contexts, FastUnpredictableInstances is acceptable.

1 0

Re: [Haskell] Re: Global Variables and IO initializers
by George Russell 29 Nov '04

29 Nov '04

(indexing with TypeRep) > This is yet another incidence where Robert Will's ByMaps would be very useful In fact GHC at least *already* generates a unique integer for each TypeRep. A good idea, since it means comparisons can be done in unit time. Thus indexing can be done trivially using this integer as a hash function.

3 2

Re: OO in Haskell
by Keean Schupke 29 Nov '04

29 Nov '04

Benjamin Franksen wrote: >I still have problems. They are probably due to a wrong definition of the >operator (#). Note that (#) is nowhere defined inside the HList sources, so I >assumed an inverse application aoperator. This is my program now: > > No, # is the record selection operator from the HList based records. infixr 9 # m # field = m .!. field Keean.

2 2

Haskore Wiki
by Henning Thielemann 29 Nov '04

29 Nov '04

For those who are interested in composing music using Haskell, I have initiated a page on the Haskell Wiki about projects related to Haskore: http://www.haskell.org/hawiki/Haskore I also like to point to my private work on Haskore. It includes bug-fixes, a more fine-grained modularization, better support for infinite music data, an automatic test-suite that is run by Darcs whenever one records a new patch, a Haddock reference documentation, some examples of music processing such as Markov chains. The Music datatype is now based on a more general type for temporal media as proposed by Paul Hudak. Unfortunately the simplicity required for teaching is partially lost. :-( The current state can be found at: http://cvs.haskell.org/darcs/haskore/src/ In the future it should support a more general notion of instruments and MIDI controllers. So there will be more incompatible changes ...

4 3

[Haskell] A puzzle and an annoying feature
by Martin Sulzmann 29 Nov '04

29 Nov '04

[Discussion moved from Haskell to Haskell-Cafe] Hi, Regarding - "lazy overlap resolution" aka unique instances Well, if there's only instance which is not exported, then you can use functional dependencies. Assume class C a instance ... => C t Internally, use class C a | -> a instance ... => C t Furthermore, there seems to be an issue that has been overlooked so far. - Providing sufficient type annotations Recall Lennart Augustsson writes: > Here is a small puzzle. > > -- The following generates a type error: > f :: Char -> Char > f c = > let x = g c > in h x > Lennart "magically" inserted a type annotation to resolve the ambiguity. > -- But this definition does not: > f :: Char -> Char > f c = > let x :: Bool > x = g c > in h x > Clearly, there are a number of ways to resolve the ambiguity. The Chameleon type debugger assists the user in identifying which locations are responsible. Here's the Chameleon type debugger error message generated for the unannotated function f temp.ch:2: ERROR: Inferred type scheme is ambiguous: Type scheme: forall b. C b => Char -> Char Suggestion: Ambiguity can be resolved at these locations b: f :: Char -> Char f c = let x = g c ^ ^ in h x ^ ^ (The ^ correspond to highlightings of the Chameleon type debugger) This may help the user to realize where and which annotations are missing. E.g., each of the following annotations (there are more possibilities) will do the job. f :: Char -> Char f c = let -- x :: Bool (1) x = g c in h x -- h (x::Bool) (2) -- (h::Bool->Char) x (3) Martin

4 6

Help!
by balarcon＠dsic.upv.es 29 Nov '04

29 Nov '04

Hi, I'm a computer´s student and have some problems with a work I have to do. My teacher has an application written in Haskell(with GUI) and he wants I work on Visual Studio.net to make a GUI in C# and its buttons have to call his Haskell'application . I'm very disoriented and help'needed.Please!! Betty ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.

2 1