- Haskell-Cafe - Haskell.org

Re: [Haskell-cafe] Non-technical Haskell question
by Keean Schupke 06 Dec '04

06 Dec '04

Looks like your right, I thought cabal was just a library packaging standard, but it appears to have an on-line archive... I guess the real question is, can i do: cabal install <package> (or equivalent) and have all dependancies and the package I want downloaded, configured, compiled, and installed on my system, such that I only have to type the one command and then I can start using the library straight away? (like with install <blah> in CPAN....) Keean. Arthur van Leeuwen wrote: > >Aren't the Hackage and Cabal projects supposed to lead to something >like that? http://www.haskell.org/cabal > >Doei, Arthur. > > >

5 4

Propagating Parsec errors
by Mark Carroll 05 Dec '04

05 Dec '04

Is there a way in Parsec to, within a parser, throw an error generated by another parser? For instance, something of type ParseError -> GenParser tok st a or whatever. -- Mark

3 3

(no subject)
by balarcon＠dsic.upv.es 05 Dec '04

05 Dec '04

Hi, I have to install HDirect on a windows plataform but I have a lot of problems. When I try to install the version 0.21,"make boot" has problems with Happy and I've commented this line(the path is correct),latter "make lib" give 2 errors: ../src/ihc :command not found [hugs/PointerPrim.hs] Error I don't know if this version is for windows too,the 0.16 isn't available in the page.I do the installation with "cygwin" I don't know if it's the best opcion.Please I need use HDirect,help me. Thanks for all, Bea ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.

1 0

maybe IO doesn't suck, but my code does...
by Frédéric Gobry 05 Dec '04

05 Dec '04

Hello, I'm a haskell beginner, and I'm struggling with the following problem: I've started writing a simple apache log file analyzer, but I cannot get rid of important memory usage problems (in fact, at each attempt, I fear I won't be able to unlock my box as my linux 2.6.9 kernel is on its knees, which reminds me on my early days writing C on MMU-less processors... not because of the language of course :-)) Enclosed is a sample code, which aborts on a large (> 100000 lines) file. I tried different variations (readFile $ lines, openFile, openFile + IORef,...) but with no success... So, if the enclosed version is not too far, please give me a hint. Alternatively, if I took the wrong direction, please refocus my search .-) Thanks in advance, Frédéric -- Frédéric Gobry Infoscience DIT-KIS / EPFL Tel: +41216932288 http://people.epfl.ch/frederic.gobry

4 6

more haskell in the news (for nerds)
by isaac jones 04 Dec '04

04 Dec '04

(please followup-to haskell-cafe) This slashdot story mentions Haskell being used to solve puzzles: http://developers.slashdot.org/developers/04/12/04/0116231.shtml?tid=159&ti… I did a quick search on slashdot to discover that Haskell has been in the topic of a slashdot story 4 times in the last 10 months (since march 2003). 5 times if you count a review of "Purely Functional Data Structures". In the year before that, it was mentioned only once in passing. In 2001, it was the topic once, and mentioned once in passing. In 2000 there were several stories on functional programming that mentioned Haskell. Any way you look at it, Haskell has gotten a lot more attention on Slashdot lately than it has since the beginning of the archives. Here's a link to the stories: http://slashdot.org/search.pl?tid=&query=haskell&author=&sort=1&op=stories peace, isaac

1 0

Quzzle
by Thomas Davie 04 Dec '04

04 Dec '04

