- Glasgow-haskell-users

Fwd: Two Proposals
by George Giorgidze 11 Oct '11

11 Oct '11

For some reasons Philip's email was rejected by the mailing list. I am reposting his message. See below. Cheers, George Begin forwarded message: > From: Philip Wadler <wadler(a)inf.ed.ac.uk> > Date: 2011-October-11 11:48:31 GMT+02:00 > To: Simon Peyton-Jones <simonpj(a)microsoft.com>, George Giorgidze <george.giorgidze(a)uni-tuebingen.de> > Subject: Fwd: Two Proposals > > FYI. -- P > > > ---------- Forwarded message ---------- > From: <glasgow-haskell-users-owner(a)haskell.org> > Date: Tue, Oct 11, 2011 at 9:28 AM > Subject: Re: Two Proposals > To: wadler(a)inf.ed.ac.uk > > > You are not allowed to post to this mailing list, and your message has > been automatically rejected. If you think that your messages are > being rejected in error, contact the mailing list owner at > glasgow-haskell-users-owner(a)haskell.org. > > > > ---------- Forwarded message ---------- > From: Philip Wadler <wadler(a)inf.ed.ac.uk> > To: George Giorgidze <giorgidze(a)gmail.com> > Date: Tue, 11 Oct 2011 09:28:05 +0100 > Subject: Re: Two Proposals > George, Thanks very much for this. I like your suggestion, which > fits the logical structure perfectly; and you've suggested a neat way > around the ugliness of 'group groupBy'. I also note that if we aren't > so worried about not introducing new keywords, that 'then group' could > become 'group'. Yours, -- P > > On Mon, Oct 10, 2011 at 11:21 PM, George Giorgidze <giorgidze(a)gmail.com> wrote: >> A quick thought that came to me after hoogling [a] -> [[a]]. >> The first four functions in the search result are named after what they >> return (noun in plural) rather than what they do (verb). I am talking about >> inits, permutations, subsequence and tails. >> So I thought the following syntax might work as well if (as it is already >> common) grouping functions are named after what they return. >> then f >> then f by e >> then group f >> then group f by e >> For example the following code fragments read well: >> then group inits >> then group permutations >> then group subsequences >> then group tails >> Here we use the special identifier group as a verb. >> I have not told you about the fifth result of the hoogling, the groupWith >> function. The following really looks ugly: >> then group groupWith by e >> But following the aforementioned naming convention the groupWith function >> could as well be named as equals. Now this reads well: >> then group equals by e >> Cheers, George >> >> On 2011-Oct-5, at 09:14 , Simon Peyton-Jones wrote: >> >> [adding ghc-users] >> >> It's not easy, Phil. Do you have any ideas? >> >> For the 'then' case the name of the function serves as the verb. One might >> say >> >> then take 4 >> or >> then takeWhile by salary > 40 >> >> For grouping one might like to say the same thing, such as >> then groupBy by salary >> but the typing rule is quite different, so we really need a different >> keyword. We chose the compound keyword "then group" to avoid needing a >> whole new keyword ("group" is treated specially only in tthis context). So >> you write >> then group by salary using groupBy >> >> Using this order of the pieces for the sorting case is harder. What would >> one say? "then process"? Like this? >> then process by salary > 40 using takeWhile >> Not very nice. >> >> One could use a new keyword for grouping "theng" say, thus: >> theng groupBy by salary >> But that is hardly beautiful either. >> >> So the current story is not great, but it's the best I could think of. >> Improvements welcome. >> >> Simon >> >> | -----Original Message----- >> | From: Philip Wadler [mailto:wadler@inf.ed.ac.uk] >> | Sent: 04 October 2011 18:15 >> | To: Simon Peyton-Jones; George Giorgidze >> | Subject: Re: FW: Two Proposals >> | >> | George, >> | >> | Nice proposal. I like the idea of symmetry, but don't at all like the >> | idea that f comes before e for 'then' but f comes after e for 'then >> | group'. Can you rethink it and come up with something even more >> | symmetric? >> | >> | Yours, -- P >> | >> | >> | On Tue, Oct 4, 2011 at 9:23 AM, Simon Peyton-Jones >> | <simonpj(a)microsoft.com> wrote: >> | > FYI >> | > >> | > -----Original Message----- >> | > From: glasgow-haskell-users-bounces(a)haskell.org >> [mailto:glasgow-haskell- >> | users-bounces(a)haskell.org] On Behalf Of George Giorgidze >> | > Sent: 30 September 2011 18:28 >> | > To: glasgow-haskell-users(a)haskell.org >> | > Subject: Two Proposals >> | > >> | > GHC Users, >> | > >> | > I would like to make to the following two proposals: >> | > * Eliminate the default grouping close from SQL-like comprehensions >> | > * Introduce a GHC extension for list literal overloading >> | > >> | > OK, let me start with the first proposal. >> | > >> | > Currently, the SQL-like comprehension notation (both in its list >> comprehension >> | and monad comprehension variants) features the following five clauses: >> | > >> | > then f >> | > then f by e >> | > then group by e >> | > then group using f >> | > then group by e using f >> | > >> | > The first two clauses are used for specifying transformations of type >> [a] -> [a] >> | (or Monad m => m a-> m a for monad comprehensions). The following three >> | clauses are used for specifying transformations of type [a] -> [[a]] (or >> Monad m, >> | Functor f => m a -> m (f a) for monad comprehensions). See [1] for >> further >> | details. >> | > >> | > Note that the third clause does not mention which function is used for >> grouping. >> | In this case GHC.Exts.groupWith function is used as a default for list >> | comprehensions and the mgroupWith function from the MonadGroup class is >> used >> | as a default for monad comprehensions. >> | > >> | > I would like to suggest to remove the third clause for the following >> reasons: >> | > * Currently the syntax is asymmetrical. Note that there is the default >> case for >> | the 'then group' clause and not for the 'then' clause. >> | > * In the current notation it is not clear which grouping function is >> used in the >> | default case >> | > * For many monads including lists it is not clear which function should >> be >> | selected as a default (e.g., the groupWith function also does sorting and >> it is not >> | clear to me why this should be the default) >> | > * Gets rid of the MonadGroup class. Currently the sole purpose of this >> class is to >> | introduce a default grouping function for monad comprehensions. >> | > * Explicit mention of the grouping function would make monad/list >> | comprehensions much easier to read by making it immediately apparent >> which >> | function is used for grouping. >> | > >> | > My second proposal is to introduce the OverloadedLists extension that >> overloads >> | list literals. See Section 5.2 in [1] for details. >> | > >> | > Basically the idea is to treat list literals like: >> | > >> | > [1,2,3] >> | > >> | > as >> | > >> | > fromList [1,2,3] >> | > >> | > where >> | > >> | > class IsList l where >> | > type Item l >> | > fromList :: [Item l] -> l >> | > >> | > In the following I give useful instances of the IsList class. >> | > >> | > instance IsList [a] where >> | > type Item [a] = a >> | > fromList = id >> | > >> | > instance (Ord a) => IsList (Set a) where >> | > type Item (Set a) = a >> | > fromList = Set.fromList >> | > >> | > instance (Ord k) => IsList (Map k v) where >> | > type Item (Map k v) = (k,v) >> | > fromList = Map.fromList >> | > >> | > instance IsList (IntMap v) where >> | > type Item (IntMap v) = (Int,v) >> | > fromList = IntMap.fromList >> | > >> | > instance IsList Text where >> | > type Item Text = Char >> | > fromList = Text.pack >> | > >> | > As you can see the extension would allow list literals to be used for >> sets, maps >> | and integer maps. In addition the suggested OverloadedLists extension >> would >> | subsume OverloadedStrings extension (see the instance for Text, for >> example). >> | Having said that, for now, I am not suggesting to remove the >> OverloadedStrings >> | extension as it appears to be widely used. >> | > >> | > This extension could also be used for giving data-parallel array >> literals instead of >> | the special syntax used currently. >> | > >> | > Unless there is a vocal opposition to the aforementioned two proposals, >> I would >> | like to implement them in GHC. Both changes appear to be straightforward >> to >> | implement. >> | > >> | > Thanks in advance for your feedback. >> | > >> | > Cheers, George >> | > >> | > [1] >> http://www-db.informatik.uni-tuebingen.de/files/giorgidze/haskell2011.pdf >> | > _______________________________________________ >> | > Glasgow-haskell-users mailing list >> | > Glasgow-haskell-users(a)haskell.org >> | > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >> | > >> | > >> | > >> | >> | >> | >> | -- >> | .\ Philip Wadler, Professor of Theoretical Computer Science >> | ./\ School of Informatics, University of Edinburgh >> | / \ http://homepages.inf.ed.ac.uk/wadler/ >> | >> | The University of Edinburgh is a charitable body, registered in >> | Scotland, with registration number SC005336. >> | >> >> >> > > > > -- > .\ Philip Wadler, Professor of Theoretical Computer Science > ./\ School of Informatics, University of Edinburgh > / \ http://homepages.inf.ed.ac.uk/wadler/ > > The University of Edinburgh is a charitable body, registered in > Scotland, with registration number SC005336. > > > > > > > -- > .\ Philip Wadler, Professor of Theoretical Computer Science > ./\ School of Informatics, University of Edinburgh > / \ http://homepages.inf.ed.ac.uk/wadler/

