November 2004 - Haskell-Cafe

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

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

29 Nov '04

Benjamin wrote (snipped): > Typeable would be completely safe if the only way to declare instances > would be to derive them, but this is only practical if it can be done > from anywhere outside the data type definition. Unfortunately this would also outlaw some legitimate uses of Typeable. In particular, I think you can only derive Typeable for a type constructor of type (*). GHC has recently added Typeable1,Typeable2,... which are classes of type constructors of kind *->*, *->*->* and so on, up to 6 arguments I think, and these can be derived, which is a great help. But there are still kinds this does not include; for example (*->*)->*, which is an example of a type constructor I actually used where I wanted an instance of Typeable.

1 0

Execution Contexts
by Benjamin Franksen 29 Nov '04

29 Nov '04

I finally understood that George Russell's Library is not really about global variables. Rather it is about what I want to call 'execution contexts', which are -- as Marcin Kowalczyk observed -- a restricted form of dynamically scoped variables. [NB: Another (maybe better) name would have been 'execution environment' but the name "environment" is too heavily associated with the related concept of process environment (the string to string map given to user processes as an implicit argument).] An execution context is a mutable finite map from types to (monomorphic) values. Each IO action implicitly carries exactly one such map and by default passes it on to the actions that follow. A function is provided to (implicitly) create a new mapping and run a given IO action with the new mapping as its execution context, instead of the default one. [NB: I also understand now why the library uses ThreadIds. This was obscure to me at first because in principle all this has nothing to do with concurrency (beside the requirement that accessing the context should be thread safe). ThreadIds are used simply because they are available as an index and nothing else is. Its just a hack.] Seen this way, the whole thing smells very much of monads. Indeed, the monadic implementation is trivial. I attached a proof-of concept implementation, using George Russel's 'Dict' as an abstract data type in a separate module (copied verbatim from GlobalVariables.hs, see attached file Dict.hs). The idea: we define type Context = MVar Dict and introduce an eXtended version of the IO monad type XIO a = StateT Context IO a together with a small number of simple functions that implement the same interface as the original GlobalVariables.hs; no unsafe operations are used, everything is Haskell98 + Dynamics. Also ThreadIds do not appear and it is not necessary to change forkIO (apart from lifting it, of course). (code is in ExecutionContext.hs) I modified George's test program so that it works with ExecutionContexts. The program is completely isomorphic to the original (and does the same, too ;). The only major difference is that all IO operations are lifted into the XIO monad. Again, almost everything is Haskell98, -fglasgow-exts is only needed to derive Typeable (which can also be done manually). (Code is in TestExecutionContext.hs) The only task that remains to support this programming style so that it can be used practically, is to redefine IO as XIO in the kernel libraries. The annoying liftIOs everywhere (and the necessity to invent higher order lifts along the way) would be gone. I am almost sure that even the trick of indexing the dictionary via types (and thus the dependency on Data.Typeable and ghc extensions) can be avoided with a little more effort. Ben

5 12

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

27 Nov '04

Benjamin Franksen wrote (snipped): > Doesn't that run contrary to Adrian Hey's "oneShot" example/requirement? Remind me again what Adrian Hey's "oneShot" example/requirement is ... > Well, that's indeed one major problems with global variables. Sure, you can > try to solve it with multiple dictionaries, but that makes understanding what > a certain part of the program does even harder. How do I find out what > dictionary a write or read to a (no longer global) variable refers to? This seems to me as unnecessary as asking for which memory location it has. Provided the no-longer-global variables act as if they were global within their own universe, there is no problem. The withEmptyDict operator I provide gives you a new universe where everything starts from scratch. It seems to me you have a much bigger problem when you force everything to have global variables, and then want to run multiple copies of a program, only to have them clobber each other's variables. > Furthermore, I have great difficulty in understanding why different threads > need different dictionaries. Could you explain why this is useful, or rather, > more useful than a global single dictionary? Consider Data.Unique implemented over lots of processors. If you had a single IORef managed by a single processor used to generate new unique identifiers, there is the danger that that processor will become a bottleneck for the whole system. Much better to have a thread-local or processor-local IORef which generates new identifiers, which you then prepend with a processor tag. Me (snipped): > It is, but I'm not sure if it can be avoided without using stuff not in > the standard libraries. Ben: > What non-standard libraries have I used (that you don't)? OK, but you have to test every element of the dictionary with fromDynamic until you find one with the type you want, which is not a good idea if the dictionary is big. My implementation is equally inefficient now (because TypeRep's have no Ord), but if TypeRep's had Ord or a hashing function (both would be very easy to provide from GHC's implementation) I could make my implementation efficient very easily, while you'd have to completely rewrite yours to get the same effect.

2 4

Re: Lexically scoped type variables
by oleg＠pobox.com 27 Nov '04

27 Nov '04

Simon Peyton-Jones wrote: > In GHC at present, a separate type signature introduces no scoping. For > example: > f :: forall a. a -> a > f x = (x::a) > would be rejected, because the type signature for 'f' does not make > anything scope over the right-hand side, so (x::a) means (x::forall > a.a), which is ill typed. OTH, `f x = (x::a)' will be accepted if this definition appears in an instance declaration, which mentions the type variable `a' somewhere in its `signature'. Incidentally, Hugs differs from GHC in that matter: Hugs considers type variables in an instance declaration just like type variables in a function signature -- having no effect on the local type variables. One might say that Hugs is more consistent in that matter -- OTH, GHC is more convenient, IMHO. The alternative > 1b) It's brought into scope even if the forall is implicit; e.g. > f :: a -> a > f x = (x::a) would seem therefore consistent with the existing behavior of GHC with respect to `instance signatures'. > 2b) Get rid of result type signatures altogether; instead, > use choice (1a) or (1b), and use a separate type signature We can always emulate the result type signatures: that is, instead of writing foo a :: resType = body we can write foo a = result where result body and use "`asTypeOf` result" wherever we need to refer to resType. Or we can write foo a = result where result = cid result cid (_::resType) = body to reduce the result type signature to the argument type signature. OTH, I have personally used result type signatures on many occasions and found them quite helpful. I would be grateful if there were a way to keep them.

2 1