Hi, Having read an interesting, but simplistic article on the development of Quzzle in Haskell on slashdot (http://developers.slashdot.org/article.pl?sid=04/12/04/ 0116231&threshold=1&tid=159&tid=156). I was wondering if anyone knew of any more in depth reviews of what Jim Lewis did to create the puzzle. Is there a paper available on it? Thanks Tom Davie -- Computer Science is as much about computers as astronomy is about telescopes -- Edsgar Dijkstra

1 0

Re: [Haskell-cafe] Non-technical Haskell question
by Keean Schupke 04 Dec '04

04 Dec '04

Some of the features they are adding to c# are pretty cool. Nothing you can't do in Haskell, but it does have the advantage of familiar syntax. On the other hand they say it is easier to teach functional programming to people who have never programmed before. I was of course thinking of how to persuade someone to adopt Haskell as yet another programming language. Marc Charpentier wrote: > On 3 déc. 2004, at 17:18, Keean Schupke wrote: > > Its not yet another programming language - it's the future and you > don't want to be left behind... > > Keean. > > > But Erik Meijer wrote (http://blogs.gotdotnet.com/emeijer/) > > " Pure functional programmers, your days are numbered. The grim reaper > is knocking at your door." > > :-/ > > > > > Marc Charpentier

2 1

Classes in type declarations in Hugs
by John Goerzen 04 Dec '04

04 Dec '04

Hello, I have this line: type CPResult a = MonadError CPError m => m a GHC (with various command-line options I'm already using) compiles this fine. hugs, with -98 +o, complains: Syntax error in input (unexpected `=>') How do I make this work both places?

3 3

Top-level state debate on the wiki
by George Russell 03 Dec '04

03 Dec '04

Ben Rudiak wrote (snipped): > I put up a wiki page summarizing the main proposals for top-level > mutable state. The type-dictionary approach isn't there yet, but there's > a space for it; I'll probably fill it in within the next 24 hours unless > someone else feels like doing it first. > > Please add more detail, objections, examples. Especially examples! > > Here's the page: > > http://haskell.org/hawiki/GlobalMutableState I have added a summary of the type-dictionary approach. I recommend other people look at this page and, if there is something they disagree with, amend it so that their own view is reflected. IMO the WiKi approach is an excellent way of obtaining consensus and providing an overview of the topic.

5 4

problem building hmake on Mac OS X
by Steven Elkins 03 Dec '04

03 Dec '04

Hello everyone, I'm trying to build hmake on version 10.3.6 of Mac OS, having installed the ghc 6.2.2 dmg I found on haskell.org, but I'm encountering the following problem: Steven-Elkins-Computer:~/haskell/hmake-3.09 sge$ make cd src/hmake; make HC=ghc all config /Users/sge/haskell/hmake-3.09/lib/powerpc-Darwin7/config:9: *** missing separator. Stop. make: *** [targets/powerpc-Darwin7/hmake-ghc] Error 2 Here's lib/powerpc-Darwin7/config: Steven-Elkins-Computer:~/haskell/hmake-3.09 sge$ cat lib/powerpc-Darwin7/config BUILDWITH=ghc BUILDOPTS="" INSTALLVER="3.09 (2004-11-13)" INSTALLINFO="config: powerpc-Darwin7/ by sge(a)Steven-Elkins-Computer.local on Thu Dec 2 04:43:46 EST 2004" BUILDBASEDIR=/Users/sge/haskell/hmake-3.09/targets READLINE="-DUSE_READLINE=1 -lreadline" EXE= GHCSYM=#pragma GCC set_debug_pwd "/Users/sge/haskell/hmake-3.09" 602 TRUE=/usr/bin/true In case Gmail wraps this, line 9 has the oracular '602'. Finally, here's the ./configure output: Steven-Elkins-Computer:~/haskell/hmake-3.09 sge$ ./configure --prefix=/usr/local Configuring for hmake... [ 3.09 (2004-11-13) ] -------- Looking for already-installed Haskell compilers: Looking for hbc... (not found) Note: LMLDIR/HBCDIR variables must be set to enable detection of hbc. Looking for ghc... found 6.2.2 Looking for nhc98... (not found) I am guessing that you want to use ghc to build hmake. Now I'm creating targets/powerpc-Darwin7/hmake3.config for your installation. Done. -------- Configuration report for hmake. (You can re-run configure to change settings before proceeding.) You wish (eventually) to install the following components in these locations: (Installation directories are not created/checked at this stage.) Final install root: /usr/local hmake binaries: /usr/local/lib/hmake/powerpc-Darwin7 Scripts: /usr/local/bin Man pages: /usr/local/man/man1 Now we check/create your build directories: Config directory: targets/powerpc-Darwin7 Build directory root: /Users/sge/haskell/hmake-3.09/targets (exists) Object files build in: /Users/sge/haskell/hmake-3.09/targets/powerpc-Darwin7 (exists) Executables and libs: /Users/sge/haskell/hmake-3.09/lib/powerpc-Darwin7 (created) I have guessed you will build hmake with: ghc Testing for the curses library: -lncurses (detected) Testing for the readline library: -lreadline (detected) Executables need .exe suffix? no (detected) Found /usr/bin/true not /bin/true Adding Makefile config script to /Users/sge/haskell/hmake-3.09/lib/powerpc-Darwin7... Adding build scripts for hmake, hmake-config, and hi to /Users/sge/haskell/hmake-3.09/script... Updating targets/powerpc-Darwin7/hmake3.config... Saving current configuration in targets/powerpc-Darwin7/config.cache Done. Steven-Elkins-Computer:~/haskell/hmake-3.09 sge$ Thanks, Steve

3 4

RE: [Haskell-cafe] Re: Non-technical Haskell question
by Simon Peyton-Jones 02 Dec '04

02 Dec '04

| I also have a very small start on a "haskell for hackers" ("hackers" in | the non-evil sense) sort of document. One this doesn't ignore I/O as | "hard" or "unimportant". I/O in Haskell doesn't suck. It's just that a | lot of people in the community don't have it as a high priority, I | think. As a shameless plug, have you tried "Tackling the awkward squad?". Indeed I/O in Haskell doesn't suck. http://research.microsoft.com/%7Esimonpj/papers/marktoberdorf Simon

2 1

Top-level state debate on the wiki
by Ben Rudiak-Gould 02 Dec '04

02 Dec '04

I put up a wiki page summarizing the main proposals for top-level mutable state. The type-dictionary approach isn't there yet, but there's a space for it; I'll probably fill it in within the next 24 hours unless someone else feels like doing it first. Please add more detail, objections, examples. Especially examples! Here's the page: http://haskell.org/hawiki/GlobalMutableState (It also includes an explanation of why I chose that title, though of course you're welcome to dispute that too.) -- Ben

6 10

memory leak in Random.randoms or makeList?
by S. Alexander Jacobson 01 Dec '04

01 Dec '04

Using ghci, I am getting this error message: *Main> timeOp $ print $ sizeFM bigFM' GHC's heap exhausted: current limit is 268435456 bytes; >From this code: makeList x = map ((\x->x `mod` range).abs) $ Random.randoms (Random.mkStdGen x)::[Int] range=100000 fmRecords' n = listToFM $ take n $ zip (makeList 100) (makeList 200) fmRecords n = listToFM $ take n $ zip [range..] [range..] fmSize=10^6 bigFM = fmRecords fmSize bigFM' = fmRecords' fmSize bigFM works fine so the leak is obviously within makeList. I just don't understand how makeList could produce this error... -Alex- ______________________________________________________________ S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com

1 0

Forcing type conversion - probably FAQ(?)
by Dusan Kolar 01 Dec '04

01 Dec '04

Hello, I'm trying to make work the following code (I'm using GHCi with flags -fglasgow-exts -fallow-undecidable-instances): infixl 6 :+, :- infixl 6 .+, .- data TMyExpr = TMyExpr :+ TMyExpr | TMyExpr :- TMyExpr | Val Int | Id String class MkExpr a b where (.+) :: a -> b -> TMyExpr (.-) :: a -> b -> TMyExpr instance MkExpr Int Int where (.+) a b = (Val a) :+ (Val b) (.-) a b = (Val a) :- (Val b) instance MkExpr Int TMyExpr where (.+) a b = (Val a) :+ b (.-) a b = (Val a) :- b instance MkExpr TMyExpr Int where (.+) a b = a :+ (Val b) (.-) a b = a :- (Val b) instance MkExpr TMyExpr TMyExpr where (.+) a b = a :+ b (.-) a b = a :- b It compiles fine, no problem. Nevertheless, writing (3::Int) .+ (4::Int) seems to me quite clumsy, but 3 .+ 4 does not work. :-( It says the 3 is from class Num and no variant is present for it, I know, it is not present, but how to force it to convert it to Int "automatically"? When I try to incorporate instance (Num a, Num b) => MkExpr a b where (.+) a b = (Val . round a) :+ (Val . round b) (.-) a b = (Val . round a) :- (Val . round b) the situation is even worse. :-( I tried several modifications, but they don't work either. :-\ I was trying to find the discussion (I wonder whether it went on the similar topic through the list recently), but failed. :-( If someone can just point me to any resource I could study the possible solutions - maybe I put wrong data to google. ;-) Or just to stop me, if I'm trying to do impossible... :-\ Thx, Dusan

2 1

Re: [Haskell-cafe] Re: ACIO versus Execution Contexts
by Adrian Hey 01 Dec '04

01 Dec '04

On Tuesday 30 Nov 2004 3:02 pm, Lennart Augustsson wrote: > I reiterate: not even device drivers written in C use TWIs. > (Well, at least not quality drivers. :)) A finite pool of N devices is still a unique resource. Ultimately you have to contain the problem locally with a modular solution, or all the unique state handle "buck passing" to higher levels (via who knows what intermediate modules) takes you all the way up to main. This is technically feasible, but highly un-modular and certainly not a desirable characteristic of any programming language (at least not one whose use I would advocate). Regards -- Adrian Hey

3 5

Rank-2 types and class constraints
by Stefan Holdermans 01 Dec '04

01 Dec '04

Hi, Just out of curiosity (I cannot come up with a practical example): Why doesn't the following piece of code type check in GHC (with extensions)? > foo :: (forall a . (Eq a) => a) -> Integer > foo = undefined It seems like the type-class constraint is playing a decisive rôle here, since the following does check. > bar :: (forall a . a) -> Integer > bar = undefined TIA, Stefan

2 1

Re: [Haskell-cafe] Re: ACIO versus Execution Contexts
by MR K P SCHUPKE 01 Dec '04

01 Dec '04

Actually I now think that not only are top level TWIs okay, I can get extra contexts by rewriting the MVar module. Here I can create a TWI in the new MVar module called context, and all mvar writes and reads would be parameterised by context. In this way I can change the context then call oneShot and get it to run a second (or as many times as I like)... So that gets round my last remaining objection to top level MVars. This also shows that top level TWIs and the Execution contexts are effectively the same thing... but I guess TWIs have a nicer syntax... Keean.

1 0

Re: ACIO versus Execution Contexts
by George Russell 01 Dec '04

01 Dec '04

Adrian wrote (snipped): > But if top level MVars are all that's on offer I'd settle for that :-) > I can still implement my "oneShot" examples just by passing the top > level MVar as an argument to oneShot rather than having it create its > own. I am not sure which the oneShot examples are, but I suspect you can implement them just as well using the execution contexts I have proposed. If you want to be sure your data will not be clobbered by other modules, simply wrap the state in special type, and make sure no-one else has access to that type. This requires no change to the Glasgow Haskell language at all, only a new library module. I suppose it may happen that you are worried about someone using withEmptyDict to create an inner execution context where everything starts from scratch, because you want to interface with broken C libraries which are stateful. However since this is a problem caused by broken C libraries rather than anything in Haskell, surely it would be better to support this by providing a global dictionary to be used in such exceptional cases, while leaving execution contexts the preferred tool in the Haskell world.