1 0

"case" of an empty type should have no branches
by Roman Beslik 11 Oct '11

11 Oct '11

Hi. Why the following code does not work? > data Empty > quodlibet :: Empty -> a > quodlibet x = case x of "parse error (possibly incorrect indentation)" This works in Coq, for instance. Demand for empty types is not big, but they are useful for generating finite types: > Empty ≅ {} > Maybe Empty ≅ {0} > Maybe (Maybe Empty) ≅ {0, 1} > Maybe (Maybe (Maybe Empty)) ≅ {0, 1, 2} etc. Number of 'Maybe's = number of elements. I can replace @Maybe Empty@ with @()@, but this adds some complexity.

5 5

Two Proposals
by George Giorgidze 10 Oct '11

10 Oct '11

GHC Users, I would like to make to the following two proposals: * Eliminate the default grouping close from SQL-like comprehensions * Introduce a GHC extension for list literal overloading OK, let me start with the first proposal. Currently, the SQL-like comprehension notation (both in its list comprehension and monad comprehension variants) features the following five clauses: then f then f by e then group by e then group using f then group by e using f The first two clauses are used for specifying transformations of type [a] -> [a] (or Monad m => m a-> m a for monad comprehensions). The following three clauses are used for specifying transformations of type [a] -> [[a]] (or Monad m, Functor f => m a -> m (f a) for monad comprehensions). See [1] for further details. Note that the third clause does not mention which function is used for grouping. In this case GHC.Exts.groupWith function is used as a default for list comprehensions and the mgroupWith function from the MonadGroup class is used as a default for monad comprehensions. I would like to suggest to remove the third clause for the following reasons: * Currently the syntax is asymmetrical. Note that there is the default case for the 'then group' clause and not for the 'then' clause. * In the current notation it is not clear which grouping function is used in the default case * For many monads including lists it is not clear which function should be selected as a default (e.g., the groupWith function also does sorting and it is not clear to me why this should be the default) * Gets rid of the MonadGroup class. Currently the sole purpose of this class is to introduce a default grouping function for monad comprehensions. * Explicit mention of the grouping function would make monad/list comprehensions much easier to read by making it immediately apparent which function is used for grouping. My second proposal is to introduce the OverloadedLists extension that overloads list literals. See Section 5.2 in [1] for details. Basically the idea is to treat list literals like: [1,2,3] as fromList [1,2,3] where class IsList l where type Item l fromList :: [Item l] -> l In the following I give useful instances of the IsList class. instance IsList [a] where type Item [a] = a fromList = id instance (Ord a) => IsList (Set a) where type Item (Set a) = a fromList = Set.fromList instance (Ord k) => IsList (Map k v) where type Item (Map k v) = (k,v) fromList = Map.fromList instance IsList (IntMap v) where type Item (IntMap v) = (Int,v) fromList = IntMap.fromList instance IsList Text where type Item Text = Char fromList = Text.pack As you can see the extension would allow list literals to be used for sets, maps and integer maps. In addition the suggested OverloadedLists extension would subsume OverloadedStrings extension (see the instance for Text, for example). Having said that, for now, I am not suggesting to remove the OverloadedStrings extension as it appears to be widely used. This extension could also be used for giving data-parallel array literals instead of the special syntax used currently. Unless there is a vocal opposition to the aforementioned two proposals, I would like to implement them in GHC. Both changes appear to be straightforward to implement. Thanks in advance for your feedback. Cheers, George [1] http://www-db.informatik.uni-tuebingen.de/files/giorgidze/haskell2011.pdf