1 0

ACIO versus Execution Contexts
by George Russell 01 Dec '04

01 Dec '04

I think it would be nice to summarise the current state of play. This really needs to be a WiKi. Ian's ACIO proposal http://www.haskell.org//pipermail/haskell-cafe/2004-November/007680.html seems in fact to achieve much the same as the proposal I originally posted to http://www.haskell.org//pipermail/haskell/2004-November/014894.html and which Benjamin Franksen has explained and simplified here http://www.haskell.org//pipermail/haskell-cafe/2004-November/007691.html You can in fact do much the same with both. With Haskell 98, Data.Dynamic and ACIO and, if your implementation has concurrency at all, thread identifiers, I can implement execution contexts. On the other hand ACIO allows you to create variables with top-level declarations such as x <- newIORef 0 which can then be accessed in a pure way. With Execution Contexts you cannot do this; you would instead need a function getX :: IO (IORef Int) which would get the global variable x. In practice I don't think this distinction very important, since there's not much you could do with x except using the IO monad. Disadvantages of execution contexts ----------------------------------- 1. You are only allowed one value of each type in an execution context. Thus it is dangerous to try to use a global value of type (IORef Int); people would have to be advised to create a special newtype for each value. 2. They are likely to be less efficient than just allowing <- declarations at top level. Certainly they are in my implementation. The vast majority of this inefficiency can be eliminated by using hash tables, but you can't escape doing at least one hash-table lookup each time you want to access a global value. The bare minimum then would be one division by a constant followed by an indirection. 3. In a concurrent system, you also need forkIO to be modified, so that you can work out which execution context applies to you. Disadvantages of ACIO --------------------- 1. The ACIO proposal preserves one bad feature of unsafePerformIO, namely that you only have one "execution context". You cannot for example run two copies of the same program simultaneously, since they will clobber each other's global variables. 2. I don't know exactly how ACIO is to be implemented, but it looks as if at the least it requires an extension to the Haskell syntax. 3. I think that if the ACIO proposal were implemented, it would in any case be a good idea to implement execution contexts or something like them on top of it, so that people can create initialisation actions which do other things than the very strict subset allowed as ACIO actions. Questions --------- 1. Is there anything people would like to do with ACIO for which execution contexts would not be practical? 2. Which if either of the proposals would the gods responsible for implementing Haskell compilers favour?

6 9

RE: [Haskell-cafe] ACIO versus Execution Contexts
by Simon Peyton-Jones 01 Dec '04

01 Dec '04

| I think it would be nice to summarise the current state of play. This really | needs to be a WiKi. Thanks for the summary, George. | 2. Which if either of the proposals would the gods responsible for implementing | Haskell compilers favour? Rather than remain completely silent on this topic let me say that (a) I'm totally snowed under at the moment, at least partly with GHC stuff (Template Haskell, GADTs etc); (b) there has been so much traffic on this global variable topic that I've stopped reading it carefully. This isn't because I think it's unimportant or boring, but rather because I'm hoping that someone will eventually emit a summary that really does boil out the main issues, so that everyone else can benefit from the fruits of your (plural) labours. The idea would be that everyone else can just read the summary without reading the thread. A Wiki would be good. (c) I have the impression that there's still quite a bit of active discussion; convergence is not achieved (d) I'm not averse to changing GHC in some way, but big changes (e.g top level <-) would need a jolly persuasive argument and solid consensus. Smaller changes (e.g. a robust promise about top-level newMVars) are easier of course. (e) FWIW, as Simon has remarked, we're busy eliminating top-level global MVars from GHC. The really persuasive use I know for them is to implement semantically-pure but implementationally impure things like memo tables. Simon

2 1

not possible with monad transformers ?
by Pavel Zolnikov 01 Dec '04

01 Dec '04

Hi, I have been playing with Maybe and Output monad transformers and realized that I cannot make the following work nicely: > foo a b = do > output "before" > r <- (liftM2(+)) a b > when r == Nothing $ output "error" > return r As soon as computation produces Nothing, I am loosing ability to do any output. I think what I need is not wrapping one monad into another with transformer; I need some sort of monad combiner: > newtype MC m1 m2 = MC (m1 a, m2 b) So I could execute both of monads ‘in parallel’. But I have no idea how to express this or even if this is doable at all. Any comments? Thanks, Pavel. P.S. Here is summary of what I tried with transformers so far: Let’s say I have following monad transformers: > newtype MaybeMonadT m a = MMT (m a) > newtype OuptutMonadT m o a = OMT (m a, o) And I am trying to use following monads: > type M1 a = MaybeMonadT OutputM a > type M2 a = OuptutMonadT Maybe String a Now, they both won’t quite work in the following example: > foo a b = do > output "before" > r <- (liftM2(+)) a b > when r == Nothing $ output "error" > return r In case of M1, as soon as I get Nothing in r, computation will stop and return without any output gathered. In case of M2, as soon as I get Nothing in r, computation will stop and return only with output gathered so far. That is > output "error" will never be called.

7 11