12 19

log time instead of linear for case matching
by Greg Weber 10 Oct '11

10 Oct '11

We have a couple use cases in Yesod that can potentially match many different patterns. Routing connects the url of an http request to a Haskell function. The current code just uses a pattern match, which scales linearly. So if a site has a hundred different routes (urls), it could take 100 comparisons to finally match the url to a function. Michael Snoyman is writing some code to make this issue obsolete. One of the things it does is use a Map lookup instead of a case match. More worrying is our system for internationalization of a website. A user is supposed to make a sum type with every custom message as a constructor in that sum type. data Msg = Model | Year | Please -- Rendering function for English. renderEnglish Model = "Model" renderEnglish Year = "Year" renderEnglish Please = "Please fill in your car's details" -- Rendering function for Swedish. renderSwedish Model = "Modell" renderSwedish Year = "Årgång" renderSwedish Please = "Vänligen fyll i uppgifterna för din bil" So if there are 100 custom messages on a site, that will setup a case match with potentially 100 comparisons. Note that we are using this technique for type safety- switching to a map here would be difficult. We want to know at compile time that a translation exists for every message. So first of all I am wondering if a sum type comparison does in fact scale linearly or if there are optimizations in place to make the lookup constant or logarithmic. Second, I as wondering (for the routing case) if Haskell can make a string case comparison logarithmic so that users can use case comparisons instead of maps for string collections that are known at compile time and won't change.