Re: [Haskell-cafe] Equality of functions
by oleg＠pobox.com 01 Dec '04

01 Dec '04

Jules Bean wrote: > From the point of view of a programmer, that's all there is to it: > there is no way of proving two functions are the same except by > exhaustively checking every input. That is too pessimistic, I'm afraid. There is also an intensional equality. Granted, it can be sound but never, in general, complete (although it can be total). That is, if the comparison function returns True, then the arguments truly denote the same, identically the same function. If the answer is False, well, we don't know. The arguments may still denote the same function. Here's one example of intensional comparison: > import Foreign > > comp a b = > do > pa <- newStablePtr a > pb <- newStablePtr b > let res = pa == pb > freeStablePtr pa > freeStablePtr pb > return res *FD> comp id id >>= print True *FD> comp undefined id >>= print False *FD> comp undefined undefined >>= print True This function lives in the IO monad, where it should stay because it destroys free theorems. It is quite equivalent to Scheme's eq? predicate. For some -- wide -- classes of functions, it is possible to define a pure functional intensional comparison. For example, a recent message http://www.haskell.org/pipermail/haskell/2004-November/014939.html demonstrated the reconstruction of (even compiled) numerical functions. So, one can define intensional equality of two numeric functions as structural equality of their reconstructed representations. Alas, this comparison function can't be total: bottom is beyond comparison.

2 1

Equality of functions
by Adam Zachary Wyner 01 Dec '04

01 Dec '04

Hi All, After some weeks of experimenting and digging around, I understand that functions cannot be compared for equality. Thanks to Bjorn Lisper for pointing this out. I basically understand (?) the underlying mathematical issue, which is that functions in general may have infinite domains and ranges. For example, a function f, which gives the successor of an integer, x + 1, could not be compared to a function g, which gives the predecessor of an integer which has 2 added, (x + 2) - 1, even though these two functions give exactly the same result on all arguments, because we would have to compare them on all possible values for x. Question -- is this all there is to the issue, or is there something more? Apologies in advance for not understanding the math better here. Question -- though Haskell, as a lazy language, does not otherwise have problems with infinite lists, why does it here? Question -- is there some way around this problem? It is very handy to be able to have a variable over functions and then compare the value to a designated function. This would let me say things like: when variableFunctionX == functionA then.... otherwise etc... One possible (dirty?) solution I thought up is to use the record types of Hugs to correlate the function with a name of type String: type FunctionNameFunction = Rec (functionName :: String, functionFunction :: WhateverFunction) Then, whenever one needs to use the function, one uses the value of functionFunction, but whenever one needs to evaluate for identity, one uses the value of functionName, using just string identity. Of course, this makes lots of things less 'pretty' (to apply a function to an argument, one has to first 'pull out' the function from the record), but it addresses a general problem. One would also have to keep careful track of which functionNames correlate with with functionFunctions. Other suggestions? Cheers, Adam

6 6

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

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

Re: [Haskell] Real life examples
by Keean Schupke 26 Nov '04

26 Nov '04

I've replied to the cafe, as per requests... Peek and poke are instances of the Storable class, I can re-implement storable, and provide the alternative definition by giving ghc some -i<something> arguments. I don't even need to recompile your module, simply providing the alternate Storable module at link time is sufficient. So I restate my point, it _can_ be done in Haskell as it stands at the moment, and yor proposal would break this. Keean. Adrian Hey wrote: >On Friday 26 Nov 2004 11:39 am, Keean Schupke wrote: > > >>Adrian Hey wrote: >> >> >>>Well it can be written in Haskell, but not using a module that was >>>specifically designed to prevent this. >>> >>> >>Well, It can be written in Haskell as it stands at the moment... >> >> > >No it can't. If I have a device driver that's accessing real hardware >(peeking and poking specific memory locations say), how are you going >to emulate that? You need to make peek and poke parameters of the >module. > >That is certainly possible, but if the author of the driver module >didn't anticipate your emulation needs, you'd be stuck I think. > >Regards >-- >Adrian Hey > > >_______________________________________________ >Haskell mailing list >Haskell(a)haskell.org >http://www.haskell.org/mailman/listinfo/haskell > >

2 4

Re: Yet another IO initializer: Effectful declarations and an ACIO monad
by George Russell 26 Nov '04

26 Nov '04

Ian Stark wrote (snipped): > Way back in this thread, Koen Claessen mentioned the idea of a commutative > version of the IO monad for handling things with identity. That doesn't quite > do it, but I have a refinement that might. The thing is to focus on IO > computations that are: > > a) central -- their effect commutes with every other IO action > b) affine -- their effect is not directly observable, and can be discarded. Unfortunately I have a number of examples where I use global variables with initialisation actions which cannot conceivably be proven to be central & affine by the compiler. For example, where I want to call up an external program (such as wish) which I will later use for doing graphics. The Haskell libraries would run into a similar problem when they tried to open stdin/stdout/stderr. Or indeed when they tried to implement RandomGen, which I presume is going to want to get at the system clock to seed the random number generator. My guess is that if we were to have top-level <- actions where the actions were restricted to those certified to be ACIO, it would not be very long before GHC would implement an unsafeForceACIO function ...

3 4

[Haskell] Lexically scoped type variables
by Martin Sulzmann 26 Nov '04

26 Nov '04

Hi, let me answer your questions by comparing what's implemented in Chameleon. (For details see http://www.comp.nus.edu.sg/~sulzmann/chameleon/download/haskell.html#scoped) > ---- QUESTION 1 ----- > > In short, I'm considering adopting the Mondrian/Chameleon rule for GHC. > There are two variations > > 1a) In the example, 'a' is only brought into scope in the > right hand side if there's an explicit 'forall' written by > the programmer > 1b) It's brought into scope even if the forall is implicit; e.g. > f :: a -> a > f x = (x::a) > > I'm inclined to (1a). Coments? > Currently, Chameleon goes for 1b), i.e. foralls are implicit. I agree that 1a) might help the programmer to immediately see which variables are bound by the outer scope. > > ----- QUESTION 2 ------ > > [...] > > The alternatives I can see are > > 2a) Make an arbitrary choice of (A) or (B); GHC currently chooses (B) > 2b) Decide that the scoped type variables arising from pattern > bindings scope only over the right hand side, not over > the body of the let > 2b) Get rid of result type signatures altogether; instead, > use choice (1a) or (1b), and use a separate type signature > instead. > > Opinions? > Chameleon goes for 2c) A Chameleon speciality is that we can write f ::: a->a f x = True f ::: a->a states that f has type a->a for some a. ::: follows the same scoping rules as :: Then, the following statement let f (x::[a],ys) = <rhs> in <body> (I assume that x::[a] states here that x has type [a] for some a) can be encoded as let f ::: ([a],b)->c f (x::[a],ys) = <rhs> in <body> The main motivation behind Chameleon's lexically scoped annotations was to allow for programs such as class Eval a b where eval::a->b f :: Eval a (b,c) => a->b f x = let g :: (b,c) g = eval x in fst g As Josef pointed out, there are also examples where it might be useful that some inner annotations refer to variable a from the outer annotation. Martin