3 3

Re: Is this a concurrency bug in base?
by Jean-Marie Gaillourdet 09 Oct '11

09 Oct '11

Hi, the Eq instance of TypeRep shows the same non-deterministic behavior: import Control.Concurrent import Control.Exception import Control.Monad import Data.Typeable main :: IO () main = do { fin1 <- newEmptyMVar ; fin2 <- newEmptyMVar ; forkIO $ return (typeOf ()) >>= evaluate >>= putMVar fin1 ; forkIO $ return (typeOf ()) >>= evaluate >>= putMVar fin2 ; t1 <- takeMVar fin1 ; t2 <- takeMVar fin2 ; when (t1 /= t2) $ putStrLn $ "typeOf " ++ show t1 ++ " /= typeOf " ++ show t2 } $ ghc-7.0.3 -threaded -rtsopts TypeRepEq.hs <snip> $ while true ; do ./TypeRepEq +RTS -N ; done typeOf () /= typeOf () typeOf () /= typeOf () ^C^C $ On 09.10.2011, at 16:04, David Brown wrote: > The program below will occasionally print "1 /= 0" or "0 /= 1" on > x86_64 linux with the Debian testing 7.0.4 ghc. > > $ ghc bug -rtsopts -threaded > $ while true; do ./bug +RTS -N; done > >> module Main where >> import Control.Monad >> import Control.Concurrent >> import Data.Typeable >> main :: IO () >> main = do >> fin1 <- newEmptyMVar >> fin2 <- newEmptyMVar >> forkIO $ child fin1 >> forkIO $ child fin2 >> a <- takeMVar fin1 >> b <- takeMVar fin2 >> when (a /= b) $ >> putStrLn $ show a ++ " /= " ++ show b >> child :: MVar Int -> IO () >> child var = do >> key <- typeRepKey (typeOf ()) >> putMVar var key Thanks again for reproducing it. Jean

1 0

GHC, Clang & XCode 4.2
by austin seipp 07 Oct '11

07 Oct '11

There has been recent discussion on the Homebrew bug tracker concerning the upcoming XCode 4.2 release by Apple, which has apparently just gone GM (meaning they're going to make a real release on the app store Real Soon Now.) The primary concern is that XCode will no longer ship GCC 4.2 at all, it seems. XCode 4.0 & 4.1 merely set 'llvm-gcc' as the default compiler, and GHC's `configure` script was adjusted to find the `gcc-4.2` binary. If you have old XCode's installed, then you may have the binaries laying around, but I doubt they'll be on your $PATH, and anybody doing a fresh install is SOL. It seems Clang 3.0 will now be the default compiler, with llvm-gcc as a deprecated option, probably removed in XCode 4.3. It doesn't matter really, because both of them do not work with GHC, because of its use of either A) Global register variables of any kind, or B) the __thread storage modifier. David Peixotto did some work on this not too long ago as the issue of compiling with Clang was raised. His branches include changes which make the 'gct' variable use pthread_getspecific rather than __thread for TLS and then as an optimization use inline ASM to grab the value out of the variable, with an impact of about 9% it seems, but that's on nofib and I don't know if it was -threaded. He also included a version which passes the 'gct' around as a parameter to all GCC functions which is a bit uglier but may give some better performance I guess. (The discussion is from here IIRC.) I suppose the real perf killer here is probably -threaded code. https://github.com/dmpots/ghc Was there ever any decision on which route to take for this issue? The parameter passing solution looks quite uglier IMO but it may be necessary for performance. I'm just posting this here as a reminder as this is probably going to become a problem pretty quickly for anybody who uses Lion or modern XCode and also likes using GHC, so it should probably be sorted out. :) I'm still on SL using XCode 4 so it's not an issue for me, but it will be for any future Mac endeavors. Hopefully they get support for __thread or something equivalent soon, because nobody likes performance hits, but it doesn't seem like we have a choice. -- Regards, Austin

4 3

mkTopLevEnv: not interpreted main:Main
by Chris Smith 07 Oct '11

07 Oct '11

So I'm trying to fix a bug in a web application that's using the GHC API with GHC 7.2. If it helps, the application is gloss-web, source code at https://github.com/cdsmith/gloss-web and the relevant module is src/Source.hs. The error I'm getting is <no location info>: mkTopLevEnv: not interpreted main:MyModule I get this occasionally when two pieces of source code happen to get compiled at approximately the same time, but most of the time everything works fine. The module name there is whichever one I've defined in the source code I'm compiling. It's correct that the module is not interpreted; I'm specifying options hscTarget = HscAsm ghcLink = LinkInMemory But it's unclear to me why GHC occasionally decides to require that it be interpreted and complain, when compiling the code works fine in any other circumstance. Anyone else seen anything like this, or know what the cause is? A few notes: 1. It doesn't appear to be a straight-forward reentrancy issue, as wrapping uses of the GHC API with an MVar lock doesn't affect it at all. However, it definitely *is* correlated with multiple compiles at approximately the same time. Very odd there. 2. On a whim, I tried adding a performGC before and after each use of the compiler to try to isolate the uses of the GHC API more completely. Oddly enough, a performGC before the compile makes the problem much WORSE. I found that interesting; maybe it's a hint. 3. If you want to build my code and reproduce it, the easiest way is to comment out line 110 (keepAlive cmap digest 30) of src/Source.hs. Doing so will break the bit that caches recently compiled source code, making it much easier to actually call the GHC API several times in rapid succession just by rapidly clicking the Run button in the web app. If there's anything I can do to get more information, I'm happy to do so as well. I'm not terribly familiar with the flags or options for GHC, as I've never done this before. -- Chris Smith

4 11

REQ: add a non-closing version of handleToFd
by Volker Wysk 07 Oct '11

07 Oct '11