1 0

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

26 Nov '04

Marcin wrote (snipped): > I think global variables are a lot less evil if they behave as if they > were dynamically scoped, like Lisp special variables. > > That is, there is a construct which gives the variable a new mutable > binding visible in the given IO action. It's used more often than > assignment. Assignment is still available though. I agree entirely. The fact that declaring global variables using unsafePerformIO introduces an artificial notion of "global" and forces it on every part of the program is a major disadvantage which we haven't heard enough about in this discussion. It prevents you doing all sorts of things. It's bad for parallelism. It prevents you running two independent copies of a (main) action. It prevents you writing a Haskell controller which runs over Haskell actions as subprograms.

1 0

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

25 Nov '04

> This is funny. When I got no immediate reaction from you, I started > implementing it myself. I ended up with something similar. It has less > features but is also a lot simpler. This is the interface: > > initGlobal :: Typeable a => a -> IO () > getGlobal :: Typeable a => IO a Your implementation is probably much simpler than mine because you don't implement withEmptyDict. I'm really quite keen about withEmptyDict, because one of the MAJOR conceptual problems I have with unsafePerformIO global variables is that you only get one universe, corresponding to the Haskell program. There shouldn't really be a single "the Haskell program" anyway; imagine something like GHC or an operating system written in Haskell which run sub-systems which require their own global variables. Or imagine a program split between lots of processors where, for efficiency reasons, you don't want everyone to have to refer to the same set of global variables.o > Storing (TypeRep,Dynamic) pairs is redundant, since Dynamics already > contain their own TypeRep (that is how they are made to work). It is, but I'm not sure if it can be avoided without using stuff not in the standard libraries. > I also use a list for the dictionary; and I share your view about > TypeRep badly needing an Ord instance (probably trivial to provide > but I could be wrong). Even better would be a hashable integer. TypeRep actually is implemented internally on GHC using a hashcons'd unique integer, so exposing it should be trivial ...

3 2

Interview with David Roundy on darcs and Haskell
by Josef Svenningsson 25 Nov '04

25 Nov '04

Hi all, At osdir there is a nice interview with David Roundy about darcs, the revision control system written in Haskell. He has a few comments about Haskell as well. Read it here: http://osdir.com/Article2571.phtml This was also covered on /. (which is where I found it). /Josef

1 0

Yet another IO initializer: Effectful declarations and an ACIO monad
by Ian.Stark＠ed.ac.uk 25 Nov '04

25 Nov '04