Hello The function to extract a file descriptor from a handle, handleToFd, closes the handle as a side effect. This appears to be necessary in the general case, otherwise the implementers wouldn't have made it this way. But there are cases in which it isn't necessary to close the handle. For instance, this little function needs to extract the file descriptor, but there is no need to close, or change, the handle. isatty :: Handle -- ^ Handle to check -> IO Bool -- ^ Whether the handle is connected to a terminal isatty h = do fd <- handleToFd_noclose h isterm <- {# call isatty as hssh_c_isatty #} -- this is c2hs ((fromIntegral fd) :: CInt) return (isterm /= (0::CInt)) handleToFd_noclose :: Handle -> IO Fd -- to be implemented The isatty above can't be implemented with things the way they are. To me, this is a serious drawback. The cases, in which the handle needs to be closed, should be identified, and documented. Then, a version of handleToFd, which doesn't close the handle can be implemented. Cheers Volker

4 3

Mysterious function timer_settime
by Volker Wysk 06 Oct '11

06 Oct '11

Hi! Im porting my HsShellScript library to GHC-7.0.4 and to Cabal/Hackage. It builds and installs fine: ~/src/hsshellscript-3.0.0 $ cabal clean cleaning... ~/src/hsshellscript-3.0.0 $ cabal configure Resolving dependencies... Configuring hsshellscript-3.0.0... ~/src/hsshellscript-3.0.0 $ cabal build Preprocessing library hsshellscript-3.0.0... Building hsshellscript-3.0.0... (...) Registering hsshellscript-3.0.0... ~/src/hsshellscript-3.0.0 $ cabal haddock Running Haddock for hsshellscript-3.0.0... Preprocessing library hsshellscript-3.0.0... (...) Documentation created: dist/doc/html/hsshellscript/index.html ~/src/hsshellscript-3.0.0 $ cabal install Resolving dependencies... Configuring hsshellscript-3.0.0... Preprocessing library hsshellscript-3.0.0... Building hsshellscript-3.0.0... Registering hsshellscript-3.0.0... Installing library in /home/v/.cabal/lib/hsshellscript-3.0.0/ghc-7.0.4 Registering hsshellscript-3.0.0... I've made a fine little test program src/test.hs: import HsShellScript main = (outm "3\n1\n2\n") -|- exec "/usr/bin/sort" ["-n"] But this doesn't work. It generates a mysterious error message: ~/src/hsshellscript-3.0.0 $ src/test test: <stderr>: hPutStr: illegal operation (handle is closed) test: timer_settime: Invalid argument "timer_settime" occurs only in the generated test binary. It doesn't occur anywhere in the library or in "/usr/bin/sort": ~/src/hsshellscript-3.0.0 $ find -type f -print0|xargs -0 egrep timer_settime Übereinstimmungen in Binärdatei ./src/test. ~/src/hsshellscript-3.0.0 $ egrep timer_settime /usr/bin/sort (no output) It looks like GHC has introduced this mysterous call of timer_settime. What does that mean? Thanks for any help, Volker W.

2 3

Re: [Pkg-haskell-maintainers] libffi soname change upcoming
by Joachim Breitner 04 Oct '11

04 Oct '11

Hi, Am Mittwoch, den 24.08.2011, 12:44 +0200 schrieb Matthias Klose: > > The question that has to be answered first is: Assume the libraries do > > not depend on libffi themselves, and only ghc does. Now you update > > libffi and ghc gets rebuilds, what will happen: > > > > A) The haskell ABIs stay the same, the existing library packages can > > still be used. Great. > > > > B) The haskell ABIs change. We’ll have to binNMU all Haskell libraries, > > but oh well, not bad thanks to BD-Uninstallable-support in wanna-build > > and autosigning. > > > > C) The haskell ABIs do not change, but the old library builds are > > broken nevertheless. Big mess. Hard to recover from, because builds are > > not ordered automatically any more. Needs lots of NMUes and Dep-Waits. > > sorry, I don't get the `C' case. why should these be broken by a libffi or > libgmp change? Maybe it’s an unrealistic example, but I could imagine that ghc some data type (size) defined by libffi is used when generating code for a haskell library under the assumption that it has the same structure/size in the run time system and/or other used haskell libraries. But instead of making blind guesses, maybe GHC upstream can enlighten us: Is it safe to build ghc and a Haskell library, then upgrade libffi to a new version (with soname bump), rebuild ghc, but use the previous library build? > > Removing the libffi dependencies from the haskell libraries makes C > > possible and only helps with A. So until someone investigates this, I’d > > rather err on the safe side, leave the dependencies in, and fix the > > issue by rebuilding all haskell libraries when you upload the new ffi > > soname to unstable. > > well, with binNMU orgies like this you'll pull in any new or tightened > dependencies for shared libraries. Not depending on these unused libraries > does avoid this. True. I agree that it would be nice and worthwhile to remove the libffi dependency from the libraries, but only if it is actually safe and scenario C is guaranteed not to happen. Greetings, Joachim -- Joachim "nomeata" Breitner Debian Developer nomeata(a)debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nomeata(a)joachim-breitner.de | http://people.debian.org/~nomeata

2 4