Way back in this thread, Koen Claessen mentioned the idea of a commutative version of the IO monad for handling things with identity. That doesn't quite do it, but I have a refinement that might. The thing is to focus on IO computations that are: a) central -- their effect commutes with every other IO action b) affine -- their effect is not directly observable, and can be discarded. Thus an element u of (IO a) is affine central if for all v::IO b and w::IO c, do { x <- u; v } = v (affine) do { x <- u; y <-v; w } = do { y <- v; x <- u; w } (central) where '=' is observational equivalence. For example, we would expect newMVar x :: IO (MVar a) to be affine central; similarly newIORef, and newStdGen for random number generators. If we define an ACIO monad for affine central IO expression, then we can safely use these in toplevel declarations: declare x <- u -- x::a, u::ACIO a declare count <- newIORef 0 -- count :: IORef Int declare flag <- newMVar True -- flag :: MVar Bool The semantics of such declarations would be to gather them all to the start of a program, whose meaning is now do { declarations; main } Because all declarations are ACIO: they can appear anywhere in the source; be executed at any point between the start of the program and the use of their value; and if there is no such use, need never be executed at all. In any event, the right-hand side of each declaration will be evaluated, and perform its side-effect, at most once. The declared values (x, count, flag) are pure values and do not have IO types. However, almost all their uses (bumping the counter, reading the flag) will live in the IO monad. Like stdIn and stdOut. Also, just because these declarations are toplevel doesn't mean they are globally visible: they are lexically scoped within standard module namespaces. I conjecture that when used "safely" the {-# NOINLINE #-} unsafePerformIO idiom is in fact being applied to IO expressions that are affine central; which means they could be put in ACIO and used as declarations instead. -- Ian Stark http://www.ed.ac.uk/~stark LFCS, School of Informatics, The University of Edinburgh, Scotland

2 2

RE: [Haskell] Lexically scoped type variables
by Josef Svenningsson 25 Nov '04

25 Nov '04

Let me just begin by sharing my experience with scoped type variables. I've found them very useful in a project were I was to generalize a substantial code base. Many of the functions had local definitions whose type were simply not expressible without scoped type variables. During this work I found an interesting interplay between multi parameter type classes and scoped type variables. An example would look something like this: f :: C a b c => a -> b f a = .... let g = ... The important thing to note is that the type variable c in f's signature occurs neither in the argument nor the result type of f. Hence c is not bindable by lexically scoped type variables. But suppose c is part of g's type. Then we still have no way of expressing g's type! This thing has bitten me and so I welcome the change you're planning. As for your questions I would prefer 1b although I don't think it is a big deal. For your second question I would go for 2c (which you've called 2b :). That's because I don't use result type signatures. Other people will surely disagree. Cheers, /Josef > -----Original Message----- > From: haskell-bounces(a)haskell.org [mailto:haskell-bounces@haskell.org] On > Behalf Of Simon Peyton-Jones > Sent: den 25 november 2004 11:44 > To: haskell(a)haskell.org > Subject: [Haskell] Lexically scoped type variables > > | This is a great example, thanks for posting it. However, I feel like > | the real problem in this example is the lexically-scoped type > | variables declared with your function f. > > Paul's message gives me an excuse to consult the Haskell list about the > design of lexically scoped type variables. I have a two particular > questions I'd like your advice about. (This is nothing to do with > monomorphism restriction, or Lennart's original puzzle.) > > I'm sending this message to the main Haskell list, to maximise > readership, but I suggest that > > you reply to haskell-cafe(a)haskell.org > > Thereby to avoid spamming the main Haskell list, which is meant to be > low-bandwidth. I believe I've set the reply-to field of this message to > achieve this goal. [Perhaps others can do the same?!] > > Simon > > ---- Background ---- > > First, for background you might want to glance at "Lexically scoped type > variables", an unpublished paper available at > http://research.microsoft.com/%7Esimonpj/papers/scoped-tyvars > I don't want to take time in this message to discuss why we want scoped > type variables; I'll just take it for granted here. > > One design choice discussed in the paper, and implemented in GHC, is > that we can bring new lexically-scoped type variables into scope by > mentioning them in a pattern type signature: > f (x::a) = .... > Here 'a' is a name for the type of x, and 'a' scopes over f's body, and > can be mentioned in type signatures in f's body. Sometimes one wants to > name types in the result* of f, rather than it its *arguments*. For > example > head (xs::[a]) :: a = ... > Here, the ":: a" before the "=" gives the type of head's result. If a > result type signature binds a type variable, that type variable scopes > over the right hand side of the definition. > > In GHC, it's not necessary for the type that 'a' names to be a type > variable; it could be Int, for example: > f (x::a) = x + (1::Int) > Already this embodies several design choices. For example, we know that > 'a' is a *binding* for 'a' because there is no 'a' already in scope, > otherwise it'd be an *occurrence* of 'a'. (An alternative would be to > mark binding sites somehow.) Also once could require that 'a' names a > type variable rather than an arbitrary type. But for this message I > want to take GHC's design as given. > > ---- QUESTION 1 ----- > > 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. > > An obvious alternative, taken up by (among others) Mondrian and > Chamaeleon, is to say that > > the top-level quantified variables of a separate type signature > scope over the right hand side of the binding > > In the above example, then, the 'a' bound by the 'forall' would scope > over the right hand side of 'f'. > > I've argued against this in the past, because the construct (forall a. > <type>) patently scopes 'a' only over <type>. But my resolve is > weakening. It's just too convenient! Furthermore, it binds a *rigid* > type variable (i.e. 'a' really must name a type variable) and that's > important for GADTs... which strengthens the case. > > In short, I'm considering adopting the Mondrian/Chameleon rule for GHC. > There are two variations > > 1a) In the example, 'a' is only brought into scope in the > right hand side if there's an explicit 'forall' written by > the programmer > 1b) It's brought into scope even if the forall is implicit; e.g. > f :: a -> a > f x = (x::a) > > I'm inclined to (1a). Coments? > > > ----- QUESTION 2 ------ > > Question 2 concerns degenerate bindings. First, consider pattern > bindings. For example: > let > (x::[a], y) = <rhs> > in <body> > The LHS of the let-binding is a pair, so it's called a pattern binding. > What should the scope of 'a' be? GHC's current story is that "it is the > same as the scope of term variables bound in the same pattern", so just > as 'x' scopes over both <rhs> and <body>, so does 'a'. And that in turn > means that we can't generalise over 'a', so 'x' is monomorphic. > > An alternative would be to say that type variables bound in a pattern > binding scope only over the right-hand side. > > ---- The degenerate case: variable bindings ---- > > Now the nasty case > > let > f :: a -> a = \x -> x > in (f True, f 'c') > > Is the binding for 'f' > (A) a (degenerate) function binding no arguments, but with a > result signature? > or (B) a (degenerate) pattern binding with pattern (var::type)? > > If we consider it to be (A) then arguably 'a' scopes only over the > right-hand side, and f gets the polymorphic type (forall a. a-> a). > > If we consider it to be (B) then currently 'a' scopes over the right > hand side and the body of the let, so 'f' has to be monomorphic, with > type ty->ty for some ty; and no ty will do, so the program is rejected. > > The trouble is that the binding is patently *both* (A) and (B). This > gives no difficulty in Haskell 98, because there's no difference in > treatment; but GHC's current rules for scoped type variables do > distinguish the two. > > The alternatives I can see are > > 2a) Make an arbitrary choice of (A) or (B); GHC currently chooses (B) > 2b) Decide that the scoped type variables arising from pattern > bindings scope only over the right hand side, not over > the body of the let > 2b) Get rid of result type signatures altogether; instead, > use choice (1a) or (1b), and use a separate type signature > instead. > > Opinions? > > > > _______________________________________________ > Haskell mailing list > Haskell(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell

1 0

Re: Global Variables and IO initializers
by Benjamin Franksen 25 Nov '04

25 Nov '04

[encouraging everybody to reply on haskell-cafe] On Tuesday 23 November 2004 12:02, you wrote: > Thanks to the encouraging post > > http://www.haskell.org//pipermail/haskell/2004-November/014748.html > > from Benjamin Franksen, I have implemented > my proposal which allows the user to define new global variables without > unsafePerformIO, NOINLINE and other such horrors. This is funny. When I got no immediate reaction from you, I started implementing it myself. I ended up with something similar. It has less features but is also a lot simpler. This is the interface: initGlobal :: Typeable a => a -> IO () getGlobal :: Typeable a => IO a Some remarks: o The separation into two modules is only historical. o I use an MVar internally, not an IORef; since it is not exposed, no indefinite blocking can occur. It's just a mutex around the dictionary. o Storing (TypeRep,Dynamic) pairs is redundant, since Dynamics already contain their own TypeRep (that is how they are made to work). o Both our implementations use unsafePerformIO in an unsafe manner, which is why the NOINLINE flag is used. o I also use a list for the dictionary; and I share your view about TypeRep badly needing an Ord instance (probably trivial to provide but I could be wrong). *************** On a related note, there was some discussion recently about which IO actions should be considered as 'harmless' so that they are allowed for the proposed top-level '<-' bindings, and how to characterize them in an elegant way. Here is yet another solution: The only things allowed at top-level (other than pure values) will be unique labels (such as provided by Data.Unique). Then we take all the newXXX actions out of whatever monad they live in and provide them as pure functions that take a Unique as additional argument: newXXX :: Unique -> a -> XXX a This might be a bit tricky to do efficiently. Anyway, a Haskell program could then create top-level Unique labels instead of top-level XXX vars: myGlobalVarLabel <- unique myGlobalMVar = newMVar myGlobalVarLabel "initial content" The concrete syntax could be made even simpler (and clearer), i.e. without the '<-' operator: unique myGlobalVarLabel Advantages: o No question of what is in SafeIO and what is not. o No question of when top-level IO actions are performed. *************** Now what about combining the two aproaches? The point here is that in Haskell we can easily create new unique labels at the top-level without resorting to any kind of unsafe operations: data Uniq1 = Uniq1 data Uniq2 = Uniq2 ... Only these have not the same but different types. So we need a way to map them to a single type in such a way that their uniqueness is preserved. We already have such a tool and it is called "deriving Typeable": unique = typeOf type Unique = TypeRep data Uniq1 = Uniq1 deriving Typeable data Uniq2 = Uniq2 deriving Typeable Our unique labels can now simply be defined as label1 = unique Uniq1 label2 = unique Uniq2 and our global variables as global1 = functionalNewMVar label1 True global2 = functionalNewMVar label1 (117::Int) I think this is most elegant, although there remains the questions of an efficient implementation of functionalNewXXX. Ben

3 4

Re: [Haskell] Top Level TWI's again
by Benjamin Franksen 24 Nov '04

24 Nov '04

[for the third time moving this discussion to cafe] On Tuesday 23 November 2004 20:20, Aaron Denney wrote: > [...about std file handles...] > They're wrappers around the integers 0, 1, and 2. The handles could > have been implemented to be the same, at each invocation. (I expect > they are in most implementations). If we had to make them ourselves, > they could be done as: > > stdin = makeHandle 0 > stdout = makeHandle 1 > stderr = makeHandle 2 > > in absolutely pure Haskell, only the things that manipulate them need > be in the IO monad. If they were simple wrappers around the integers, you'd be right and I couldn't rightfully object to them being top-level values. I don't like it but I have to admit that (although hypothetical) this invalidates the argument I gave against them being top-level things ;-( My only rescue is to shift the blame on the OS. Indeed it is quite debatable whether the raw file descriptor API is a good one. Does it make sense that you can, e.g. swap stdin and stdout? It doesn't seem right to me that file descriptors are reused at all. I think file handles should be completely abstract. Also I would rather have separate types for Input, Output, and RandomAccess Streams, although they might of course share some methods via type classes. I am currently taking a look at Simon Marlow's new_io library that seems to do just that (and a lot more). > >> Keeping them outside the IO monad, and only accessing them inside -- > >> i.e. the current situation -- would be fine. > > > > I beg to differ. Note, I do not claim they are unsafe. > > If it's not unsafe, and it makes for simpler (hence easier to > understand, create, debug, and modify) in what sense is it not fine? I don't buy the "easier to understand, create, debug, and modify" part if it comes to global variables. Not everything that makes things simpler at first, is also good for long-term maintenance, and global variables have accumulated quite a bad reputation in this regard. > >> They're not mutable in any sense. > > > > Well, a variable in C is not mutable in exactly the same sense: It always > > refers (="points") to the same piece of memory, whatever value was > > written to it. Where does that lead us? > > A slightly different sense, but I won't quibble much. Assume a completely type-safe version of C, if that makes it clearer. > It would lead us to being able to have TWIs, only readable or writeable > in the IO Monad. Many people don't think that would be such a bad > thing. But because of the semantics we expect from IORefs, we can't > get them without destroying other properties we want. > > a = unsafePerformIO $ newIORef Nothing > > Respecting referential integrity would give us the wrong semantics. > Adding labels would force the compiler to keep two differently labeled > things seperate, Hmm. That sounds as if the global variables problem is equivalent to the problem of unique name supplies: With global variables (let's say top-level MVars) we can easily implement a unique name supply. And with a unique name supply we could (in principle, at least) define newMVar and newIORef as pure functions taking some unique label as an argument. (QED) I have just taken a closer look at 'linear implicit parameters' because they are supposed to be good for unique name supplies. It seems they are even worse than the 'normal' implicit parameters. Considering the above argument this doesn't surprise me much. That means we are back to using the IO Monad to create unique labels, so all this doesn't gain us anything, at least not on the practical level. > In contrast with IO Handles, there the OS does all the work. If > "makeHandle" were exposed to us, It really wouldn't matter whether > > handle1 and stdout > > handle1 = makeHandle 1 > stdout = makeHandle 1 > > were beta-reduced or not. Either way, the OS naturally handles how we > refer to stdout. I see the difference and I agree. However, you can already do this using the Posix package: makeHandle :: Int -> System.Posix.Fd makeHandle = fromIntegral but note that handleToFd :: Handle -> IO Fd fdToHandle :: Fd -> IO Handle are both in the IO Monad. BTW, the man page for stdin etc. says: "Note that mixing use of FILEs and raw file descriptors can produce unexpected results and should generally be avoided." > (One caveat here -- buffering implemented by the compiler & runtime > would make a difference.) I think this is done neither by compiler nor RTS but by a low-level library. Anyway, it seems to make a difference, as witnessed by the above signatures. Ben

2 1

Problem with overlapping class instances
by Graham Klyne 23 Nov '04

23 Nov '04

Once again, the Haskell class system is proving rather subtle for me. On this occasion, I'm getting an overlapping class instance error which I think should be fully disambiguated by the supplied class context. The code below (end of message) is a .lhs file that reproduces the problem in Hugs, with external dependencies from my working codebase stripped out. It should be possible to simply load it (or this whole email) to get the same error: [[ Reading file "D:\Cvs\DEV\HaskellDL\spike-overlap-conceptexpr.lhs": ERROR "D:\Cvs\DEV\HaskellDL\spike-overlap-conceptexpr.lhs":30 - Overlapping inst ances for class "ConceptExpr" *** This instance : ConceptExpr (a b) *** Overlaps with : ConceptExpr AtomicConcept *** Common instance : ConceptExpr [Char] ]] The line referred to as "this instance" is: instance (ConceptWrapper cw c, ConceptExpr c) => ConceptExpr (cw c) where The reported overlapping instance is [Char], which I take to be derived from the type constructor [] applied to type Char, this yielding a form that matches (cw c). But the instance ConceptExpr (cw c) is declared to be dependent on the context ConceptWrapper cw c, which has *not* been declared for the type constructor []. GHCi with -fglasgow-exts is no more informative. What am I missing here? #g -- [Source code follows] spike-overlap-ConceptExpr.lhs ----------------------------- > type AtomicConcepts a = [(AtomicConcept,[a] )] > type AtomicRoles a = [(AtomicRole ,[(a,a)])] > > type TInterpretation a = ([a],AtomicConcepts a,AtomicRoles a) > class (Eq c, Show c) => ConceptExpr c where > iConcept :: Ord a => TInterpretation a -> c -> [a] ... > type AtomicConcept = String -- named atomic concept Declare AtomicConcept and AtomicRole as instances of ConceptExpr and RoleExpr (AtomicRole is used by AL, and including AtomicConcept here for completeness). > instance ConceptExpr AtomicConcept where > iConcept = undefined ... To allow a common expression to support multiple description logics, we first define a wrapper class for DLConcept and DLRole: > class ConceptExpr c => ConceptWrapper cw c | cw -> c where > wrapConcept :: c -> cw c -> cw c > getConcept :: cw c -> c Using this, a ConceptWrapper can be defined to be an instance of ConceptExpr: This is line 30: > instance (ConceptWrapper cw c, ConceptExpr c) => ConceptExpr (cw c) where > iConcept = iConcept . getConcept Error message: Reading file "D:\Cvs\DEV\HaskellDL\spike-overlap-conceptexpr.lhs": ERROR "D:\Cvs\DEV\HaskellDL\spike-overlap-conceptexpr.lhs":30 - Overlapping inst ances for class "ConceptExpr" *** This instance : ConceptExpr (a b) *** Overlaps with : ConceptExpr AtomicConcept *** Common instance : ConceptExpr [Char] ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

3 6

Re: Top Level TWI's again was Re: [Haskell] Re: Parameterized Show
by Graham Klyne 23 Nov '04

23 Nov '04

[Switching to Haskell-cafe] At 11:26 22/11/04 +0000, you wrote: >I would ask an alternative question - is it possible to live without >unsafePerformIO? I have never needed to use it! I have used it once, with reservations, but at the time I didn't have the time/energy to find a better solution. (The occasion of its use was accessing external entities within an XML parser; by making the assumption that the external entities do not change within any context in which results from a program are compared, I was able to satisfy the "proof obligation" of not causing or being sensitive to side effects.) The reason this was important to me is that I wanted to be able to use the parser from code that was not visibly in the IO monad. For me, treating Web data transformations as pure functions is one of the attractions of using Haskell. (Since doing that, I had an idea that I might be able to parameterize the entity processing code on some Monad, and use either an Identity monad or IO depending on the actual requirements. This way, I could keep pure XML processing out of the IO monad, but use IO when IO was needed.) In short: I think it's usually possible to avoid using unsafePerformIO, but I'd be reluctant to cede it altogether, if only for sometimes quick-and-dirty pragmatic reasons. #g ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

8 15

Re: Global variables again
by Benjamin Franksen 23 Nov '04

23 Nov '04

[we should really keep this on haskell-cafe because such lengthy discussions are what the cafe is for] On Tuesday 23 November 2004 10:26, Adrian Hey wrote: > On Monday 22 Nov 2004 4:03 pm, Benjamin Franksen wrote: > > This is getting ridiculous. At least two workable alternatives have been > > presented: > > > > - C wrapper (especially if your library is doing FFI anyway) > > - OS named semaphores > > Neither of these alternatives is a workable general solution. Since the problem only appears in special situations, a general solution is not required, nor is it desirable (because of the danger of infection with the "global variable disease".) > There are several significant problems with both, but by far > the most significant problem (at least if you believe that top > level mutable state is evil) is that they both rely on the use > of top level mutable state. If this is evil it is surely just as > evil in C or OS supplied resources as it is in Haskell. The evil is in the world in the form of C libraries with hidden global variables and hardware with non-readable registers. What I am arguing for is to *contain* this disease by forcing a solution to happen outside of Haskell. What you are arguing for (i.e. a general solution *in* Haskell) amounts to (deliberately) *spreading* the disease. > The fact that one solution requires the use of a completely different > programming language And that is exactly the point: In order to do evil you have to go somewhere else, preferably to where the problem originally came from. If it originated in C, go fix it on the C level. If originates in the OS, go fix it on the OS level. As for broken hardware, you should use a OS level mechanism, so that multiple initialization is prevented OS wide and not only per program run. > and the other requires the use of a library which > could not be implemented in Haskell (not without using unsafePerformIO > anyway) must be telling us that there something that's just plain missing > from Haskell. Yes it's plain missing and for good reasons. There are many things plainly missing from Haskell besides global variables. > IMO this is not a very satisfactory situation for a language > that's advertised as "general purpose". "General purpose" doesn't mean that any programming idiom is supported. > > Further, as for "evidence or credible justification" for the my claim, > > you can gather it from the numerous real-life examples I gave, and which > > you chose to ignore or at least found not worthy of any comment. > > I have no idea what examples you're talking about. Did you post any code? No, I didn't post code. I already said it's annecdotal evidence. For instance, I was talking about using the ONC/RPC implementation on VxWorks, which is broken because they internally use thread-local mutual state. > If so, I must have missed it for some reason. Perhaps your're refering > to your elimination of unsafePerformIO from a library you were writing. I wasn't. > > Of course, > > these examples are only annecdotal but I think this is better than a > > completely artificial requirement (like your "oneShot"). > > Being able to avoid the use of top level mutable state sometimes (or even > quite often) is not proof that it's unnecessary, True. I have never claimed that, though. What I claimed is that in the cases where they are necessary, FFI is probably used anyway, so it *is* workable to use a foreign language wrapper. In order to convince me that this is wrong you could present a (real-world, no artificial requirements) example that does not require the use of FFI anyway. If you can do so (which I doubt) I might be willing to accept a compiler-supported standard library routine with a very long and very ugly name like warningBadStyleUseOnlyIfAbolutelyNecessary_performOnlyOnce: IO a -> IO a ;-) > especially when nobody > (other than yourself presumably) knows why you were using it in the first > place. Not I. And it was for convenience only, as I proved by completely eliminating them without making the code any more complicated. I never claimed that this proves anything, it was just a personal experience. BTW, the main reason they use global variable in C all the time is because it's just so damn convenient (at first) and *not* because there are problems otherwise unsolvable. (There are *very* few exceptions.) > However, the existance of just one real world example where it does > appear unavoidable is pretty convincing evidence to the contrary IMO. I agree that the alternatives are not a good *general* solution. I have been arguing that a general solution is not desirable. > > You have been asked more than once to present a *real-life* example to > > illustrate that > > > > (a) global variables are necessary (and not just convenient), > > (b) both above mentioned alternatives are indeed unworkable. > > I knew this would happen. I was asked to provide an example and I *did*. > I gave the simplest possible example I had of the more general problem, > and now this whole thread has consisted of either repeated denials of > the reality of even this simple problem (something you've just done again) > or protracted discussions over various half baked non-solutions to > this one particular problem (such as those you identify above) without > seeing the real underlying general problem. There is no underlying problem, apart from interfacing evil hardware or foreign libraries. At least I know of none. > > > You have yet to > > > explain how you propose to deal with stdout etc.. > > > > I see absolutely no reason why stdxxx must or should be top-level mutable > > objects. They can and should be treated in the same way as environment > > and command line arguments, i.e. > > > > getArgs :: IO [String] > > getEnv :: String -> IO String > > getStdin, getStdout, getStderr :: IO Handle > > > > Note that (just like environment and command line arguments) these > > handles may refer to completely different things on different program > > runs. > > Sure, Peter Simons suggested the same thing. I have no great objection, > but why do this? Strange. I told you the reason. You even cited it. What about reading it, too ;-? > I mean what extra safety does this buy you? Nobody claimed that global variables are unsafe in any strict sense. > Anybody can > still get at stdout and write anything they like to it. Sure they can. They have been warned, though... ;-) > The only difference is that instead of writing.. > > do ... > foo stdout > ... > > ..they now have to write.. > > do ... > stdout <- getStdout > foo stdout > ... > > I don't see why the former should be regarded as a source of great evil > which is somehow eliminated by the latter. To repeat myself once again: The latter version makes it clear to anyone looking at the code, that the stdout above (a) might refer to something different from other results of getStdout elsewhere in the program (e.g. stdout might have been closed or re-opened) (b) might refer to completely different things on different program runs (e.g. output of program is piped to some other process or even a socket). Ben -- Top level things with identity are evil. -- Lennart Augustsson

1 0