Re: [Haskell-cafe] Store type-class polymorphic values generically
| However, I want to write this as a core-to-core | translation as a ghc-plugin. I want the definition go = putStrLn Hello | World! to be translated to what I wrote above. Core cannot generate new | names to be exported from a module, so go_ is now gone. Wait... what do you mean Core cannot generate new names to be exported. I think a core-to-core plugin can certainly generate new top-level function definitions. Maybe you mean that you want your plugin to transform module M( f ) where f = e into module M( f_ ) where f_ = ...f... f = e That seems pretty drastic, because now the programmer's API for the module has changed. Are you sure you don't want to do this module M( f ) wehre f_ = e f = ...f_... by renaming the existing f with some local name. I don't like all this unsafe hackery! Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Using lenses
(I sent this to 'libraries' but Kim-Ee suggested adding Café, where so many smart people hang out.) Friends Some of you will know that I've promised to give a talk about Edward's lens libraryhttp://hackage.haskell.org/package/lens at the Haskell Exchangehttp://skillsmatter.com/event/scala/haskell-exchange in London next Wednesday (9th). I did this to give everyone (including me) a break from GHC hackery, and also to force me to learn about this lens voodoo that everyone is twittering about. Edward generously gave me quite a bit of one-to-one attention last week (my hair is still standing on end), but this message is to ask your help too. Specifically, I'd like to give some compelling use-cases. If you are using the lens library yourself, could you spare a few minutes to tell me how you are using it? I expect to cover Lens and Traversal but not Prism. The use-case everyone starts with is nested records, but I'd like to go beyond that. The next levels seem to be: · Lenses as views of data that isn't really there e.g. regarding a record with rectangular coordinates as having polar coordinates too. · Lenses and Traversals that focus on elements of finite maps (Control.Lens.At) What else? I'm sure you are using them in all sorts of cool ways that I would never think of, and I'd love to know. Please don't tell me anything secret! To give everyone the benefit I may just concatenate all the replies and send to you all, so please say if you don't want me to do that with yours. And don't burn too many cycles on this...I don't want to waste your time, and I can always get back to you if I can't understand what you say. Sooner is better than later...Weds is coming. Simon Edward's prophet PJ ___ Libraries mailing list librar...@haskell.org http://www.haskell.org/mailman/listinfo/libraries ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] An APL library for Haskell
PS: Oddly I sent this message in March 2012. I don't know why it has taken over year for it to be delivered! Simon From: Haskell-Cafe [mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Simon Peyton-Jones Sent: 08 March 2012 13:45 To: hask...@haskell.org; Haskell Cafe Cc: Lennart Augustsson; John Scholes; nic...@chalmers.se; Nate Foster; Andy Gill; Mary Sheeran; Fritz Henglein Subject: [Haskell-cafe] An APL library for Haskell Friends Many of you will know the array language APLhttp://en.wikipedia.org/wiki/APL_%28programming_language%29. It focuses on arrays and in particular has a rich, carefully-thought-out array algebra. An obvious idea is: what would a Haskell library that embodies APL's array algebra look like? In conversation with John Scholes and some of his colleagues in the APL community a group of us developed some ideas for a possible API, which you can find on the Haskell wiki here: http://www.haskell.org/haskellwiki/APL However, we have all gone our separate ways, and I think it's entirely possible that that the idea will go no further. So this message is to ask: * Is anyone interested in an APL-style array library in Haskell? * If so, would you like to lead the process of developing the API? I think there are quite a few people who would be willing to contribute, including some core gurus from the APL community: John Scholes, Arthur Whitney, and Roger Hui. Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] An APL library for Haskell
Friends Many of you will know the array language APLhttp://en.wikipedia.org/wiki/APL_%28programming_language%29. It focuses on arrays and in particular has a rich, carefully-thought-out array algebra. An obvious idea is: what would a Haskell library that embodies APL's array algebra look like? In conversation with John Scholes and some of his colleagues in the APL community a group of us developed some ideas for a possible API, which you can find on the Haskell wiki here: http://www.haskell.org/haskellwiki/APL However, we have all gone our separate ways, and I think it's entirely possible that that the idea will go no further. So this message is to ask: * Is anyone interested in an APL-style array library in Haskell? * If so, would you like to lead the process of developing the API? I think there are quite a few people who would be willing to contribute, including some core gurus from the APL community: John Scholes, Arthur Whitney, and Roger Hui. Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Extending Type Classes
See http://ghc.haskell.org/trac/ghc/wiki/DefaultSuperclassInstances | -Original Message- | From: Haskell-Cafe [mailto:haskell-cafe-boun...@haskell.org] On Behalf | Of Henning Thielemann | Sent: 26 August 2013 20:07 | To: Frantisek Farka | Cc: Haskell Cafe | Subject: Re: [Haskell-cafe] Extending Type Classes | | | The problem of refinement of type classes annoys me from time to time | when I work on the NumericPrelude. It is an experimental type class | hierarchy for mathematical types. Sometimes a new data type T shall be | implemented and it turns out that you can implement only a part of all | methods of a certain class. Then a natural step is to split the class | into | two classes A and B: 'A' contains the methods we can implement for T and | 'B' contains the remaining methods and 'B' is a sub-class of 'A'. | First, this means that all client code has to be rewritten. Second, | code | for instances becomes very lengthy, because over the time code tends to | contain one instances for every method. However the many small instances | actually carry information: Every instance has its specialised | constraints. E.g. you would certainly try to use only Applicative | constraints in an Applicative instance and not Monad constraints. | However, | if there is a way to define Applicative and Monad instances in one go, | the | Applicative instance may get Monad constraints. | | ___ | Haskell-Cafe mailing list | Haskell-Cafe@haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What am I missing? Cycle in type synonym declarations
GHC tries to typecheck quotations. In this case it's trying to typecheck the
declaration
type Bar = FooT $t
Part of type checking is rejecting recursive type synonyms. Here GHC is
rejecting it because it *might* be recursive, depending on how $t is filled in.
The trouble is that we really *can't* typecheck partial declarations like this
one. All this will be fixed when we fold in the new Template Haskell story
(it'll be in 7.8). See my blog post on the GHC Trac (from about 2 yrs ago)
describing the change. (I'm on a train so don't know the URL.) Geoff has made
the change... it just needs to be merged in.
Simon
| -Original Message-
| From: Haskell-Cafe [mailto:haskell-cafe-boun...@haskell.org] On Behalf Of
David
| Fox
| Sent: 20 August 2013 22:00
| To: Haskell Cafe
| Subject: [Haskell-cafe] What am I missing? Cycle in type synonym declarations
|
| This file gives me the error Cycle in type synonym declarations Can
| anyone tell me why? I'm just trying to write a function to create a
| type that is a FooT with the type parameter fixed.
|
| {-# LANGUAGE TemplateHaskell #-}
| import Language.Haskell.TH (Q, Dec, TypeQ)
|
| data FooT a = FooT a
|
| foo :: TypeQ - Q [Dec]
| foo t = [d| type Bar = FooT $t |]
|
| ___
| Haskell-Cafe mailing list
| Haskell-Cafe@haskell.org
| http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Alternative name for return
| Indeed, I wished the 0-ary case would be more alike to the unary and | binary case, cf. | | return f0 | f1 $ a1 | f2 $ a1 * a2 | | What is needed is a nice syntax for idiom brackets. Indeed. I'm quite open to adding idiom brackets to GHC, if everyone can agree on their syntax, and someone would like to offer a patch. Something like (| f a1 a2 |) perhaps? Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] type-level integers for GHC
The type-nats branch *should* simply work all by itself. (You may need to check out a corresponding branch on some other repos, though.) Iavor would you care to comment? Simon Microsoft Research Limited (company number 03369488) is registered in England and Wales Registered office 21 Station Road, Cambridge, CB1 2FB | -Original Message- | From: Christiaan Baaij [mailto:christiaan.ba...@gmail.com] | Sent: 20 May 2013 09:56 | To: Takayuki Muranushi | Cc: Simon Peyton-Jones; haskell | Subject: Re: [Haskell-cafe] type-level integers for GHC | | What works best for me is to actually merge the type-nats branch into a | local checkout of master; as opposed to checking out the type-nats | branch. | Though you will usually have to do some (minor) conflict resolution. | | -- Christiaan | | On May 17, 2013, at 11:13 PM, Takayuki Muranushi muranu...@gmail.com | wrote: | | Hey thanks Simon and Levor, I've reported the problem month ago, and I | see today the commit-id for type-nats is still not changed. So I | thought the problem remains. Let me first try the compile process | again tonight, and report the compile process in more detail. | | 2013/5/17 Simon Peyton-Jones simo...@microsoft.com: | I wonder why you can't compile type-nats? It should just work. You | could email ghc-devs and Iavor (type-nats author, cc'd) explaining | exactly what goes wrong. You may need the type-nats branch of some | libraries, I'm not sure | | Simon | | Microsoft Research Limited (company number 03369488) is registered in | England and Wales Registered office 21 Station Road, Cambridge, CB1 | 2FB | | | | -Original Message- | | From: haskell-cafe-boun...@haskell.org [mailto:haskell-cafe- | | boun...@haskell.org] On Behalf Of Takayuki Muranushi | | Sent: 17 May 2013 07:18 | | To: haskell | | Subject: [Haskell-cafe] type-level integers for GHC | | | | What is your recommendation for type-level integers? | | | | I'd like to use it to improve the unittyped, | | https://bitbucket.org/xnyhps/haskell-unittyped/ the library for | | physical dimension. Therefore, I need negative numbers, additions, | | but multiplications are not necessary. | | | | I've been looking forward for the type-nats extension of GHC, but I | | haven't been able to compile the type-nats branch. Just learned | | that it still takes a few month to merge the branch into the main. | | http://hackage.haskell.org/trac/ghc/wiki/Status/May13 | | | | Thijs, the original author of unittyped, has commited a branch that | | uses type-nats, but I can't try that out for the same reason. | | | | | | Best, | | -- | | Takayuki MURANUSHI | | The Hakubi Center for Advanced Research, Kyoto University | | http://www.hakubi.kyoto-u.ac.jp/02_mem/h22/muranushi.html | | | | ___ | | Haskell-Cafe mailing list | | Haskell-Cafe@haskell.org | | http://www.haskell.org/mailman/listinfo/haskell-cafe | | | | -- | Takayuki MURANUSHI | The Hakubi Center for Advanced Research, Kyoto University | http://www.hakubi.kyoto-u.ac.jp/02_mem/h22/muranushi.html | | ___ | Haskell-Cafe mailing list | Haskell-Cafe@haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] type-level integers for GHC
I wonder why you can't compile type-nats? It should just work. You could email ghc-devs and Iavor (type-nats author, cc'd) explaining exactly what goes wrong. You may need the type-nats branch of some libraries, I'm not sure Simon Microsoft Research Limited (company number 03369488) is registered in England and Wales Registered office 21 Station Road, Cambridge, CB1 2FB | -Original Message- | From: haskell-cafe-boun...@haskell.org [mailto:haskell-cafe- | boun...@haskell.org] On Behalf Of Takayuki Muranushi | Sent: 17 May 2013 07:18 | To: haskell | Subject: [Haskell-cafe] type-level integers for GHC | | What is your recommendation for type-level integers? | | I'd like to use it to improve the unittyped, | https://bitbucket.org/xnyhps/haskell-unittyped/ the library for physical | dimension. Therefore, I need negative numbers, additions, but | multiplications are not necessary. | | I've been looking forward for the type-nats extension of GHC, but I | haven't been able to compile the type-nats branch. Just learned that it | still takes a few month to merge the branch into the main. | http://hackage.haskell.org/trac/ghc/wiki/Status/May13 | | Thijs, the original author of unittyped, has commited a branch that uses | type-nats, but I can't try that out for the same reason. | | | Best, | -- | Takayuki MURANUSHI | The Hakubi Center for Advanced Research, Kyoto University | http://www.hakubi.kyoto-u.ac.jp/02_mem/h22/muranushi.html | | ___ | Haskell-Cafe mailing list | Haskell-Cafe@haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Backward compatibility
One of the great things about the Haskell mailing lists is the supportive, respectful tone that is the dominant mode of discourse. I sense that things are getting a little out of control in this particular thread. Even though this particular issue is clearly extremely frustrating for those involved, it would be great to turn down the emotional temperature. I don’t know why Haskell folk tend to be so generous and helpful, but they really are. (Maybe it’s the hylomorphisms.) Anyway, let’s keep it that way. Simon From: haskell-cafe-boun...@haskell.org [mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Gregory Collins Sent: 03 May 2013 08:27 To: Adrian May Cc: Haskell Cafe Subject: Re: [Haskell-cafe] Backward compatibility On Fri, May 3, 2013 at 6:48 AM, Adrian May adrian.alexander@gmail.commailto:adrian.alexander@gmail.com wrote: May I venture a guess that you never tried to manage a 5-10 million line project? I build a project a couple orders of magnitude bigger than that dozens of times every day. Similar stories are not uncommon among people who inhabit this list. But thanks, citing that figure as an excuse to be condescending to that person was really worth a giggle this morning. :) That's what I do. I'm not a programmer, I'm a manager. I run teams of a few dozen people on subprojects within huge telecom-related projects, and my job is to try and keep it all from collapsing in a heap of bugs. If you had any experience of that you'd run a mile from any technology with this hit and miss attitude. You keep saying things like this. Actually, you're in this situation because one or more people within your organization have made a succession of very bad choices. Haskell is not to blame. Personally, I almost can't believe you're taking this tack on the list now that the details of your situation are apparent: you've let a 5-10 million line project spiral out of control without putting the necessary software engineering infrastructure and controls in place. I can't tell people what version they should be using because half of them work for a completely different company. They have their own dependencies coming from other projects that I'm not even allowed to know about. ... and the truth emerges. This issue you're having reflects a lot more strongly on your technical culture than it does on any instability in GHC. Listen: someone within your organization decided to build a product based on a very old library which is no longer maintained by anyone. If this library were actually critical to your business, you would fork it and either get someone in-house or pay a contractor to fix bugs and keep it up to date. (And there are plenty of people here who might be interested in a contract gig to fix this for you if you asked). Repeatedly claiming in the most histrionic terms that GHC ought to freeze forever and never deprecate anything again so that you can avoid doing your job properly is simply not realistic, especially given Haskell's social culture (newsflash: it's a research platform), and is not going to garner you any sympathy on this list, either. You could practically be the poster boy for why we have the motto avoid success at all costs. You have two options: stay on GHC 6.x (the bits didn't get deleted from the internet), and if that isn't practical, fix Wash (or pay someone to do it if you don't know how) and get on with your life. G -- Gregory Collins g...@gregorycollins.netmailto:g...@gregorycollins.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Where's the case? or The difference between simpl and prep
Check out
http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/HscMain
and the notes at the top of
http://darcs.haskell.org/ghc/compiler/coreSyn/CorePrep.lhs
Beyond that I'm happy to help
Simon
| -Original Message-
| From: haskell-cafe-boun...@haskell.org [mailto:haskell-cafe-
| boun...@haskell.org] On Behalf Of Tom Ellis
| Sent: 14 March 2013 20:05
| To: Haskell Cafe
| Subject: [Haskell-cafe] Where's the case? or The difference between simpl and
| prep
|
| The -ddump-simpl output below doesn't contain a case corresponding to the
| seq in sum', but the -ddump-prep does. Isn't the output from simpl the
| input to prep? If so, where does the case reappear from? If not, how are
| simpl and prep related?
|
| It seems to have something to do with Str=DmdType SS but I don't
| understand. This seems to come from the IdInfo on the Id which is the
| binder Test.sum' but [1] says that this information is optional so it
| seems strange that such crucial information would be encoded there.
|
| Thanks,
|
| Tom
|
| [1] http://www.haskell.org/ghc/docs/7.6.2/html/libraries/ghc-
| 7.6.2/IdInfo.html#t:IdInfo
|
|
| % cat Test.hs
| module Test where
|
| sum' :: [Integer] - Integer - Integer
| sum' [] n = n
| sum' (x:xs) n = n `seq` sum' xs (n + x)
| % ghc -fforce-recomp -ddump-simpl -O2 Test.hs
| [1 of 1] Compiling Test ( Test.hs, Test.o )
|
| Tidy Core
| Result size = 14
|
| Rec {
| Test.sum' [Occ=LoopBreaker]
|:: [GHC.Integer.Type.Integer]
| - GHC.Integer.Type.Integer - GHC.Integer.Type.Integer
| [GblId, Arity=2, Caf=NoCafRefs, Str=DmdType SS]
| Test.sum' =
|\ (ds_daw :: [GHC.Integer.Type.Integer])
| (n_a9J :: GHC.Integer.Type.Integer) -
| case ds_daw of _ {
|[] - n_a9J;
|: x_a9K xs_a9L -
| Test.sum' xs_a9L (GHC.Integer.Type.plusInteger n_a9J x_a9K)
| }
| end Rec }
|
|
|
| % ghc -fforce-recomp -ddump-prep -O2 Test.hs
| [1 of 1] Compiling Test ( Test.hs, Test.o )
|
| CorePrep
| Result size = 17
|
| Rec {
| Test.sum' [Occ=LoopBreaker]
|:: [GHC.Integer.Type.Integer]
| - GHC.Integer.Type.Integer - GHC.Integer.Type.Integer
| [GblId, Arity=2, Caf=NoCafRefs, Str=DmdType SS, Unf=OtherCon []]
| Test.sum' =
|\ (ds_saQ :: [GHC.Integer.Type.Integer])
| (n_saS :: GHC.Integer.Type.Integer) -
| case ds_saQ of _ {
|[] - n_saS;
|: x_saW xs_saV -
| case GHC.Integer.Type.plusInteger n_saS x_saW
| of sat_saZ { __DEFAULT -
| Test.sum' xs_saV sat_saZ
| }
| }
| end Rec }
|
| ___
| Haskell-Cafe mailing list
| Haskell-Cafe@haskell.org
| http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] RFC: rewrite-with-location proposal
Do you mean that the proposal itself won't work, or specifically implementing
this features in terms of existing rewrite rules won't work?
I meant the latter.
I'll admit to ignorance on the internals of GHC, but it seems like doing the
shallow source location approach would be far simpler than a full trace. I'd
hate to lose a very valuable feature because we can't implement the perfect
feature.
I agree with that sentiment. But in fact I suspect that getting a stack is
little or no harder than the shallow thing.
My implicit parameter suggestion was trying to re-use an existing feature,
with a small twist, to do what you want, rather than to implement something
brand new.
Simon
From: michael.snoy...@gmail.com [mailto:michael.snoy...@gmail.com] On Behalf Of
Michael Snoyman
Sent: 25 February 2013 18:19
To: Simon Peyton-Jones
Cc: Alexander Kjeldaas; Simon Hengel; Haskell Cafe
Subject: Re: [Haskell-cafe] RFC: rewrite-with-location proposal
On Mon, Feb 25, 2013 at 4:42 PM, Simon Peyton-Jones
simo...@microsoft.commailto:simo...@microsoft.com wrote:
I'm afraid the rewrite-rule idea won't work. RULES are applied during
optimisation, when tons of inlining has happened and the program has been
shaken around a lot. No reliable source location information is available there.
Do you mean that the proposal itself won't work, or specifically implementing
this features in terms of existing rewrite rules won't work?
See http://hackage.haskell.org/trac/ghc/wiki/ExplicitCallStack; and please edit
it.
One thing I'd disagree with on that page is point (3). While it's certainly
nice to have a full stack trace, implementing just shallow call information is
incredibly useful. For logging and test framework usages, it in fact completely
covers the use case. And even for debugging, I think it would be a massive step
in the right direction.
I'll admit to ignorance on the internals of GHC, but it seems like doing the
shallow source location approach would be far simpler than a full trace. I'd
hate to lose a very valuable feature because we can't implement the perfect
feature.
One idea I had, which that page does not yet describe, is to have an implicit
parameter,
something like ?loc::Location, with
errLoc :: ?loc:Location = String - a
errLoc s = error (At ++ ?loc ++ \n ++ s)
This behave exactly like an ordinary implicit parameter, EXCEPT that if there
is no binding for ?loc::Location, then the current location is used. Thus
myErr :: ?loc:Location = Int - a
myErr n = errLoc (show n)
foo :: Int - int
foo n | n0 = myErr n
| otherwise = ...whatever...
When typechecking 'foo' we need ?loc:Location, and so the magic is that we use
the location of the call of myErr in foo.
Simon
From: haskell-cafe-boun...@haskell.orgmailto:haskell-cafe-boun...@haskell.org
[mailto:haskell-cafe-boun...@haskell.orgmailto:haskell-cafe-boun...@haskell.org]
On Behalf Of Alexander Kjeldaas
Sent: 25 February 2013 12:16
To: Simon Hengel
Cc: Haskell Cafe
Subject: Re: [Haskell-cafe] RFC: rewrite-with-location proposal
On Mon, Feb 25, 2013 at 12:46 PM, Simon Hengel
s...@typeful.netmailto:s...@typeful.net wrote:
On Mon, Feb 25, 2013 at 10:40:29AM +0100, Twan van Laarhoven wrote:
I think there is no need to have a separate REWRITE_WITH_LOCATION
rule. What if the compiler instead rewrites 'currentLocation' to the
current location? Then you'd just define the rule:
{-# REWRITE errorLoc error = errorLoc currentLocation #-}
REWRITE rules are only enabled with -O. Source locations are also
useful during development (when you care more about compilation time
than efficient code and hence use -O0). So I'm not sure whether it's a
good idea to lump those two things together.
I could imagine that source locations being useful when debugging rewrite rules
for example.
I think your argument makes sense, but why not fix that specifically?
{-# REWRITE ALWAYS errorLoc error = errorLoc currentLocation #-}
Alexander
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.orgmailto:Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] RFC: rewrite-with-location proposal
I’m afraid the rewrite-rule idea won’t work. RULES are applied during
optimisation, when tons of inlining has happened and the program has been
shaken around a lot. No reliable source location information is available there.
See http://hackage.haskell.org/trac/ghc/wiki/ExplicitCallStack; and please edit
it.
One idea I had, which that page does not yet describe, is to have an implicit
parameter,
something like ?loc::Location, with
errLoc :: ?loc:Location = String - a
errLoc s = error (“At “ ++ ?loc ++ “\n” ++ s)
This behave exactly like an ordinary implicit parameter, EXCEPT that if there
is no binding for ?loc::Location, then the current location is used. Thus
myErr :: ?loc:Location = Int - a
myErr n = errLoc (show n)
foo :: Int - int
foo n | n0 = myErr n
| otherwise = ...whatever...
When typechecking ‘foo’ we need ?loc:Location, and so the magic is that we use
the location of the call of myErr in foo.
Simon
From: haskell-cafe-boun...@haskell.org
[mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Alexander Kjeldaas
Sent: 25 February 2013 12:16
To: Simon Hengel
Cc: Haskell Cafe
Subject: Re: [Haskell-cafe] RFC: rewrite-with-location proposal
On Mon, Feb 25, 2013 at 12:46 PM, Simon Hengel
s...@typeful.netmailto:s...@typeful.net wrote:
On Mon, Feb 25, 2013 at 10:40:29AM +0100, Twan van Laarhoven wrote:
I think there is no need to have a separate REWRITE_WITH_LOCATION
rule. What if the compiler instead rewrites 'currentLocation' to the
current location? Then you'd just define the rule:
{-# REWRITE errorLoc error = errorLoc currentLocation #-}
REWRITE rules are only enabled with -O. Source locations are also
useful during development (when you care more about compilation time
than efficient code and hence use -O0). So I'm not sure whether it's a
good idea to lump those two things together.
I could imagine that source locations being useful when debugging rewrite rules
for example.
I think your argument makes sense, but why not fix that specifically?
{-# REWRITE ALWAYS errorLoc error = errorLoc currentLocation #-}
Alexander
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Advice on type families and non-injectivity?
| {-# LANGUAGE TypeFamilies #-}
|
| type family F a
|
| foo :: F a
| foo = undefined
|
| bar :: F a
| bar = foo
There is a real difficulty here with type-checking 'bar'. (And that difficulty
is why 'foo' is also rejected.)
Namely, when typechecking 'bar', we must instantiate foo with an unknown type,
say alpha. So now we must find a type 'alpha' such that
F a ~ F alpha
Certainly alpha=1 is one solution, but there might be others. For example,
suppose
type instance F [b] = F b
Then alpha=[a] would also be a solution.
In this particular case any solution will do, but suppose there was an addition
constraint (C alpha) arising from the right hand side, where C is a class.
Then if we had
instance C [b] where ...
then the second solution (alpha=[a]) would work, but not the first. This can
get arbitrarily complicated, and GHC's type inference does not search various
solutions; it follows one path.
The solution is to provide a way to fix alpha. For example,
foo :: a - F a
is fine.
Simon
| -Original Message-
| From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell-
| users-boun...@haskell.org] On Behalf Of Richard Eisenberg
| Sent: 14 January 2013 03:47
| To: Conal Elliott
| Cc: glasgow-haskell-us...@haskell.org; Haskell Cafe
| Subject: Re: Advice on type families and non-injectivity?
|
| Hi Conal,
|
| I agree that your initial example is a little puzzling, and I'm glad
| that the new ambiguity checker prevents both definitions, not just one.
|
| However, your initial question seems broader than just this example. I
| have run into this problem (wanting injective type functions) several
| times myself, and have been successful at finding workarounds. But, I
| can't think of any unifying principle or solid advice. If you can post
| more information about your problem, perhaps I or others can contribute.
|
| For what it's worth, the desire for injective type functions has been
| entered as ticket #6018 in the GHC Trac, but I see you're already on the
| cc: list. I believe Simon PJ has given serious thought to implementing
| this feature and may have even put in some very basic code toward this
| end.
|
| Richard
|
| On Jan 13, 2013, at 2:10 PM, Conal Elliott co...@conal.net wrote:
|
| I sometimes run into trouble with lack of injectivity for type
| families. I'm trying to understand what's at the heart of these
| difficulties and whether I can avoid them. Also, whether some of the
| obstacles could be overcome with simple improvements to GHC.
|
| Here's a simple example:
|
| {-# LANGUAGE TypeFamilies #-}
|
| type family F a
|
| foo :: F a
| foo = undefined
|
| bar :: F a
| bar = foo
|
| The error message:
|
| Couldn't match type `F a' with `F a1'
| NB: `F' is a type function, and may not be injective
| In the expression: foo
| In an equation for `bar': bar = foo
|
| A terser (but perhaps subtler) example producing the same error:
|
| baz :: F a
| baz = baz
|
| Replacing `a` with a monotype (e.g., `Bool`) eliminates the error.
|
| Does the difficulty here have to do with trying to *infer* the type
| and then compare with the given one? Or is there an issue even with type
| *checking* in such cases?
|
| Other insights welcome, as well as suggested work-arounds.
|
| I know about (injective) data families but don't want to lose the
| convenience of type synonym families.
|
| Thanks, -- Conal
|
| ___
| Glasgow-haskell-users mailing list
| glasgow-haskell-us...@haskell.org
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
|
|
| ___
| Glasgow-haskell-users mailing list
| glasgow-haskell-us...@haskell.org
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Advice on type families and non-injectivity?
Oh! Is the definition of 'foo' rejected in recent versions of GHC? My 7.4.1
installation doesn't complain. -- Conal
Yes, it is rejected.
Simon
From: conal.elli...@gmail.com [mailto:conal.elli...@gmail.com] On Behalf Of
Conal Elliott
Sent: 14 January 2013 20:52
To: Simon Peyton-Jones
Cc: Richard Eisenberg; glasgow-haskell-us...@haskell.org; Haskell Cafe
Subject: Re: Advice on type families and non-injectivity?
There is a real difficulty here with type-checking 'bar'. (And that difficulty
is why 'foo' is also rejected.)
Oh! Is the definition of 'foo' rejected in recent versions of GHC? My 7.4.1
installation doesn't complain. -- Conal
On Mon, Jan 14, 2013 at 3:39 AM, Simon Peyton-Jones
simo...@microsoft.commailto:simo...@microsoft.com wrote:
| {-# LANGUAGE TypeFamilies #-}
|
| type family F a
|
| foo :: F a
| foo = undefined
|
| bar :: F a
| bar = foo
There is a real difficulty here with type-checking 'bar'. (And that difficulty
is why 'foo' is also rejected.)
Namely, when typechecking 'bar', we must instantiate foo with an unknown type,
say alpha. So now we must find a type 'alpha' such that
F a ~ F alpha
Certainly alpha=1 is one solution, but there might be others. For example,
suppose
type instance F [b] = F b
Then alpha=[a] would also be a solution.
In this particular case any solution will do, but suppose there was an addition
constraint (C alpha) arising from the right hand side, where C is a class.
Then if we had
instance C [b] where ...
then the second solution (alpha=[a]) would work, but not the first. This can
get arbitrarily complicated, and GHC's type inference does not search various
solutions; it follows one path.
The solution is to provide a way to fix alpha. For example,
foo :: a - F a
is fine.
Simon
| -Original Message-
| From:
glasgow-haskell-users-boun...@haskell.orgmailto:glasgow-haskell-users-boun...@haskell.org
[mailto:glasgow-haskell-mailto:glasgow-haskell-
| users-boun...@haskell.orgmailto:users-boun...@haskell.org] On Behalf Of
Richard Eisenberg
| Sent: 14 January 2013 03:47
| To: Conal Elliott
| Cc:
glasgow-haskell-us...@haskell.orgmailto:glasgow-haskell-us...@haskell.org;
Haskell Cafe
| Subject: Re: Advice on type families and non-injectivity?
|
| Hi Conal,
|
| I agree that your initial example is a little puzzling, and I'm glad
| that the new ambiguity checker prevents both definitions, not just one.
|
| However, your initial question seems broader than just this example. I
| have run into this problem (wanting injective type functions) several
| times myself, and have been successful at finding workarounds. But, I
| can't think of any unifying principle or solid advice. If you can post
| more information about your problem, perhaps I or others can contribute.
|
| For what it's worth, the desire for injective type functions has been
| entered as ticket #6018 in the GHC Trac, but I see you're already on the
| cc: list. I believe Simon PJ has given serious thought to implementing
| this feature and may have even put in some very basic code toward this
| end.
|
| Richard
|
| On Jan 13, 2013, at 2:10 PM, Conal Elliott
co...@conal.netmailto:co...@conal.net wrote:
|
| I sometimes run into trouble with lack of injectivity for type
| families. I'm trying to understand what's at the heart of these
| difficulties and whether I can avoid them. Also, whether some of the
| obstacles could be overcome with simple improvements to GHC.
|
| Here's a simple example:
|
| {-# LANGUAGE TypeFamilies #-}
|
| type family F a
|
| foo :: F a
| foo = undefined
|
| bar :: F a
| bar = foo
|
| The error message:
|
| Couldn't match type `F a' with `F a1'
| NB: `F' is a type function, and may not be injective
| In the expression: foo
| In an equation for `bar': bar = foo
|
| A terser (but perhaps subtler) example producing the same error:
|
| baz :: F a
| baz = baz
|
| Replacing `a` with a monotype (e.g., `Bool`) eliminates the error.
|
| Does the difficulty here have to do with trying to *infer* the type
| and then compare with the given one? Or is there an issue even with type
| *checking* in such cases?
|
| Other insights welcome, as well as suggested work-arounds.
|
| I know about (injective) data families but don't want to lose the
| convenience of type synonym families.
|
| Thanks, -- Conal
|
| ___
| Glasgow-haskell-users mailing list
| glasgow-haskell-us...@haskell.orgmailto:glasgow-haskell-us...@haskell.org
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
|
|
| ___
| Glasgow-haskell-users mailing list
| glasgow-haskell-us...@haskell.orgmailto:glasgow-haskell-us...@haskell.org
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
[Haskell-cafe] The end of an era, and the dawn of a new one
Friends You'll have seen Simon Marlow's recent announcement (included below): | Today I'm announcing that I'm leaving Microsoft Research. Simon Marlow and I have worked together on GHC for nearly two decades. During much of that time we have shared a cup of coffee every morning (one cup each, since you ask), to discuss what's going on in GHC-land. We had frequent detailed and illuminating debates about design alternatives. Simon is the absolute master of GHC's code generation, runtime system, garbage collector, support for parallel execution, and much else besides. His sheer programming skill in rooting out obscure and hard-to-reproduce runtime system bugs has always amazed me. He is more than just a great hacker, of course. He is a leader in our community, has a strong publication record, chaired the Haskell Prime committee for a year, and is sought after for tutorials about parallel programming. I owe Simon a great debt, as I think we all do, for the care and skill he has lavished on GHC. He's not going to disappear entirely, but he will be spending much less time on GHC than in the past. That is a change, but it's a change that was always going to happen sometime, and while change is sometimes uncomfortable, it can also open up new possibilities. GHC is over 20, and like my own children (who are actually all a bit younger than GHC), that's not a bad time to start to head out into the world. Over time, more and more people have started to help with the task of developing and maintaining GHC. We'll have to do more of that. These days GHC has a very large surface area (running on different platforms, dynamic linking, debugger, profiler, GHCi, libraries and Cabal, etc etc), and has grown far beyond what any single person or research group can manage. Lest you should wonder, I myself will certainly continue to work on GHC. But my job is to be a *researcher*, and I am not well equipped -- in temperament or expertise -- to deal with the myriad complexities of deployment, upgrade policy, portability, and the like. Well Typed (mostly in the guise of Ian Lynagh) will continue to handle some of these issues, but again there is too much for one person to do. So we need your help. Seriously. Rather than just thinking GHC HQ will sort it out, I would welcome you saying Shall I take responsibility for X?. Johan, Bryan, and others offering to be GHC Performance Tsars is a great recent example. But don't wait to be asked: just make an offer if you see a gap or an open ticket --- and I think there will be plenty of those. Particularly valuable are offers to take responsibility for a particular area (eg the LLVM code generator, or the FFI). I'm hoping that this sea change will prove to be quite empowering, with GHC becoming more and more a community project, more resilient with fewer single points of failure. I am going to miss that cup of coffee though. Thank you Simon! Facebook is lucky to have you. Onward and upward. Simon (PJ) | -Original Message- | From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell- | users-boun...@haskell.org] On Behalf Of Simon Marlow | Sent: 22 November 2012 11:27 | To: haskell; glasgow-haskell-us...@haskell.org | Subject: Leaving Microsoft | | Today I'm announcing that I'm leaving Microsoft Research. | | My plan is to take a break to finish the book on Parallel and Concurrent | Haskell for O'Reilly, before taking up a position at Facebook in the UK | in March 2013. | | This is undoubtedly a big change, both for me and for the Haskell | community. I'll be stepping back from full-time GHC development and | research and heading into industry, hopefully to use Haskell. It's an | incredibly exciting opportunity for me, and one that I hope will | ultimately be a good thing for Haskell too. | | What does this mean for GHC? Obviously I'll have much less time to work | on GHC, but I do hope to find time to fix a few bugs and keep things | working smoothly. Simon Peyton Jones will still be leading the project, | and we'll still have support from Ian Lynagh, and of course the | community of regular contributors. Things are in a reasonably stable | state - there haven't been any major architectural changes in the RTS | lately, and while we have just completed the switchover to the new code | generator, I've been working over the past few weeks to squeeze out all | the bugs I can find, and I'll continue to do that over the coming months | up to the 7.8.1 release. | | In due course I hope that GHC can attract more of you talented hackers | to climb the learning curve and start working on the internals, in | particular the runtime and code generators, and I'll do my best to help | that happen. | | Cheers, | Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Erroneous interaction between DataKinds and ExistentialQuantification?
Quite right -- a bug. Thank you. I'll add it to the regression suite
Simon
| -Original Message-
| From: haskell-cafe-boun...@haskell.org [mailto:haskell-cafe-
| boun...@haskell.org] On Behalf Of Stefan Holdermans
| Sent: 17 October 2012 21:45
| To: Haskell Cafe
| Cc: José Pedro Magalhães
| Subject: [Haskell-cafe] Erroneous interaction between DataKinds and
| ExistentialQuantification?
|
| I am almost sure this is a known issue, but I noticed some erroneous (?)
| interaction between datatype promotion and existential quantification.
Consider
| the following program:
|
|{-# LANGUAGE DataKinds #-}
|{-# LANGUAGE ExistentialQuantification #-}
|{-# LANGUAGE GADTs #-}
|{-# LANGUAGE KindSignatures#-}
|
|module Test where
|
|data K = forall a. T a -- promotion gives 'T :: * - K
|
|data G :: K - * where
| D :: G (T []) -- kind error!
|
| I would expect the type checker to reject it, but GHC (version 7.6.1)
compiles it
| happily. Is this indeed a (known) bug?
|
| On a related note: is there a way to promote a type that involves an
existential
| type variable of a kind other than *?
|
| Thanks,
|
|Stefan
| ___
| Haskell-Cafe mailing list
| Haskell-Cafe@haskell.org
| http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Call for discussion: OverloadedLists extension
| Here at the University of Tübingen, I am co-supervising (together with | Jeroen Weijers) a student project implementing the OverloadedLists | extension for GHC. Achim Krause is the student who is working on the | project. We took into consideration earlier discussions on this topic | [1,2] before embarking on the project. | | Achim has worked on two approaches. Your second approach is this: | [x,y,z] | | as | | singleton x `mappend` singleton y `mappend` singleton z ; This approach is not good for long literal lists, because you get tons of executable code where the user thought he was just defining a data structure. And long literal lists are an important use-case. One other possibility is to use a variant of what GHC does for literal strings. Currently foo turns into unpackCString foo# where foo# is a statically allocate C string, and the unpackCString unpacks it lazily. Maybe we could make a literal [a,b.c] turn into unpack [a,b,c]# where [a,b,c]# is a statically-allocated vector? See http://hackage.haskell.org/trac/ghc/ticket/5218, which is stalled awaiting brain cycles from someone. I'm maxed out at the moment. I'd be very happy if you guys were able to make progress; I'm happy to advise. Open a ticket, start a wiki page, etc! Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Call for discussion: OverloadedLists extension
| pointer to the actual data somewhere in memory and use that. This is | more or less what happens for strings at the moment, even though you | have to use rewrite rules to get at the pointer which, in my opinion, is | neither ideal nor really necessary. IMO, the right design shouldn't | rely on rewrite rules. Also, strings give you an Addr# whereas vector | supports ByteArray#, too. If it's not necessary, I wonder if you have an idea for the right design? I find it a lot easier to see what is wrong with the current situation than to think of solutions. Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Call for discussion: OverloadedLists extension
| Many of us use the OverloadedStrings language extension on a regular | basis. It provides the ability to keep the ease-of-use of string | literal syntax, while getting the performance and correctness | advantages of specialized datatypes like ByteString and Text. I think | we can get the same kind of benefit by allowing another literal syntax | to be overloaded, namely lists. Interestingly, Achim Krause, George Giorgidze and Jeroen Weijers have been thinking about this very question. They have most of an implementation too. I'm ccing them so they can post a status update. Your email broadens the topic somewhat; I don't think we'd considered overloading for maps too, though I can see it makes sense. I'd much prefer the type-family solution (with a single-parameter type class) to the fundep one, if we go that route. This topic deserves its own page on the GHC wiki, if someone wants to start one. If we can evolve a design consensus, I'm happy to incorporate the result in GHC. Simon | -Original Message- | From: haskell-cafe-boun...@haskell.org [mailto:haskell-cafe- | boun...@haskell.org] On Behalf Of Michael Snoyman | Sent: 23 September 2012 05:07 | To: Haskell Cafe | Subject: [Haskell-cafe] Call for discussion: OverloadedLists extension | | (Prettier formatting available at: https://gist.github.com/3761252) | | Many of us use the OverloadedStrings language extension on a regular | basis. It provides the ability to keep the ease-of-use of string | literal syntax, while getting the performance and correctness | advantages of specialized datatypes like ByteString and Text. I think | we can get the same kind of benefit by allowing another literal syntax | to be overloaded, namely lists. | | ## Overly simple approach | | The simplest example I can think of is allowing easier usage of Vector: | | [1, 2, 3] :: Vector Int | | In order to allow this, we could use a typeclass approach similar to | how OverloadedStrings works: | | class IsList a where | fromList :: [b] - a b | instance IsList Vector where | fromList = V.fromList | foo :: Vector Int | foo = fromList [1, 2, 3] | | ## Flaws | | However, such a proposal does not allow for constraints, e.g.: | | instance IsList Set where | fromList = Set.fromList | | No instance for (Ord b) |arising from a use of `Set.fromList' | In the expression: Set.fromList | In an equation for `fromList': fromList = Set.fromList | In the instance declaration for `IsList Set' | | Additionally, it provides for no means of creating instances for | datatypes like Map, where the contained value is not identical to the | value contained in the original list. In other words, what I'd like to | see is: | | [(foo, 1), (bar, 2)] :: Map Text Int | | ## A little better: MPTC | | A simplistic approach to solve this would be to just use MultiParamTypeClasses: | | class IsList input output where | fromList :: [input] - output | instance IsList a (Vector a) where | fromList = V.fromList | foo :: Vector Int | foo = fromList [1, 2, 3] | | Unfortunately, this will fail due to too much polymorphism: | | No instance for (IsList input0 (Vector Int)) |arising from a use of `fromList' | Possible fix: |add an instance declaration for (IsList input0 (Vector Int)) | In the expression: fromList [1, 2, 3] | In an equation for `foo': foo = fromList [1, 2, 3] | | This can be worked around by giving an explicit type signature on the | numbers in the list, but that's not a robust solution. In order to | solve this properly, I think we need either functional dependencies or | type families: | | ## Functional dependencies | | class IsList input output | output - input where | fromList :: [input] - output | instance IsList a (Vector a) where | fromList = V.fromList | instance Ord a = IsList a (Set a) where | fromList = Set.fromList | instance Ord k = IsList (k, v) (Map k v) where | fromList = Map.fromList | | foo :: Vector Int | foo = fromList [1, 2, 3] | | bar :: Set Int | bar = fromList [1, 2, 3] | | baz :: Map String Int | baz = fromList [(foo, 1), (bar, 2)] | | ## Type families | | class IsList a where | type IsListInput a | fromList :: [IsListInput a] - a | instance IsList (Vector a) where | type IsListInput (Vector a) = a | fromList = V.fromList | instance Ord a = IsList (Set a) where | type IsListInput (Set a) = a | fromList = Set.fromList | instance Ord k = IsList (Map k v) where | type IsListInput (Map k v) = (k, v) | fromList = Map.fromList | | foo :: Vector Int | foo = fromList [1, 2, 3] | | bar :: Set Int | bar = fromList [1,
Re: [Haskell-cafe] Call for discussion: OverloadedLists extension
| I remember a similar discussion a few years ago. The question of whether | or not overloading list literals a good idea notwithstanding, the problem | with this is that fromList for vectors is highly inefficient. So if | something like this gets implemented and if vector/array literals are one | of the main motivations then I really hope there will be no lists | involved. Would you like to remind us why it is so inefficient? Can't the vector construction be a fold over the list? Ah... you need to know the *length* of the list, don't you? So that you can allocate a suitably-sized vector. Which of course we do for literal lists. So what if fromList went fromList :: Int - [b] - a b where the Int is the length of the list? Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] why do I need class context in declaring data constructor?
Aha. See http://hackage.haskell.org/trac/ghc/ticket/7205.
I don't think there's a workaround, I'm afraid
Simon
| -Original Message-
| From: haskell-cafe-boun...@haskell.org [mailto:haskell-cafe-
| boun...@haskell.org] On Behalf Of Paul Liu
| Sent: 30 August 2012 20:52
| To: Haskell Cafe
| Subject: [Haskell-cafe] why do I need class context in declaring data
| constructor?
|
| I had a toy program that encodes simply typed lambda in types. It used
| to work fine with GHC prior to 7.2. But now it no longer compiles.
| Here is a minimal fragment that demonstrates this problem.
|
| {-# LANGUAGE GADTs,
| MultiParamTypeClasses,
| FlexibleInstances,
| FlexibleContexts #-}
|
| data Abs env t v where
|Abs :: g (a, env) h v - Abs env (g (a, env) h v) (a - v)
|
| class Eval g env t v where
|eval :: env - g env t v - v
|
| instance Eval g (a, env) h v =
| Eval Abs env (g (a, env) h v) (a - v) where
|eval env (Abs e) = \x - eval (x, env) e
|
| The type Abs has 3 parameters: its environment, sub term (encoded in
| types), and type. The constructor Abs has 1 parameter: its sub term.
| The code loads fine in GHC 7.0.3.
|
| Here is the error reported by GHC 7.2.2 (and later):
|
| test.lhs:14:30:
| Could not deduce (Eval g1 (a1, env) h1 v1)
| arising from a use of `eval'
| from the context (Eval g (a, env) h v)
| bound by the instance declaration at test.lhs:(12,12)-(13,49)
| or from (g (a, env) h v ~ g1 (a1, env) h1 v1,
| (a - v) ~ (a1 - v1))
| bound by a pattern with constructor
| Abs :: forall env (g :: * - * - * - *) a h v.
| g (a, env) h v - Abs env (g (a, env) h v) (a -
| v),
|in an equation for `eval'
| at test.lhs:14:15-19
| Possible fix:
| add (Eval g1 (a1, env) h1 v1) to the context of
| the data constructor `Abs'
| or the instance declaration
| or add an instance declaration for (Eval g1 (a1, env) h1 v1)
| In the expression: eval (x, env) e
| In the expression: \ x - eval (x, env) e
| In an equation for `eval':
| eval env (Abs e) = \ x - eval (x, env) e
|
| However, if I move the class context to the data constructor of
| definition, then it compiles fine in GHC 7.2.2 (and later):
|
| data Abs env t v where
|Abs :: Eval g (a, env) h v = g (a, env) h v - Abs env (g (a, env)
| h v) (a - v)
|
| But this is very troublesome because for every new class instance I want
| to make Abs of, I have to make a new class context to the data
| constructor. It totally defeats the purpose of making class instances to
| extend usage of data types.
|
| Did I missed a language extension when moving code from GHC 7.0.3 to GHC
| 7.2.2? What can I do to fix it for newer GHCs?
|
| --
| Regards,
| Paul Liu
|
| ___
| Haskell-Cafe mailing list
| Haskell-Cafe@haskell.org
| http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Rigid skolem type variable escaping scope
| This compiles just fine, as I would expect. But now let's say I want | to change it to make IntFn a newtype: | | newtype IntFn a = IntFn (a - Int) | | bar :: (forall a. (FooClass a) = IntFn a) - Bool | bar (IntFn fn) = foo fn The easiest way is to imagine transforming the function to System F. I'll ignore the (FooClass a) bit since it's irrelevant. We'd get bar = \(x :: forall a. IntFn a). ...what?... We can't do case-analysis on x; it has a for-all type, so we must instantiate it. But at what type? Let's guess some random type 'b': bar = \(x : forall a. IntFn a). case (x b) of IntFn (f :: b - Int) - foo f But now we are in trouble. 'foo' itself needs an argument of type (forall a. a-Int). So we need a big lambda bar = \(x : forall a. IntFn a). case (x b) of IntFn (f :: b - Int) - foo (/\a. f) But this is obviously wrong because 'b' escapes the /\a. I don't know if I can explain it better than that Simon | | I had expected this to compile too. But instead, I get an error like | this one (using GHC 7.4.1): | | Couldn't match type `a0' with `a' | because type variable `a' would escape its scope | This (rigid, skolem) type variable is bound by | a type expected by the context: FooClass a = a - Int | The following variables have types that mention a0 | fn :: a0 - Int (bound at the line number that implements bar) | In the first argument of `foo', namely `fn' | In the expression: foo fn | In an equation for `bar': bar (IntFn fn) = foo fn | | I don't think I am grasping why adding the layer of newtype | wrapping/unwrapping, without otherwise changing the types, introduces | this problem. Seems to me like the newtype version would also be type- | safe if GHC allowed it (am I wrong?), and I'm failing to understand why | GHC can't allow it. Is there a simple explanation, or else some | reading that someone could point me to? (-: | | Cheers, | -Matt | | | ___ | Haskell-Cafe mailing list | Haskell-Cafe@haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Noticed this change about infix decls in GHC 7.4.2
Yes, it's a bug. Happily a dup of http://hackage.haskell.org/trac/ghc/ticket/6120, which is already fixed. I'll add your program as a regression test though. Thanks for reporting Simon | -Original Message- | From: haskell-cafe-boun...@haskell.org [mailto:haskell-cafe- | boun...@haskell.org] On Behalf Of Christopher Done | Sent: 17 June 2012 19:54 | To: Haskell Cafe | Subject: [Haskell-cafe] Noticed this change about infix decls in GHC 7.4.2 | | So I have some module, in a work project that I'm portnig from GHC | 6.12.3 to GHC 7.4.2, | | module Data.Monoid.Operator where | | import Data.Monoid | | (++) :: Monoid a = a - a - a | (++) = mappend | infixr 5 ++ | | This compiles happily on GHC 6.12.3, but on 7.4.2 says: | | src/Data/Monoid/Operator.hs:9:10: | Ambiguous occurrence `++' | It could refer to either `Data.Monoid.Operator.++', | defined at src/Data/Monoid/Operator.hs:8:1 |or `Prelude.++', | imported from `Prelude' at | src/Data/Monoid/Operator.hs:3:8-27 | (and originally defined in `GHC.Base') | | It seems that it used to assign higher priority to the declared thing | in the current module over the imported one. Is this intentional? I'd | suspect not, given that if I comment the binding out: | | -- (++) :: Monoid a = a - a - a | -- (++) = mappend | | I get: | | src/Data/Monoid/Operator.hs:9:10: | The fixity signature for `++' lacks an accompanying binding |(The fixity signature must be given where `++' is declared) | | Which seems to contradict the previous error message. | | Bug? | | Ciao! | | P.S. Yes, I know I can fix this by not importing Prelude. | P.P.S Yes, I know there's a or + defined now, but I prefer (++), thanks. | | ___ | Haskell-Cafe mailing list | Haskell-Cafe@haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] converting functional dependencies to type families
Thanks. I've linked to it from http://www.haskell.org/haskellwiki/GHC/Type_families#Frequently_asked_questions | -Original Message- | From: Henning Thielemann [mailto:lemm...@henning-thielemann.de] | Sent: 10 June 2012 15:14 | To: Simon Peyton-Jones | Cc: Haskell Cafe | Subject: RE: converting functional dependencies to type families | | | On Thu, 7 Jun 2012, Simon Peyton-Jones wrote: | | Very useful! Maybe worth turning into a page on the Haskell wiki? | | I created one: | | http://www.haskell.org/haskellwiki/Functional_dependencies_vs._type_fami | lies ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHC 7.4 and TypeSynonymInstances
It's deliberate. As the user manual says (http://www.haskell.org/ghc/docs/latest/html/users_guide/flag-reference.html#id3101511), FlexibleInstances implies TypeSynonymInstances. See Trac http://hackage.haskell.org/trac/ghc/ticket/4841 I'll clarify the docs a bit. Simon | -Original Message- | From: haskell-cafe-boun...@haskell.org [mailto:haskell-cafe- | boun...@haskell.org] On Behalf Of Ivan Lazar Miljenovic | Sent: 06 June 2012 23:34 | To: Haskell Cafe | Subject: Re: [Haskell-cafe] GHC 7.4 and TypeSynonymInstances | | *Bump* | | Especially as there is now a version of the Haskell Platform based | around GHC-7.4.1, I would appreciate it if this behaviour could be | clarified. | | On 20 April 2012 15:25, Ivan Lazar Miljenovic | ivan.miljeno...@gmail.com wrote: | Has there been a change in the behaviour/requirement of | TypeSynonymInstances as of GHC-7.4.1? (Not sure if this behaviour | occurs with 7.2.1 as I don't have it installed) | | I had an instance for String for a class which ghc accepted whilst | using FlexibleInstances; however, when trying to load it in 7.0.* it | stated that TypeSynonymInstances was needed (which I forgot to add | since it didn't seem to need it). | | All I could find in the release notes was that as of 7.2.1, both | extensions were needed, not that one implied the other: | http://www.haskell.org/ghc/docs/7.4.1/html/users_guide/release-7-2-1.h | tml#id3003826 | | Is this behaviour deliberate, or a bug? | | -- | Ivan Lazar Miljenovic | ivan.miljeno...@gmail.com | http://IvanMiljenovic.wordpress.com | | | | -- | Ivan Lazar Miljenovic | ivan.miljeno...@gmail.com | http://IvanMiljenovic.wordpress.com | | ___ | Haskell-Cafe mailing list | Haskell-Cafe@haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Fundeps and overlapping instances
| My take is that we should abandon Fundeps, and concentrate on | introducing overlaps into type functions in a controlled way (what | I've called 'dis- overlapped overlaps'.) | | Abandoning fundeps would be a sad day for type-level programming. | There are many things other than overlaps that you can do with fundeps | and constraint kinds that you cannot currently do with type families, | such as: | | - Partial application or higher-order programming. | - Short-circuit evaluation, lazy evaluation or type-level case. Etienne, I think it would be a good service to make Haskell wiki page describing the difference between fundeps and type families, and in particular describing things that can be done with the former but not the latter. The standard encoding of fundeps using type families is this: With fundeps class C a b | a - b With type failies class (F a ~ b) = C a b where type F a The merit of a wiki page would be to be a single place to find the discussion, the standard encoding and examples of where the standard encoding fails. Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Typed TemplateHaskell?
Maybe take a look at http://hackage.haskell.org/trac/ghc/blog/Template%20Haskell%20Proposal | -Original Message- | From: haskell-cafe-boun...@haskell.org [mailto:haskell-cafe- | boun...@haskell.org] On Behalf Of Tillmann Rendel | Sent: 23 May 2012 18:20 | To: Haskell Café | Subject: Re: [Haskell-cafe] Typed TemplateHaskell? | | Hi Ilya, | | Ilya Portnov wrote: | As far as can I see, using features of last GHC one could write typed | TH library relatively easily, and saving backwards compatibility. | | For example, now we have Q monad and Exp type in template-haskell | package. Let's imagine some new package, say typed-template-haskell, | with new TQ monad and new polymorphic type Exp :: * - *. Using last | GHC's features, one will easily write something like expr :: Exp | String, which will mean that expr represents a string expression. | And we will need a new function, say runTQ :: TQ a - Q a (or some | more complicated type), which will turn TypedTemplateHaskell's | constructs into plain TH. | | That would be a good thing to have. But it might be quite hard to | implement. For example, I guess you might want to have functions like | this one: | |apply :: Exp (a - b) - Exp a - Exp b | | This function takes two typed expressions and produces an application. | The types ensure that the generated application will typecheck. Cool. | | But can you do the same thing for lambdas? Lambdas create functions, so | the type would be something like the following: | |lambda :: ... - Exp (a - b) | | But what would you put instead of the ...? | | I fear that overall, you would have to reimplement Haskell's type system | in Haskell's type system. Which sounds like a cool thing to do, but | maybe not so easily. | |Tillmann | | ___ | Haskell-Cafe mailing list | Haskell-Cafe@haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data Kinds and superfluous (in my opinion) constraints contexts
I'm glad you've been trying out kinds. However, I don't understand the feature
you want here.
You say:
fromIntgr :: Integer - BV (size :: D)
fromIntgr int = BV mkD int -- doesn't work, but desired.
fromIntgr :: MkD size = Integer - BV (size :: D)
fromIntgr int = BV mkD int -- does work, but is not that useful.
The implementation MUST pass a value parameter for (MkD size =) to fromIntgr.
Your point is presumably that since every inhabitant of kind D is an instance
of MkD, the (MkD size =) doesn't actually constrain the type at all. It really
works for every instantiation of 'size'.
So maybe your feature is
Please omit class constraints where I can see that
every suitably-kinded argument is an instance of the
class.
I suppose that might be conceivable, but it'd make the language more
complicated, and the implementation, and I don't see why the second version is
not that useful.
Start a feature-request ticket if you like, though.
Simon
| -Original Message-
| From: haskell-cafe-boun...@haskell.org [mailto:haskell-cafe-
| boun...@haskell.org] On Behalf Of Serguey Zefirov
| Sent: 06 May 2012 17:49
| To: haskell
| Subject: [Haskell-cafe] Data Kinds and superfluous (in my opinion)
| constraints contexts
|
| I decided to take a look at DataKinds extension, which became available
| in GHC 7.4.
|
| My main concerns is that I cannot close type classes for promoted data
| types. Even if I fix type class argument to a promoted type, the use of
| encoding function still requires specification of context. I consider
| this an omission of potentially very useful feature.
|
| Example is below.
|
| -
| {-# LANGUAGE TypeOperators, DataKinds, TemplateHaskell, TypeFamilies,
| UndecidableInstances #-} {-# LANGUAGE GADTs #-}
|
| -- a binary numbers.
| infixl 5 :*
| data D =
| D0
| | D1
| | D :* D
| deriving Show
|
| -- encoding for them.
| data EncD :: D - * where
| EncD0 :: EncD D0
| EncD1 :: EncD D1
| EncDStar :: EncD (a :: D) - EncD (b :: D) - EncD (a :* b)
|
| -- decode of values.
| fromD :: D - Int
| fromD D0 = 0
| fromD D1 = 1
| fromD (d :* d0) = fromD d * 2 + fromD d0
|
| -- decode of encoded values.
| fromEncD :: EncD d - Int
| fromEncD EncD0 = 0
| fromEncD EncD1 = 1
| fromEncD (EncDStar a b) = fromEncD a * 2 + fromEncD b
|
| -- constructing encoded values from type.
| -- I've closed possible kinds for class parameter (and GHC successfully
| compiles it).
| -- I fully expect an error if I will try to apply mkD to some type that
| is not D.
| -- (and, actually, GHC goes great lengths to prevent me from doing that)
| -- By extension of argument I expect GHC to stop requiring context with
| MkD a where
| -- I use mkD constant function and it is proven that a :: D.
| class MkD (a :: D) where
| mkD :: EncD a
| instance MkD D0 where
| mkD = EncD0
| instance MkD D1 where
| mkD = EncD1
| -- But I cannot omit context here...
| instance (MkD a, MkD b) = MkD (a :* b) where
| mkD = EncDStar mkD mkD
|
| data BV (size :: D) where
| BV :: EncD size - Integer - BV size
|
| bvSize :: BV (size :: D) - Int
| bvSize (BV size _) = fromEncD size
|
| -- ...and here.
| -- This is bad, because this context will arise in other places, some of
| which
| -- are autogenerated and context for them is incomprehensible to human
| -- reader.
| -- (they are autogenerated precisely because of that - it is tedious and
| error prone
| -- to satisfy type checker.)
| fromIntgr :: Integer - BV (size :: D) -- doesn't work, but desired.
| -- fromIntgr :: MkD size = Integer - BV (size :: D) -- does work, but
| is not that useful.
| fromIntgr int = BV mkD int
|
| -
|
| ___
| Haskell-Cafe mailing list
| Haskell-Cafe@haskell.org
| http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Printing call site for partial functions
Tristan Allwood got quite a long way with this a couple of years ago.
http://research.microsoft.com/en-us/um/people/simonpj/papers/stack-trace/DebugTraces.pdf
But not enough to finish it off! The paper describes the tricky points... Simon
M is more of an expert than I.
Moreover the work Simon has done on improving profiling is relevant too.
Simon
| -Original Message-
| From: haskell-cafe-boun...@haskell.org [mailto:haskell-cafe-
| boun...@haskell.org] On Behalf Of Evan Laforge
| Sent: 25 April 2012 17:08
| To: Michael Snoyman
| Cc: Haskell Cafe
| Subject: Re: [Haskell-cafe] Printing call site for partial functions
|
| And then have the compiler automatically include (optional) package
| name, module name, and line number where `headContext` was called. How
| about we borrow a bit from rewrite rules, and have a pragma such as:
|
| {-# WITH_CONTEXT head headContext #-}
|
| This seems similar to the SRCLOC_ANNOTATE pragma supported by jhc.
|
| I'd love to have this feature. I'd just like to point out it's not just
| useful for partial functions like 'head', but also for logging and expected
| exceptions like Left. It's also extremely useful for tests, when I get
| check failed: 3 /= 4 it's really important to see filename and line number.
|
| There are various hacks out there to get this, but they all involve
| annotating the call sites with some magic, either an 'assert' (and then
| runtime overhead on every function that uses it) or a TH splice (and then you
| have to turn TH on in every module). I have literally thousands of lines of
| tests that would all need an extra boilerplate argument.
|
| I implemented a preprocessor that is effectively like SRCLOC_ANNOTATE and it
| works ok for me, but it's not a good general solution because it's hardcoded
| to certain symbols and slows down compilation too much.
| And being specific to my app of course it wouldn't help in your case
| :)
|
| But it won't happen unless one of us few people who care about it just goes
| and implements it. I don't think it's much of a priority with others.
|
| ___
| Haskell-Cafe mailing list
| Haskell-Cafe@haskell.org
| http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Some thoughts on Type-Directed Name
| What would really, really help me is for someone to have a look at the 'solution' I | posted to the difficulties SPJ saw with the SORF approach. (I ref'd it in my reply to In response to your plea, I took a look at your post http://www.haskell.org/pipermail/glasgow-haskell-users/2011-December/021298.html Some thoughts * I don't think you need GetTy at all. The attached version of your code gets rid of it. * Your trick with SetrTy does, I think, support type-changing update. Good. (Whether type-changing update is itself a valuable enough feature to be worth the extra complexity, I'm not certain, but perhaps that's a separate matter.) * Your trick with SetTy to support update of polymorphic fields is, I belive, an (ingenious) hack that does not scale. I think it works only for fields that are quantified over one type variable with no constraints. So, I think that update of polymorphic fields remains problematic. Simon | -Original Message- | From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell-users- | boun...@haskell.org] On Behalf Of Anthony Clayden | Sent: 28 January 2012 09:25 | To: Greg Weber; Steve Horne; Haskell Cafe | Cc: glasgow-haskell-us...@haskell.org | Subject: Re: [Haskell-cafe] Some thoughts on Type-Directed Name | | There is an effort underway to make Haskell's Records better. The | discussion is ongoing on the ghc-users mail list, ... | in the direction of making the most minimal changes possible to | achieve some simple record name-spacing. | | Thanks, | Greg Weber | | Thank you Greg, | | Yes I know, and I have been trying to follow along (intermittently). Thank you for | your attempts to marshall the discussion. | | What would really, really help me is for someone to have a look at the 'solution' I | posted to the difficulties SPJ saw with the SORF approach. (I ref'd it in my reply to | Steve.) | http://www.haskell.org/pipermail/glasgow-haskell-users/2011- | December/021298.html | | It seemed from my testing to address the needs. Since I got it working in GHC | 7.2.1, there's a good chance it will need only minimal changes to implement | (I'm thinking mostly syntactic sugar) -- providing of course that it is workable and | generalisable enough. | | It could possibly benefit from some of the new Kind-level stuff in 7.4.1 (that SPJ | used, but wasn't available to me at the time). | | I keep trying to make the time to write up the full proposal on the Wiki. I see it as | a 'tweak' to SORF. Given that I'm supposed to have a day job, I'm reluctant to | make time until/unless someone else double-checks whether I'm barking up the | wrong tree. | | Anthony | | | | | ___ | Glasgow-haskell-users mailing list | glasgow-haskell-us...@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] FW: [Haskell] Job Opportunity at Parallel Scientific
I'm taking the liberty of forwarding this super-relevant advert to Haskell Cafe in case any readers read the Cafe but not the main Haskell mailing list. Simon From: haskell-boun...@haskell.org [mailto:haskell-boun...@haskell.org] On Behalf Of Peter Braam Sent: 21 November 2011 22:23 To: haskell Subject: [Haskell] Job Opportunity at Parallel Scientific Parallel Haskell Programmers Parallel Scientific, LLC is a Boulder, CO based early stage, but funded startup company working in the area of scalable parallelization for scientific and large data computing. We are implementing radically new software tools for the creation and optimization of parallel programs benefiting applications and leveraging modern systems architecture. We build on our mathematical knowledge, cutting edge programming languages and our understanding of systems software and hardware. We are currently working with the Haskell development team and major HPC laboratories world wide on libraries and compiler extensions for parallel programming. Parallel Scientific was founded by Dr Peter Braam in 2010. Peter formerly taught mathematics and computer science at Oxford and Carnegie Mellon. Then he contributed file systems to Linux and invented Lustre (which provides storage to 9 of the top 10 systems in the world). He ran several successful startups, and Parallel Scientific is run by an very experienced management team and board. Successful candidates can in some cases work remotely and will work in a modern virtual environment. We provide training in advanced processes for software design and implementation and domain specific knowledge. Required skills: * Very strong background in computer science or mathematics * Experience with Haskell * Knowledge of systems programming and operating systems functionality * Knowledge of system architectures, such as high performance networking, memory architectures, multi and manycore CPUs and GPGPUs * Experience with performance tuning of parallel or concurrent algorithms * Experience designing and implementing concurrent or parallel programs Experience in one or more of the following areas is desirable: * Experience with Haskell compiler technology * In depth knowledge of core Haskell libraries for parallel programming (NDP, REPA etc) * Experience in the area of middleware algorithms for data flow programming, graphs, cloud based data analytics, or sparse matrices * Domain specific knowledge in scientific programming areas related to irregular and sparse problems, e.g. data analytics using graph analysis, genomics, tightly connected numerical analysis * Experience with performance tuning for parallel applications on multi core systems (e.g. with the Intel toolkit), for GPGPU's using Cuda/OpenCL or with MPI/OpenMP on clusters of SMPs To apply, please send a resume to j...@parsci.commailto:j...@parsci.com. ___ Haskell mailing list hask...@haskell.org http://www.haskell.org/mailman/listinfo/haskell ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] When does the UNPACK pragma work?
newtypes always turn into no code. The UNPACK is therefore asking to unpack
the Integer inside a Day, and that we can't do because Integer has more than
one data constructor. Ditto Pico. So just drop the UNPACKS. Keep the !
though, to keep it strict
S
From: haskell-cafe-boun...@haskell.org
[mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Eugene Kirpichov
Sent: 28 October 2011 10:41
To: Haskell Cafe
Subject: [Haskell-cafe] When does the UNPACK pragma work?
Hi,
I'm trying to speed up Data.Time (the time package) 'cause my program is
spending a very substantial fraction of time manipulating dates.
I decided to start with strictifying and unpacking the date/time types, as
there's no point in having them be lazy and I indeed had a lot of allocation in
date/time arithmetic in my performance profile.
data UTCTime = UTCTime {
utctDay :: {-# UNPACK #-} !Day,
utctDayTime :: {-# UNPACK #-} !DiffTime
}
(unpacks and strictness mine)
newtype Day = ModifiedJulianDay {toModifiedJulianDay :: Integer}
newtype DiffTime = MkDiffTime Pico
And Pico is also essentially a newtype for Integer.
So, I'm getting warnings on this definition of UTCTime.
QUESTION: Is it the case that I can only UNPACK primitive fields, and not even
their newtypes?
Data\Time\Clock\UTC.hs:30:16:
Warning: Ignoring unusable UNPACK pragma on the
first argument of `UTCTime'
In the definition of data constructor `UTCTime'
In the data type declaration for `UTCTime'
Data\Time\Clock\UTC.hs:30:16:
Warning: Ignoring unusable UNPACK pragma on the
second argument of `UTCTime'
In the definition of data constructor `UTCTime'
In the data type declaration for `UTCTime'
--
Eugene Kirpichov
Principal Engineer, Mirantis Inc. http://www.mirantis.com/
Editor, http://fprog.ru/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Simon PJ in Australia
This is a message for Australian FPers -- sorry to spam the rest of you. I'm crossing the planet to Australia for YOW (Melbourne Dec 1-2, Brisbane Dec 5-6). http://www.yowconference.com.au/YOW2011/ I'm committed for the conference dates of course, but I could spend a few days before or afterwards, hanging out with some of you guys. Hack on GHC, give a talk, eat pizza, university departments, Haskell users groups, surfing (on water, that is) Do drop me (not the list) a line if any of that sounds fun. Simon PS: John Hughes is coming to Yow too, so you could try luring him into your lair too. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] FFI for a beginner
FIXED IT!!! The problem with charm.hs and its FFI dependency charm.c is that
both want to produce an intermediary charm.o file. Solution: rename charm.hs to
hscharm.hs.
Would you (or anyone else) care to update the tutorials on the Haskell Wiki?
As someone wrote below:
While the tutorials at
HaskellWikihttp://www.haskell.org/haskellwiki/FFI_complete_examples are
helpful, they're outdated. Argh!
It would be great if someone was public-spirited enough to fix this. The root
page is here
http://haskell.org/haskellwiki/GHC/Using_the_FFI
which in turn links to the complete examples page mentioned above.
The
docshttp://www.haskell.org/ghc/docs/latest/html/users_guide/ffi-ghc.html#glasgow-foreign-headers
say that -#include pragmas no longer work, but fail to explain how to load
code without them. Suffice to say I have no recourse but trial and error.
Ah, now that is a GHC documentation question. Can you tell us what should the
docs should say instead? Then we can fix the docs.
Simon
From: haskell-cafe-boun...@haskell.org
[mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Andrew Pennebaker
Sent: 14 July 2011 07:57
To: Jason Dagit
Cc: Haskell Cafe
Subject: Re: [Haskell-cafe] FFI for a beginner
FIXED IT!!!
The problem with charm.hs and its FFI dependency charm.c is that both want to
produce an intermediary charm.o file.
Solution: rename charm.hs to hscharm.hs.
Cheers,
Andrew Pennebaker
www.yellosoft.ushttp://www.yellosoft.us
On Tue, Apr 12, 2011 at 5:55 PM, Andrew Pennebaker
andrew.penneba...@gmail.commailto:andrew.penneba...@gmail.com wrote:
hsc2hs and c2hs are good suggestions, and some of the tutorials I'm following
use them.
But 1) Many Haskell FFI tutorials don't require them, so they only seem to
help, or only help in older versions of GHC.
And 2) When I did compile using c2hs, it just produced the same file, but with
filler comments like {#- LINE 13 #-}. And they still refused to compile for the
same reason:
ld: duplicate symbol _Charm_getWidth_info in charm.o and charm.o
Cheers,
Andrew Pennebaker
www.yellosoft.ushttp://www.yellosoft.us
On Sat, Apr 9, 2011 at 9:50 PM, Jason Dagit
dag...@gmail.commailto:dag...@gmail.com wrote:
I don't know how to make ghc load them without using either hsc2hs or c2hs.
I've had better experiences with hsc, but your mileage may vary.
On Apr 8, 2011 3:34 AM, Andrew Pennebaker
andrew.penneba...@gmail.commailto:andrew.penneba...@gmail.com wrote:
ncurses is proving too difficult to setup, so I'm working on a new library
called charm. The C code works by itself, but I can't compile a Haskell wrapper
for it. While the tutorials at
HaskellWikihttp://www.haskell.org/haskellwiki/FFI_complete_examples are
helpful, they're outdated. Argh! The
docshttp://www.haskell.org/ghc/docs/latest/html/users_guide/ffi-ghc.html#glasgow-foreign-headers
say that -#include pragmas no longer work, but fail to explain how to load
code without them. Suffice to say I have no recourse but trial and error.
GitHub: charmhttps://github.com/mcandre/charm and
hscharmhttps://github.com/mcandre/hscharm
$ make
cp /usr/include/charm.c .
ghc --make -fforce-recomp -o hellocharm hellocharm.hs charm.hs charm.c
-I/usr/include -dylib-install-name /usr/lib/libcharm.dynlib
[1 of 2] Compiling Charm( charm.hs, charm.o )
[2 of 2] Compiling Main ( hellocharm.hs, hellocharm.o )
Linking hellocharm ...
ld: duplicate symbol _Charm_getWidth_info in charm.o and charm.o
collect2: ld returned 1 exit status
make: *** [hellocharm] Error 1
Cheers,
Andrew Pennebaker
www.yellosoft.ushttp://www.yellosoft.us
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.orgmailto:Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Proposal to incorporate Haskell.org
Dear haskell.org committee Great stuff. Thanks for getting this together. Things I wondered about are: - who will run the haskell.org entity? - how are they chosen? do they have fixed terms? - how are they accountable to the Haskell Community (eg an a brief annual report would be good; since money is involved, accounts perhaps) None of these look like being problems to me, but I think we should have a page that sets out these matters -- a kind of constitution for haskell.org, if you like -- as part of the process. Simon | -Original Message- | From: libraries-boun...@haskell.org [mailto:libraries-boun...@haskell.org] On Behalf | Of Don Stewart | Sent: 10 May 2011 23:45 | To: hask...@haskell.org; Haskell Libraries; GHC Users Mailing List; haskell-cafe; | commit...@haskell.org | Subject: Proposal to incorporate Haskell.org | | Hello everyone. | | The haskell.org committee[1], in the interest of the long-term stability | of the open source Haskell community infrastructure, has decided to | incorporate haskell.org as a legal entity. This email outlines our | recommendation, and seeks input from the community on this decision. | | The committee's proposal is that haskell.org incorporate as an entity | under the Software Freedom Conservancy umbrella organization (the same group | that Darcs joined recently): | | http://sfconservancy.org/ | | If we proceed with this move, haskell.org will be a legal entity, and | registered as a non-profit, allowing us to more directly accept | (US tax-deductible) donations, and to invest in assets that benefit the | Haskell open source community. | | We welcome your feedback on the proposal attached below. | | -- Don Stewart (on behalf of the Haskell.org committee) | | | | | | = A proposal for the incorporation of Haskell.org = | | In recent years, haskell.org has started to receive assets, e.g. money from | Google Summer Of Code, donations for Hackathons, and a Sparc machine for use in | GHC development. We have also started spending this money: in particular, on | hosting haskell.org itself. There is also interest in running fundraising | drives for specific things such as Hackathon sponsorship and hosting fees. | | However, haskell.org doesn't currently exist as a legal entity, meaning that | these assets have had to be held on our behalf by other entities, such as | Galois and various universities. This leads to tricky situations, with no-one | being sure who should decide how the haskell.org assets can be used. | | To solve these problems, we propose that haskell.org applies to become a member | project of the Software Freedom Conservancy (SFC) | http://conservancy.softwarefreedom.org/. The SFC is a non-profit organization | that provides free financial and administrative services to open source | projects. Additionally, it has 501(c)(3) status, meaning donations from the US | are tax-deductible. The SFC would hold haskell.org's money and other assets, | and would be able to accept donations on behalf of haskell.org. | | The haskell.org committee, as described here [2], will make decisions on | spending assets and other decisions related to governing the non-profit. | | | Before proceeding, we are inviting input from the community in the form | of specific objections or queries regarding the plan. | | We've tried to answer some of the most likely questions: | | Q: Does this mean that my Haskell project must now be covered by a | copyleft licence such as GPL? | A: No, but Haskell projects using haskell.org resource should use an | Open Source licence | http://www.opensource.org/licenses/alphabetical. | | Q: Will it still be possible to use community.h.o to host | non-open-source material, such as academic papers? | A: An overall minority of such content, as is the current situation, is | not a problem. | | Q: Will it still be possible to have job ads on the haskell.org mailing | lists and website? | A: Yes. | | Q: Will this affect our ability to host the Haskell Symposium | http://www.haskell.org/haskell-symposium/ and Industrial Haskell | Grouphttp://industry.haskell.org/ webpages within haskell.org? | A: No. | | Q: What will be the relationship between haskell.org and other | organizations such as the Haskell Symposium and Industrial Haskell | Group? | A: Those organisations will continue to exist as separate entities. | | Q: If an umbrella non-profit organisation The Haskell Foundation was | created, would haskell.org be able to join it? | A: Yes. It's likely that in such a scenario, the Haskell Foundation | would become the owner of the haskell.org domain name, with the cost | divided between the members. The entity that is part of the SFC would | be renamed community.haskell.org in order to avoid confusion. | | [1]:
Re: [Haskell-cafe] Template Haskell reified type.
Can you give a concrete example? There is code in GHC that is supposed to produce TupleT and ListT! Simon | -Original Message- | From: haskell-cafe-boun...@haskell.org [mailto:haskell-cafe-boun...@haskell.org] On | Behalf Of Serguey Zefirov | Sent: 09 May 2011 14:43 | To: haskell | Subject: [Haskell-cafe] Template Haskell reified type. | | Language.Haskell.TH.Type contains, among others, two constructors: | TupleT Int and ListT. | | I can safely construct types using them, but reification returns ConT | GHC.Tuple.(,) and ConT GHC.Types.[] respectively. | | This is not fair asymmetry, I think. | | Also, it took purity from one of my functions while I debugged that | problem. I had to make it into Q monad. ;) | | ___ | Haskell-Cafe mailing list | Haskell-Cafe@haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] mtlx has a nice design but is slow
GHC's goal is to be good enough at inlining and optimisation that you shouldn't take a performance hit for adding layers of abstraction. Sometimes it needs help (eg inlining pragmas). So as Don implies, it might be worth digging a bit to see where the performance hit comes from. Simon | -Original Message- | From: haskell-cafe-boun...@haskell.org [mailto:haskell-cafe- | boun...@haskell.org] On Behalf Of Don Stewart | Sent: 06 April 2011 18:19 | To: Sean Leather | Cc: Haskell Café List | Subject: Re: [Haskell-cafe] mtlx has a nice design but is slow | | Is the package missing some obvious inlining in the instances? | | On Wed, Apr 6, 2011 at 10:13 AM, Sean Leather leat...@cs.uu.nl wrote: | I just refactored my type and transform system prototype (introduced in [1] | but changed since then) from using mtlx [2] (type-indexed monad | transformers | described in [3]) to mtl using RWST. mtlx allowed me to cleanly separate | the | various monadic components in a convenient way. Unfortunately, I found it | to | be too slow. The refactoring was an experiment to see how slow. I was | rather | surprised: | | Running time of a compiled main with a list of tests: | mtlx (7 transformers): 2 min 52 sec | mtl (RWST): 0 min 13 sec | | It's frustrating to see such a huge performance gap for a better design. | | Regards, | Sean | | [1] | http://splonderzoek.blogspot.com/2011/03/draft-type-changing-program- | improvement.html | [2] http://hackage.haskell.org/package/mtlx | [3] http://www.ittc.ku.edu/~marks/cgi-bin/pubs/monadfactory.pdf | | | ___ | Haskell-Cafe mailing list | Haskell-Cafe@haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe | | | | ___ | Haskell-Cafe mailing list | Haskell-Cafe@haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Class constraints for associated type synonyms
| class Monoid (GeneratorOf a) = Generable a where | type GeneratorOf a :: * - * | construct :: GeneratorOf a - a | | Now, it seems I need FlexibleInstances to do this when I'm using an | associated type synonym, but I don't need the flexibility when using a | multiparameter type class. Suppose you have these wierd instances: type instance GeneratorOf (Tree a) = Tree (Tree a) instance Generable a = Monoid (Tree a) instance Generable (Tree a) Now, in the last of these we need to cough up an instance of Generable (Tree a)'s superclasses. Ah, that's Monoid (GeneratorOf (Tree a)) Ah, that's Monoid (Tree (Tree a)) We have an instance of Monoid, but it needs, well Generable (Tree a), which is where we started. If I'd nested things a bit more deeply you can see I'd get into an infinite regress. So you have to take responsibility that instance solving will terminate, hence FlexibleInstances. As you say, the same thing can happen with fundeps. The fact that the thing is allowed is probably a bug in the Fundep stuff. Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Parallel Haskell stories
Friends I'm giving a talk at a developer conference in London on Friday 18th, about parallel programming in Haskell. http://skillsmatter.com/event/scala/functionalpx-2011/ad-1382 I know that some of you have been using Haskell for parallel or concurrent programming quite a bit, so this email is just to ask could you contribute a little vignette or story about using Haskell in a *parallel/concurrent* application that I could use to illustrate my talk? I can rant all I like about the glories of Haskell, but I'm a biased witness. It's much more convincing if I can illustrate with true tales from the trenches. I'm interested in both parallelism and concurrency, so for example the success of Warp in using Concurrent Haskell is in scope. I can't say a lot about any one example, obviously, but what would be great would be - an idea of how Haskell helped (esp if you have a head to head comparison) - code snippets that illustrate how lovely it all is - brief performance indicators *Insight* is the key word. I don't just want to say Company X used Haskell to do Y because that doesn't convey any re-usable insights or ideas. What is the essence? I'll start writing in earnest on Monday 14th; the talk is on Friday. I have plenty to say already, so treat this as an opportunity not an obligation. But still, examples would be good! Do let me know if you have one. Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] rewrite rules to specialize function according to type class?
What happens is this. From the (Foo Bool) instance GHC generates
dFooBool :: Foo Bool
dFooBool = DFoo fooBool barBool foo_barBool
barBool :: Bool - Bool
barBool = not
Now when GHC sees
bar dFooBool
it rewrites it to
barBool
Moreover there is currently no way to say don't do that rewrite until phase
1. It's an always-on rewrite. For all other rewrite rules you can control
which phase(s) the rule is active in.
What you want in this case is to avoid doing the bar/dFooBool rewrite until the
foo/bar rule has had a chance to fire.
There's no fundamental difficulty with doing this, except a syntactic one:
since the rule is implicit, how can we control it's phase? You could imagine
saying
class Foo a where
bar :: a - a
{-# NOINLINE [1] bar #-}
but currently any pragmas in a class decl are treated as attaching to the
*default method*, not to the method selector:
class Foo a where
bar :: a - a
bar x = x
{-# NOINLINE [1] bar #-}
So we need another notation for the latter.
As a workaround, you can say
class Foo a where
_bar :: a - a
_foo :: a - a
{-# NOINLINE [1] foo #-}
foo = _foo
{- NOINLINE [1] bar #-}
bar = _bar
Given the workaround, and the syntactic question, I wonder whether the feature
is worth the cost.
Simon
| -Original Message-
| From: haskell-cafe-boun...@haskell.org [mailto:haskell-cafe-
| boun...@haskell.org] On Behalf Of Max Bolingbroke
| Sent: 15 February 2011 09:08
| To: Gábor Lehel
| Cc: Haskell Cafe
| Subject: Re: [Haskell-cafe] rewrite rules to specialize function according to
| type class?
|
| 2011/2/15 Gábor Lehel illiss...@gmail.com:
| This is a semi-related question I've been meaning to ask at some
| point: I suppose this also means it's not possible to write a class,
| write some rules for the class, and then have the rules be applied to
| every instance? (I.e. you'd have to write them separately for each?)
|
| This does work, because it doesn't require the simplifier to lookup up
| class instances. However, it's a bit fragile. Here is an example:
|
|
| class Foo a where
| foo :: a - a
| bar :: a - a
| foo_bar :: a - a
|
| {-# RULES foo/bar forall x. foo (bar x) = foo_bar x #-}
|
|
| instance Foo Bool where
| foo = not
| bar = not
| foo_bar = not
|
| instance Foo Int where
| foo = (+1)
| bar x = x - 1
| foo_bar = (+2)
|
|
| {-# NOINLINE foo_barish #-}
| foo_barish :: Foo a = a - a
| foo_barish x = foo (bar x)
|
|
| main = do
| print $ foo (bar False) -- False if rule not applied, True
| otherwise
| print $ foo (bar (2 :: Int)) -- 2 if rule not applied, 4, otherwise
| print $ foo_barish False -- False if rule not applied, True
| otherwise
| print $ foo_barish (2 :: Int) -- 2 if rule not applied, 4, otherwise
|
|
| With GHC 7, the RULE successfully rewrites the foo.bar composition
| within foo_barish to use foo_bar. However, it fails to rewrite the two
| foo.bar compositions inlined directly in main. Thus the output is:
|
|
| False
| 2
| True
| 4
|
|
| The reason it cannot rewrite the calls in main is (I think) because
| the foo/bar class selectors are inlined before the rule matcher gets
| to spot them. By using NOINLINE on foo_barish, and ensuring that
| foo_barish is overloaded, we prevent the simplifier from doing this
| inlining and hence allow the rule to fire.
|
| What is more interesting is that I can't get the foo (bar x) rule to
| fire on the occurrences within main even if I add NOINLINE pragmas to
| the foo/bar names in both the class and instance declarations.
| Personally I would expect writing NOINLINE on the class declaration
| would prevent the class selector being inlined, allowing the rule to
| fire, but that is not happening for some reason.
|
| Perhaps this is worth a bug report on the GHC trac? It would at least
| give it a chance of being fixed.
|
| Max
|
| ___
| Haskell-Cafe mailing list
| Haskell-Cafe@haskell.org
| http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] The F# Team are Hiring
Dear Haskell'ers The F# team in Seattle/Redmond have an opening for a Senior Program Managerhttps://careers.microsoft.com/JobDetails.aspx?ss=pg=0so=rw=1jid=33994jlang=EN. A demonstrated love for applied Haskell/OCaml/F# programming would be highly regarded background experience :) We also have positions open for software development engineers specializing in compilers and tools (see https://careers.microsoft.com/JobDetails.aspx?ss=pg=0so=rw=3jid=34078jlang=EN) Kind regards best wishes, Don Syme The F# Team are Hiring!!! * Do you have a love for modern, industry-leading programming technologies? * Can you help us take the F# language to the next level? * Do you have the vision to combine functional programming with technologies for data, cloud, web, finance and technical computing? * Do you have a passion for delivering great visual tools and a simple, clear end-to-end experience for F# programmers? * And do you want to work on a talented agile team that releases compiler sources on codeplex.com and has originated major innovations for C# and Visual Basic? If so, we have a great opportunity for you! The Visual Studio Pro team is looking for an experienced Program Manager to drive the F# area. Partnering with your engineering team in Redmond and Microsoft Research in Cambridge, you will define the F# developer experience for Visual Studio and out of band releases such as the F# PowerPack. As a strong customer advocate, you will drive changes into the F# language, libraries and tools. You will develop and update community programs that drive increased awareness and adoption of F#. Being responsible for delivering integrated solutions, you have experience in building strong cross-group partnerships, ensuring alignment of schedules and business goals, and the natural skill of getting things done. Specific responsibilities include: * Travelling to major conferences, user group meetings, and enterprises to get people excited about solving problems using F# * Defining the strategy for marketing F# to the developer community * Owning our content strategy and community engagement programs * Driving multiple concurrent projects for the F# team including Visual Studio and out of band releases * Working closely with groups within Microsoft such as Technical Computing, .NET Framework, SQL and Azure to deliver great experiences for F# developers * Contributing to the design of all aspects of F# from language libraries to the tools that integrate with Visual Studio Basic Qualifications: * 3-5 years experience in Program Management or related experience, including a proven track record of delivering on challenging projects * A BS or equivalent degree in Computer Science, Electrical Engineering, or a related field. * Passionate for language and user experience design * Knowledge of Visual Studio, .NET functional programming languages, and the ability to dig deep into technical challenges * Strong sense of teamwork, personal integrity, responsibility and accountability * Excellent verbal and written communication skills * Strong customer advocate, self-starter and problem solver * Strong knowledge of F# or language design on managed platforms is preferred If you'd would like more details, please either contact me (ds...@microsoft.commailto:ds...@microsoft.com), or Sean Laberee (sea...@microsoft.commailto:sea...@microsoft.com) directly. To apply immediately, please fill in the online formshttps://careers.microsoft.com/JobDetails.aspx?ss=pg=0so=rw=1jid=33994jlang=EN and drop us a note that you're applying. https://careers.microsoft.com/JobDetails.aspx?ss=pg=0so=rw=1jid=33994jlang=EN don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Missing Functor instances in GHC 7?
| Interestingly, if I import only Control.Applicative from within GHCi, it | does not find the instances defined in Control.Monad.Instances although | this module is imported in Control.Applicative. On the other hand, if I | write a file containing the line 'import Control.Applicative' and load | this file in GHCi then the instances from Control.Monad.Instances are | visible. | | Apparently, importing a module in GHCi differs from importing it in a | Haskell file and loading this into GHCi. I don't believe that should happen, depending on exactly what you mean by importing a module in GHCi. If there's a consensus that the behaviour is wrong, or at least unexpected, would you like to make a reproducible test case and file a ticket? Thanks! Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] GHC 7.0.1 developer challenges
| The irony of this situation is deep. CPSA is a program that analyzes | cryptographic protocols in an effort to expose security flaws. To | ensure that the program does not crash a user's machine, I have to use | a linker option that may expose the user to some security problems. Do you have an alternative to suggest? After all, the previous situation wasn't good either. Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Impredicative Types
Yes, impredicative types are still in, but in a simpler form than before, along the lines of QML http://research.microsoft.com/en-us/um/people/crusso/qml/ I have been too busy with getting the new type checker working to describe or document it. Notably, I have not yet added syntax for QML's rigid type annotations, which leads to a loss of expressive power. too much to do! Bottom line: if you are interested in impredicative polymorphism, let me know. A good way to do so would be to register your interest on http://hackage.haskell.org/trac/ghc/ticket/4295 Just add your email address to the cc list, *and* write a comment giving an example of how you are using impredicative poly, and pointing to any further info. That'll help motivate me to do the remaining work! Thanks Simon | -Original Message- | From: haskell-cafe-boun...@haskell.org [mailto:haskell-cafe-boun...@haskell.org] | On Behalf Of Gregory Crosswhite | Sent: 19 November 2010 19:23 | To: Haskell Cafe | Subject: [Haskell-cafe] Impredicative Types | | Hey everyone! I haven't had a chance to try out GHC 7 myself, but I saw | in the documentation that Impredicative Types are still supported. Is | this true? I thought that they were on their way out because they | overcomplicated type checking; has this plan been changed? | | Cheers, | Greg | ___ | Haskell-Cafe mailing list | Haskell-Cafe@haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Impredicative Types
read the QML paper! that's the trick. simpler, but with a heavier annotation burden than the more sophisticated approaches | -Original Message- | From: Gregory Crosswhite [mailto:gcr...@phys.washington.edu] | Sent: 19 November 2010 19:59 | To: Simon Peyton-Jones | Cc: Haskell Cafe; glasgow-haskell-us...@haskell.org | Subject: Re: [Haskell-cafe] Impredicative Types | | Awesome, thank you. :-) One more question out of pure curiosity, if | you have the time: What is allowing you to keep them in? I thought | that the problem was that they made a mess that touched every party of | the type checker rather than being centralized in one place. Was there | a trick you discovered that now allows you to support them without | creating such a mess? | | Cheers, | Greg | | On 11/19/10 11:45 AM, Simon Peyton-Jones wrote: | Yes, impredicative types are still in, but in a simpler form than before, along the | lines of QML | http://research.microsoft.com/en-us/um/people/crusso/qml/ | | I have been too busy with getting the new type checker working to describe or | document it. Notably, I have not yet added syntax for QML's rigid type annotations, | which leads to a loss of expressive power. | | too much to do! | | Bottom line: if you are interested in impredicative polymorphism, let me know. A | good way to do so would be to register your interest on | http://hackage.haskell.org/trac/ghc/ticket/4295 | Just add your email address to the cc list, *and* write a comment giving an example | of how you are using impredicative poly, and pointing to any further info. That'll help | motivate me to do the remaining work! | | Thanks | | Simon | | | -Original Message- | | From: haskell-cafe-boun...@haskell.org [mailto:haskell-cafe- | boun...@haskell.org] | | On Behalf Of Gregory Crosswhite | | Sent: 19 November 2010 19:23 | | To: Haskell Cafe | | Subject: [Haskell-cafe] Impredicative Types | | | | Hey everyone! I haven't had a chance to try out GHC 7 myself, but I saw | | in the documentation that Impredicative Types are still supported. Is | | this true? I thought that they were on their way out because they | | overcomplicated type checking; has this plan been changed? | | | | Cheers, | | Greg | | ___ | | Haskell-Cafe mailing list | | Haskell-Cafe@haskell.org | | http://www.haskell.org/mailman/listinfo/haskell-cafe | | ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Curious data family bug
Hmm. It works with HEAD (and hence I believe with the 7.0.1 RC2). It looks
similar to http://hackage.haskell.org/trac/ghc/ticket/4174, which is fixed.
Anyway I've added it as a regression test, so it should never go wrong again.
Thanks for mentioning it.
Simon
| -Original Message-
| From: haskell-cafe-boun...@haskell.org
[mailto:haskell-cafe-boun...@haskell.org] On
| Behalf Of Michael Snoyman
| Sent: 14 November 2010 19:16
| To: Haskell Cafe
| Subject: [Haskell-cafe] Curious data family bug
|
| Hey all,
|
| While trying to get a commit pushed for Yesod[1], Alexander Dunlap
| pointed out one of his programs didn't work with the new code. After
| some investigation, I was able to reproduce the bug with the following
| code snippet:
|
| {-# LANGUAGE TypeFamilies #-}
| data family Foo a
| data Bar = Bar
| data instance Foo Bar
| = Bar1 | Bar2 | Bar3 | Bar4 | Bar5 | Bar6 | Bar7 | Bar8 | Bar9
| deriving Eq
|
| This produces:
|
| Couldn't match expected type `Main.R:FooBar'
|against inferred type `Foo Bar'
| NB: `Foo' is a type function
| In the first argument of `Main.$con2tag_R:FooBar', namely `a'
| In the expression: (Main.$con2tag_R:FooBar a)
| In the expression:
| case (Main.$con2tag_R:FooBar a) of {
| a#
| - case (Main.$con2tag_R:FooBar b) of {
| b# - (a# GHC.Prim.==# b#) } }
|
| The especially strange thing about this bug is that it only occurs
| when there are more than 8 constructors; if I remove Bar9, everything
| seems to work. Does anyone have experience with this occuring?
|
| Michael
|
| [1] http://docs.yesodweb.com/blog/please-break-yesod/
| ___
| Haskell-Cafe mailing list
| Haskell-Cafe@haskell.org
| http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Quasiquoter invocation no longer requires/allows a leading dollar sign.
Good point. I've done this. (Ian, could you merge) Fri Nov 12 08:30:52 GMT 2010 simo...@microsoft.com * Allow the old [$foo| ... |] syntax for quasi-quotes This is just a backward-compatibility thing, to be removed eventually. Simon | -Original Message- | From: haskell-cafe-boun...@haskell.org [mailto:haskell-cafe-boun...@haskell.org] On | Behalf Of Michael Snoyman | Sent: 11 November 2010 22:08 | To: Haskell Cafe | Subject: [Haskell-cafe] Quasiquoter invocation no longer requires/allows a leading | dollar sign. | | Sorry, maybe I missed the memo on this one, but I just noticed this | change to quasi-quotation syntax on the GHC 7 upgrade page[1]. So if | GHC 6.12 *requires* the dollar sign, and GHC 7 *rejects* the dollar | sign, is there any way to write code that will run on both? Is there a | reason we can't keep the dollar sign as supported syntax for a release | or two to make for a cleaner migration? | | Michael | | [1] | http://haskell.org/haskellwiki/Upgrading_packages/Updating_to_GHC_7#Quasiquotation:_. | 5B.24foo.7C7C.5D_-.3E_.5Bfoo.7C7C.5D | ___ | Haskell-Cafe mailing list | Haskell-Cafe@haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] ghc dump the code for derived instances
-ddump-deriv From: haskell-cafe-boun...@haskell.org [mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Ozgur Akgun Sent: 11 November 2010 14:27 To: Haskell cafe Subject: [Haskell-cafe] ghc dump the code for derived instances Café, Is there a way to make GHC dump the code for auto-derived type class instances, say for Show, Eq and such? Thanks, Ozgur ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Are newtypes optimised and how much?
| The exact syntax is a problem (as usual). We have the technology now. The | question is how important it is. | | I think extending the syntax for contexts would be sufficient: | Write a ~~ b for a can be converted to b by wrapping / unwrapping | newtypes, which is a conservative approximation of a and b have the | same representation. | | Then we can define | | safeCoerce :: (a ~~ b) = a - b | safeCoerce = unsafeCoerce Yes, that's right. When I said we have the technology I meant that we (will) have something similar to ~~. See our paper Generative Type Abstraction and Type-level Computation http://www.cis.upenn.edu/~sweirich/newtypes.pdf. No unsafeCoerce required. Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Splittable random numbers
Hi Cafe A while back there was a threadhttp://www.mail-archive.com/haskell-cafe@haskell.org/msg79633.html about a good implementation of a (pseudo) random number generator with a good split operation. There's lots of material on generators that generate a linear sequence of random numbers, but much less on how to generate a tree of random numbers, which is what Haskell's System.Random API requires. I happened to meet Burton Smith recently, who wrote some early papers about this stuff (eg Pseudo random trees in Monte-Carlohttp://portal.acm.org/citation.cfm?id=1746034), so I asked him. His reply is below, along with some follow-up comments from his colleagues Tolga Acar and Gideon Yuval. The generator uses crypto functions, so it's probably more computationally expensive than common linear-sequence generators, but in exchange you get robust splitting. Does anyone feel like taking the idea and turning it into a Haskell library? (Or even a Haskell Wiki page?) I'm taking the liberty of cross-posting to the libraries list. Simon From: Burton Smith Sent: Tuesday, November 02, 2010 3:58 PM To: Simon Peyton-Jones Cc: Gideon Yuval (Gideon Yuval); Tolga Acar Subject: Random number generation With some help from Gideon and Tolga, I think the solution to the arbitrary tree of random numbers problem is as follows: The generator G is a pair comprising a crypto key G.k and an integer counter (the message) G.c. The (next G) operation returns a pair: 1. a random integer r obtained by encrypting G.c with G.k, and 2. a new generator G' such that G'.k = G.k and G'.c = G.c + 1. The (split G) operation is similar, returning the same G', except that instead of returning a random integer r it returns a third generator G'' such that G''.k = r and G''.c = 0. A suitable block cipher system might be 128-bit AES (Rijndael). Unencumbered implementations exist in a variety of languages, and performance is pretty good and will improve dramatically as hardware support improves. I'd pick both crypto key size and the size of the result r to be 128 bits, and employ a 64 bit counter c. Other crypto options exist. From: Simon Peyton-Jones Sent: Wednesday, November 03, 2010 3:11 AM To: Burton Smith; Gideon Yuval (Gideon Yuval) Cc: Tolga Acar; Simon Peyton-Jones Subject: RE: Random number generation Burton, Gideon, Tolga Aha, that's interesting. I'd never seen a random number generator based on crypto, but it seems like an attractive idea. As I understand it, successive calls to 'next' will give you encrypt(0), encrypt(1), encrypt(2), encrypt(3), Is this standard? Does it have provably good randomness properties, (cycle length, what else?) like other RNGs? Or does it simply seem very plausible? Can I send it round to the Haskell mailing list, in the hope that someone will turn the idea into a library? (Ideally I'd like to make claims about the randomness properties in doing so, hence my qns above.) From: Gideon Yuval (Gideon Yuval) Sent: Wednesday, November 03, 2010 7:15 AM To: Simon Peyton-Jones; Burton Smith Cc: Tolga Acar Subject: RE: Random number generation As long as the key, and the non-counting part of the counter, are kept secret, anyone who can distinguish these pseudorandoms from real random, in less than 2^128 steps, has a nice paper for crypto-2011 (this is known as provable security) concerning a weakness in AES128. One exception: real randoms have a birthday paradox; the pseudorandoms suggested do not. If you care, you can: (1)Limit the counter to 2^32 steps (paradox has 2^-64 probability) or even 2^16 (2^-96), then rekey; or (2)XOR 2 such encrypted counters, with different keys; or (3)XOR 3 successive values for the same counter (just possibly cheaper; top-of-head idea). More hard-core: swap the position of key message: encrypting a constant secret with 1,2,3,4 Gives pseudorandoms with no birthday paradox. From: Tolga Acar Sent: 03 November 2010 15:50 To: Gideon Yuval (Gideon Yuval); Simon Peyton-Jones; Burton Smith Subject: RE: Random number generation Simon, The general idea is not really that new in the crypto area with constraints Gideon describes, of course. That is typically called a PRNG - Pseudo Random Number Generator, or in another parlance, Deterministic Random Bit Generators (DRBG). The DRBG constructions based on hash functions and block ciphers are even standardized in NIST publication SP800-90 (even though I may not recommend every one of them). As for the construction below, that is based on the AES block cipher, that essentially takes advantage of the PRP (Pseudo Random Permutation) property of the AES block cipher, as each block cipher ought to be. So, as Gideon outlines below, if you fix the key, the PRP gives you a random-looking (or, in other terms, indistinguishable from random) output that no one without the secret key and the state can generate or easily predict. Assuming an ideal
RE: [Haskell-cafe] Are newtypes optimised and how much?
| Yes, you can freely use Foo/unFoo. There's no runtime penalty. (In the | jargon of GHC's intermediate language, Foo and unFoo translate to | *type-safe casts*, which generate no executable code. | | When does the conversion to type-safe casts occur relative to other | optimizations (namely, rewrite rules)? | | That is, I know that rewrite rules operate on the source language not on | Core, but to what extent does that mean that type-safe casts inhibit the | firing of rules? Rewrite rules work on Core, not source, so they see the type-safe casts. I don't know how to say to what extent they inhibit rules. If you show an example I will try to help. S ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Are newtypes optimised and how much?
| At the end of the day what motivated me to ask these questions it that
| I like very much defining newtypes for most of the types I use, I have
| completely forgotten about `type' aliasing. I'm completely happy to
| write Foo and unFoo all over the place to aid my type correctness, but
| I want a nice generic way to convert to/from newtypes but keeping it a
| compile-time concept. Sometimes I have unThisThat, unTheOther,
| unThoseWhoShantBeNamed, etc. and it I could just use fromIntegral and
| fromString then that would be super.
Yes, you can freely use Foo/unFoo. There's no runtime penalty. (In the jargon
of GHC's intermediate language, Foo and unFoo translate to *type-safe casts*,
which generate no executable code.
That includes the 'newtype deriving' stuff too, and hence your uses of
fromInteger etc.
However, sadly:
| Also, is 'map unFoo' optimised away at compile-time, too? I think that
| it would be compiled to map id. So it would still wrap a thunk around
| each cons. How far does it go?
No, this isn't optimised. The trouble is that you write (map Foo xs), but GHC
doesn't know about 'map'. We could add a special case for map, but then you'd
soon want (mapTree Foo my_tree).
What you really want is to say is something like this. Suppose my_tree :: Tree
String. Then you'd like to say
my_tree ::: Tree Foo
meaning please find a way to convert m_tree to type (Tree Foo), using newtype
coercions.
The exact syntax is a problem (as usual). We have the technology now. The
question is how important it is.
Simon
| -Original Message-
| From: haskell-cafe-boun...@haskell.org
[mailto:haskell-cafe-boun...@haskell.org]
| On Behalf Of Christopher Done
| Sent: 19 October 2010 19:12
| To: Haskell Cafe
| Subject: [Haskell-cafe] Are newtypes optimised and how much?
|
| So I have the following nice things:
|
| {-# LANGUAGE GeneralizedNewtypeDeriving, OverloadedStrings #-}
|
| import Data.String
|
| newtype Foo = Foo { unFoo :: String } deriving (IsString)
|
| x :: Foo
| x = Hello, World!
|
| newtype Bar = Bar { unBar :: Integer } deriving
| (Eq,Show,Num,Integral,Real,Enum,Ord)
|
| y :: Bar
| y = 2
|
| I can write literals and they will be converted to the type I wanted
| with no extra verbiage needed.
|
| Questions (I'm talking about GHC when I refer to compilation):
|
| (1) Are fromString and fromIntegral ran at compile time? I don't think
| that this is the case. I think they are just translated to fromString
| Hello, World! and fromIntegral 2 verbatim.
| (2) Regardless of this, the implementation of fromString and
| fromIntegral is essentially a no-op, it's just fromString = Foo,
| fromIntegral = Bar, which is in turn essentially fromString = id,
| fromIntegral = id, as far as I understand it. It's purely compile
| time. But supposing I write:
|
| fromIntegral (fromIntegral (2::Integer) :: Bar) :: Integer
|
| Is this at the end of the day equal to just (2::Integer)? Thinking
| simple-mindedly, I would say, yes. The compiler knows that
| fromIntegral :: Integer - Bar == id, and that fromIntegral :: Bar -
| Integer == id (right?). But is that the case? Perhaps the type class
| methods have some dictionary and thus cannot be inlined, or maybe that
| doesn't matter?
|
| At the end of the day what motivated me to ask these questions it that
| I like very much defining newtypes for most of the types I use, I have
| completely forgotten about `type' aliasing. I'm completely happy to
| write Foo and unFoo all over the place to aid my type correctness, but
| I want a nice generic way to convert to/from newtypes but keeping it a
| compile-time concept. Sometimes I have unThisThat, unTheOther,
| unThoseWhoShantBeNamed, etc. and it I could just use fromIntegral and
| fromString then that would be super.
|
| Also, is 'map unFoo' optimised away at compile-time, too? I think that
| it would be compiled to map id. So it would still wrap a thunk around
| each cons. How far does it go?
|
| So, if I go around using fromIntegral/fromString (etc. for other
| newtype types), is it still kept compile time? After having newtypes
| catch dozens of type mismatches that otherwise wouldn't unified
| happily but were completely wrong (e.g. wrong argument order), I've
| found newtype to be an indispensable part of Haskell and of writing a
| large piece of software.
|
| Cheers
| ___
| Haskell-Cafe mailing list
| Haskell-Cafe@haskell.org
| http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Template Haskell: onward and upward
Folks Following lots of feedback from users, especially at ICFP, I've evolved some proposals for Template Haskell, that should make it both more expressive, and more secure. http://hackage.haskell.org/trac/ghc/blog/Template%20Haskell%20Proposal Do let me know what you think. Discussion by email is fine (cc me if it's on Haskell-cafe), or comments direct on the Trac. (None of this will be in GHC 7.0; it's a proposed plan for post-release improvements.) Thanks Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] try, seq, and IO
You may get useful help from Haskell Cafe. But if you can produce a cut-down example without complex dependencies, we could also look at it. Simon | -Original Message- | From: haskell-cafe-boun...@haskell.org [mailto:haskell-cafe- | boun...@haskell.org] On Behalf Of Jeroen van Maanen | Sent: 15 September 2010 10:13 | To: Haskell Café | Subject: [Haskell-cafe] try, seq, and IO | | The past year I have been working on a port of my machine learning project | named LExAu from Java to Haskell. I'm still very glad I took the jump, | because the complexity curve appears to be log shaped rather than exp shaped. | In one year I almost got to the functionality that had taken me five years to | produce in Java (of course it helped a lot that I had a working prototype | this time). | | There is one thing that still bothers me though: when I write seq or $! it | doesn't seem to have any effect! | | Currently I am trying to add some exception handling to help me debug the | system, but the code that I managed to produce depends on the logging | statement to produce the desired result. :-( It looks like this, and only | works when I uncomment the line '-- logger Check sum: [...]', otherwise the | exception is caught by the try around the body of the thread that this code | runs in: | | do logger Received update [showString label, logs update] | result - | try $! | do maybeUpdatedModel - return $ f update startModel |theCheckSum - return $ liftM checkSum maybeUpdatedModel | -- logger Check sum [showString label, shows theCheckSum] |return $! seq theCheckSum maybeUpdatedModel | maybeNextModel - | case result of | Right theMaybeNextModel - return theMaybeNextModel | Left exception - | do let exc :: SomeException | exc = exception | logger Exception [showString label, shows exception] | return Nothing | logger Maybe next model [showString label, logs maybeNextModel] | | For more context see: | | | http://lexau.svn.sourceforge.net/viewvc/lexau/branches/totem/src/LExAu/Pipeli | ne/Concurrent.hs?revision=326view=markup | | after line 241. | | Can someone explain why a few showStrings a shows and a putStrLn are more | effective in forcing the check sum to be computed (which necessarily | evaluates the complete updated model and reveals the lurking exception) than | the seq on the line just below the logging statement? | | Cheers, Jeroen ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] circular imports
I was under the impression that the main reason GHC requires .hs-boot files is that nobody has had the time or inclination to make it resolve circular dependencies automatically, and not an intentional design decision to encourage good design. Indeed. I’ve added some notes here http://hackage.haskell.org/trac/ghc/ticket/1409#comment:37 Simon From: haskell-cafe-boun...@haskell.org [mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Daniel Peebles Sent: 07 September 2010 06:06 To: Mathew de Detrich Cc: Ivan Lazar Miljenovic; haskell Subject: Re: [Haskell-cafe] circular imports I was under the impression that the main reason GHC requires .hs-boot files is that nobody has had the time or inclination to make it resolve circular dependencies automatically, and not an intentional design decision to encourage good design. On Tue, Sep 7, 2010 at 6:51 AM, Mathew de Detrich dete...@gmail.commailto:dete...@gmail.com wrote: I had the same issue zonks ago, and I resorted to using the hs-boot file method as well (which worked fine) Which I guess brings me to my second point, is this something that GHC should do automatically when it sees circular dependencies? When I asked about it earlier on #haskell, I was told that its better that way because it discourages making bad design through circular dependencies (yet in my case and I assume the other cases as well, not using the hs-boot method would have made the design much worse). Are there any cases in particular where people would be encouraged to make interface design with circular dependencies (and that design be deemed as horrible) as opposed to what seems to be more realistic case where circular dependencies rarely crop up, and when they do they actually make the design better? On Tue, Sep 7, 2010 at 1:48 PM, Ivan Lazar Miljenovic ivan.miljeno...@gmail.commailto:ivan.miljeno...@gmail.com wrote: On 7 September 2010 03:44, Edward Z. Yang ezy...@mit.edumailto:ezy...@mit.edu wrote: Excerpts from Evan Laforge's message of Mon Sep 06 13:30:43 -0400 2010: I feel like the circular imports problem is worse in haskell than other languages. Maybe because there is a tendency to centralize all state, since you need to define it along with your state monad. But the state monad module must be one of the lower level ones, since all modules that use it must import it. However, the tendency for bits of typed data to migrate into the state means it's easy for it to eventually want to import one of its importers. And the state monad module gets larger and larger (the largest modules in my system are those that define state monads: 1186 lines, 706 lines, 1156 lines---the rest tend to be 100--300 lines). I have used hs-boot files to this effect. I separated data and functionality, and typeclasses, which must be in the same module as data or are considered orphaned, get definitions via a circular import. I'm just getting to the point where I have a similar problem. I was thinking about splitting instances off from the classes (and telling GHC to not worry about orphaned instances for the instance-only modules) but then realised that some instance declarations would be circular as well, so I have to either use hs-boot files, define everything in one big module and then re-export them in ways that make sense or define all instances in one big module (at least for those types which have circular deps among instances) and re-export accordingly. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.commailto:ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.comhttp://IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.orgmailto:Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.orgmailto:Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] RE: [Haskell] Proposal: Form a haskell.org committee
Ian et al | To fix this problem, we propose that we create a haskell.org | committee, which is responsible for answering these sorts of questions, | although for some questions they may choose to poll the community at | large if they think appropriate. I think that's an excellent idea. I think there should be a web page describing what the committee does, who is in it, how to contact it, etc. I'm sure you intended that. An annual statement of what money came in and went out would be good practice. Well the committee also be responsible for the haskell.org web site? | We suggest that the committee be composed of 5 representatives from the | community, with committee members standing down after at most 3 years. | Each year the committee will appoint one of their members to be the chair. It's usually helpful to establish a rotation so that everyone knows who is going to stand down when, and to arrange that there isn't a sudden glut one year. Document the stand-down dates on the committee web page. In my experience, everyone forgets! Five might be a little small. It might be good to allow for a person to be re-elected for a second term if they are willing. It's a good principle to have rotation, but a pity to lose willing and experienced talent. But six years is enough. | As membership of the Haskell community is not well-defined, and voting | would potentially be open to abuse if anyone were able to vote, we | propose that the committee should choose their replacements from open | nominations. I agree with the problem, and I think your proposed solution may do for now, but it's obviously not a robust solution. I trust you five, but in three years time you may all have stood down! A possible solution would be to have an electoral college of people entitled to vote. It should be easy to become a member of the college: any track record of contributions to the Haskell community, including constructive contributions to Haskell Cafe, would be enough. Then the college can elect the committee. It's debatable whether this is worth the bother at this point. Maybe it would be enough to document on the committee page that we don't regard the nomination process as robust, and if any concern arises we will consider something more substantial. Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] FW: [TYPES/announce] CUFP 2010 Call for Participation
Dear Haskellers CUFP should be a lot of fun this year. Do consider going. Simon Commercial Users of Functional Programming Workshop (CUFP) 2010 Call for Participation Sponsored by SIGPLAN Co-located with ICFP 2010 _ 1 - 2 October 2010 Baltimore (MD), USA http://cufp.org/conference/schedule/2010 Reservation will be available through ICFP's website: http://www.icfpconference.org/icfp2010 _ Functional programming languages have been a hot topic of academic research for over 35 years, and have seen an ever larger practical impact in settings ranging from tech startups to financial firms to biomedical research labs. At the same time, a vigorous community of practically-minding functional programmers has come into existence. CUFP is designed to serve this community. The annual CUFP workshop is a place where people can see how others are using functional programming to solve real world problems; where practitioners meet and collaborate; where language designers and users can share ideas about the future of their favorite language; and where one can learn practical techniques and approaches for putting functional programming to work. CUFP 2010 will feature three hour Functional Programming tutorials given by language experts on the first day and Experience and Technical Talks on day two. Attendees may attend either or both days. Talks Program, October 2nd 2010 Luke Hoban (Microsoft) Keynote: F#: Embracing Functional Programming in Visual Studio 2010 Sally A Browning (Galois Inc) Cryptol, a DSL for Cryptographic Algorithms Marius Eriksen (Twitter) Scaling Scala at Twitter Michael Fogus (Science Applications International Corporation) Naïveté vs. Experience - or, How We Thought We Could Use Scala and Clojure, and How We Actually Did It Neal Glew Leaf Petersen (Intel) Functional Language Compiler Experiences at Intel Warren Harris (Metaweb) Functional Programming at Freebase Warren A. Hunt, Jr. (U. of Texas) Eating One’s Own Dog Food Rusty Klophaus (Basho Technologies) Riak Core: Building Distributed Applications Without Shared State Howard Mansell (Credit Suisse) Eden: An F#/WPF frameworok for building GUI tools Erik Meijer (Microsoft) Reactive Extensions (Rx): Curing Your Asynchronous Programming Blues Tutorial Program, October 1st 2010 Morning: Clojure (Aaron Bedra) Building robust servers with Erlang (Martin Logan) High Performance Haskell (Johan Tibell) Afternoon: F# 2.0 - A day at the beach (Rick Minerich) Implementing web sites with Scala and Lift (David Pollak) Camlp4 and Template Haskell (Nicolas Pouillard, Jake Donham) There will be no published proceedings, as the meeting is intended to be more a discussion forum than a technical interchange. For more information, for more information, including presentation abstracts and the most recent schedule information, visit http://cufp.org See you there! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] foreign function interface Invalid type signature
The HEAD now does FFI by default (Haskell 2010) so you would not have tripped
over this.
But even if you use the -XHaskell98 flag to recover Haskell-98 mode, you get
this error:
Foo.hs:9:1:
Invalid type signature: foreign export ccall foo :: CInt - CInt
Perhaps you meant to use -XForeignFunctionInterface?
Which would have been more helpful for you.
Simon
| -Original Message-
| From: haskell-cafe-boun...@haskell.org [mailto:haskell-cafe-
| boun...@haskell.org] On Behalf Of Ivan Lazar Miljenovic
| Sent: 26 August 2010 01:48
| To: Ken Takusagawa
| Cc: Haskell Cafe
| Subject: Re: [Haskell-cafe] foreign function interface Invalid type
| signature
|
| On 26 August 2010 10:41, Ken Takusagawa ken.takusagaw...@gmail.com wrote:
| What am I doing wrong?
|
| module Ffi2 where
| {
| import Foreign.C.Types;
|
| foo :: CInt - CInt;
| foo x = x;
|
| foreign export ccall foo :: CInt - CInt;
|
| }
|
| Did you enable the
|
|
| $ ghc -c Ffi2.hs
|
| Ffi2.hs:8:0: Invalid type signature
|
| You need to call it with -XForeignFunctionInterface to enable FFI methinks.
|
|
| --
| Ivan Lazar Miljenovic
| ivan.miljeno...@gmail.com
| IvanMiljenovic.wordpress.com
| ___
| Haskell-Cafe mailing list
| Haskell-Cafe@haskell.org
| http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Is there any experience using Software Transactional Memory in substantial applications?
| Recently we discussed Haskell and especially types in Russian part of | LiveJournal and of course we talk about STM. | | My opponent gave me that link: | http://logicaloptimizer.blogspot.com/2010/06/so-microsofts-experiments-with- | software.html | | It says that performance with STM in Microsoft Research was more than | horrible. I can't resist replying to this. Several things to say: * STM requires runtime logging of every memory read and write. In an imperative language (such as C#), in which the very fabric of computation involves reads and writes, STM is bound to be expensive. [Lots of work has been done to omit redundant logging based on program analysis, but it's still expensive.] In contrast, in a pure functional language there are no reads and writes, so all the pure part has zero overhead. Only when you do 'readTVar' and 'writeTVar' do you pay the overhead; these are a tiny fraction of all memory accesses. So we get a huge win from the fact that Haskell's computational fabric is pure. * When do you need readTVar/writeTVar? Answer, precisely when you are manipulating state shared between threads. If you do a *lot* of this, your program is *bound* to perform badly; data has to be shuffled between processors, caches have to do their thing, etc. The key to high performance in parallel applications is to minimise sharing. If you do that, then you'll (dynamically) have few readTVar/writeTVars, and so regardless of how expensive they are it'll run fast. There are occasional data structures that are (a) necessarily shared and (b) necessarily hot-spots. Then STM is perhaps not the best solution, which is why GHC provides a range of primitives: as well as STM we've kept MVars, and we also have atomicModifyIORef which is even cheaper. Horses for courses. * The GHC STM implementation is simple. It's a direct implementation of our paper Composable Memory Transactions. We could make strong simplifying assumptions. In contrast, the Microsoft .NET project had to tackle a much more challenging set of requirements. In particular, they thought that programmers would *require* to be able to manipulate the same locations both *inside* and *outside* a transaction. It turns out that this simple requirement dramatically complicates the implementation [see multiple papers by Tim Harris on this topic]. Also they wanted nested transactions, and a raft of other complications. Each of these features was strongly motivated, and the MS guys in Redmond are extremely smart, but the result was necessarily complex and, as it turned out, unacceptably slow. Summary: it's simplistic to say STM good or STM bad. For STM to work well you need - very limited side effects in the computational fabric - limited communication between threads - a simple design Then STM can work extremely well. And it does in Haskell. But it's not a silver bullet; concurrency is too complex to be slain with one bullet. Indeed those precise words appear in every talk about STM I have given (eg http://research.microsoft.com/en-us/um/people/simonpj/papers/stm) Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Template Haskell sees into abstract data types
I assume you've seen http://hackage.haskell.org/trac/ghc/ticket/4222
There are non-obvious design choices here
Simon
| -Original Message-
| From: haskell-cafe-boun...@haskell.org
[mailto:haskell-cafe-boun...@haskell.org] On
| Behalf Of Serguey Zefirov
| Sent: 28 July 2010 11:07
| To: Jonas Almström Duregård
| Cc: Ivan Lazar Miljenovic; haskell
| Subject: Re: [Haskell-cafe] Template Haskell sees into abstract data types
|
| 2010/7/28 Jonas Almström Duregård jonas.dureg...@gmail.com:
| Hi,
|
| I cannot write classes that see into internal structure. For example,
| I cannot write my own (de)serialization without using from/toAscList.
|
| Actually I don't believe you can do this with TH either. TH splices
| code into the module where you use it. The generated code is then type
| checked in this module. If constructors that are not exported are used
| in the generated code, I believe you will get an error.
|
| This could still be an issue because your TH code won't know if the
| constructors are exported or not, but i doubt you can actually do
| things with TH that you can't do with plain H.
|
| I doubt that doubt first. ;)
|
| At least, it looks like I can, I didn't tried, actually.
| Neither have I.
|
| So I did. And succeed: TH sees into data types.
|
| (ghc 6.12.1)
|
| Module A.hs, contains definition of abstract data type A, class Class
| and some primitive instance generator for that Class. Instance
| generator takes a data declaration name, takes first constructor
| (which should be argumentless) and makes it a value for definition of
| c function.
| --
| {-# LANGUAGE TemplateHaskell #-}
|
| module A(A,Class(..),mkSimpleClass) where
|
| import Language.Haskell.TH
|
| data A = A1 | A2
| deriving Show
|
| class Class a where
| c :: a
|
| mkSimpleClass :: Name - Q [Dec]
| mkSimpleClass name = do
| TyConI (DataD [] dname [] cs _) - reify name
| ((NormalC conname []):_) - return cs
| ClassI (ClassD [] cname [_] [] [SigD mname _]) - reify ''Class
| return [InstanceD [] (AppT (ConT cname) (ConT dname)) [FunD mname
| [Clause [] (NormalB (ConE conname)) [
| --
|
| Module B.hs, imports A.hs, uses mkSimpleClass on A.A name:
| --
| {-# LANGUAGE TemplateHaskell #-}
|
| module B where
|
| import A
|
| $(mkSimpleClass ''A)
| --
|
| I successfully loaded B.hs into ghci, Expression c :: A successfully
| evaluates to A1.
|
| My view on that problem is that we can add TyConIAbs for incompletely
| exported and abstract data types.
|
| When someone get TyConIAbs after reification, he will know that he
| doesn't know everything about that type.
|
| So, empty data declaration like data Z will return TyConI with empty
| list of constructors, TyConIAbs will have empty list of constructors
| for abstract data type.
| ___
| Haskell-Cafe mailing list
| Haskell-Cafe@haskell.org
| http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Template Haskell sees into abstract data types
| Data.Map.Map and Data.Set.Set are exported abstractly, without | exposing knowledge about their internal structure. | | I cannot directly create my own class instances for them because of | that. But I found that I can write Template Haskell code that could do | that - those data types could be reified just fine. I've created a ticket for this http://hackage.haskell.org/trac/ghc/ticket/4222. In writing it down I identify several design questions that need to be addressed before we can fix this bug. Help welcome. Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Docs on the current and future constraint solver?
Corey | On 14 July 2010 18:39, Corey O'Connor coreyocon...@gmail.com wrote: | I believe I have run headlong into issue #3064 in ghc | (http://hackage.haskell.org/trac/ghc/ticket/3064). All I think I know | is this: | * this is a performance issue with the system used to solve type | constraints. | * the solver is undergoing an overhaul to resolve performance issues | in addition to other issues. | * An efficient constraint solver is difficult. NP-Complete in the general | case? It would be very helpful to have your code as a test case. Can you boil out a concrete program that demonstrates very poor performance of the type checker, and submit a Trac report? That way we'll test the new type inference engine against it. Lacking the example, we won't. Which is isn't a promise that we'll solve your problem -- but it's much easier to solve if we have a concrete example. Many thanks! Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Re: checking types with type families
| -- Does this typecheck? | f :: C a b = T a - Bool | f T1 = True | f T2 = op 3 | | The function f should typecheck because inside the T2 branch we know | that (a~Int), and hence by the fundep (b~Bool). | | Perhaps I'm confused, but there seems to be no link between | the call 'op 3' and 'a' in this example. While the 'desugaring' | introduces just such a connection. You're right, I made a mistake here. Sorry! I hope you could see what I was after though. I've written a long email about fundeps and overlap that should clarify further. Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] checking types with type families
Martin Sulzmann, Jeremy Waznyhttp://www.informatik.uni-trier.de/%7Eley/db/indices/a-tree/w/Wazny:Jeremy.html, Peter J. Stuckeyhttp://www.informatik.uni-trier.de/%7Eley/db/indices/a-tree/s/Stuckey:Peter_J=.html: A Framework for Extended Algebraic Data Types. FLOPS 2006http://www.informatik.uni-trier.de/%7Eley/db/conf/flops/flops2006.html#SulzmannWS06: 47-64 describes such a system, fully implemented in Chameleon, but this system is no longer maintained. Type families and Fundeps are equivalent in expressive power and it's not too hard to show how to encode one in terms of the other. Local constraints are an orthogonal extension. In terms of type inference, type families + local constraints and fundeps + local constraints pose the same challenges. Probably, Simon is refrerring to the 'unresolved' issue of providing a System F style translation for fundeps + local constraints. Apologies, Martin, you are quite right. Indeed, you were the first to teach me about implication constraints, which are the key to combining local constraints and functional dependencies. Chameleon implements such a system, using (I believe) the Constraint Handling Rule framework to solve the resulting constraints. However as you mention we could not figure out a good way to combine this approach to constraint solving with evidence generation, although it seems that in principle it should be possible. As you say Well, the point is that System FC is geared toward type families. The two possible solutions are (a) either consider fundeps as syntactic sugar for type families (doesn't quite work once you throw in overlapping instances), (b) design a variant System FC_fundep which has built-in support for fundeps. Why is FC is geared towards type families? It's not an accidental bias; it's more that I know how to do (a) and I don't know how to do (b). I'll write separately about the issue of overlap Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Fundeps and overlapping instances
Oleg points out, and Martin also mentions, that functional dependencies appear
to interact OK with overlapping instances, but type families do not. I this
impression is mistaken, and I'll try to explain why in this message, in the
hope of exposing any flaws in my reasoning.
We can't permit overlap for type families because it is unsound to do so (ie
you can break well typed programs don't go wrong). But if it's unsound for
type families, it would not be surprising if it was unsound for fundeps too.
(I don't think anyone has done a soundness proof for fundeps + local
constraints + overlapping instances, have they?) And indeed I think it is.
So the short summary of this message is: if it works for fundeps it works for
type families, and vice versa. (NB this equivalence is not true about GHC's
current implementation, however. GHC doesn't support the combination of
fundeps and local constraints at all.)
Such an equivalence doesn't argue against fundeps; I'm only suggesting the that
the two really are very closely equivalent. I much prefer type families from
a programming-style point of view, but that's a subjective opinion.
Simon
Imagine a system FDL that has functional dependencies and local type
constraints. The big deal about this is that you get to exploit type
equalities in *given* constraints. Consider Oleg's example, cut down a bit:
class C a b | a - b
instance C Int Bool
newtype N2 a = N2 (forall b. C a b = b)
t2 :: N2 Int
t2 = N2 True
We end up type-checking (True :: forall b. C Int b = b). From the functional
dependency we know that (b~Bool), so the function should typecheck. GHC
rejects this program; FDL would not.
But making use of these extra equalities in given constraints is quite
tricky. To see why look first at Example 1:
module X where
class C a b | a - b
data T a where
MkT :: C a b = b - T a
module M1 where
import X
instance C Int Char where ...
f :: Char - T Int
f c = MkT c
module M2 where
import X
instance C Int Bool
g :: T Int - Bool
g (MkT x) = x
module Bad where
import M1
import M2
bad :: Char - Bool
bad = g . f
This program is unsound: it lets you cast an Int to a Bool; result is a
seg-fault.
You may say that the problem is the inconsistent functional dependencies in M1
and M2. But GHC won't spot that. For type families, to avoid this we
eagerly check for conflicts in type-family instances. In this case the
conflict would be reported when compiling module Bad, because that is the first
time when both instances are visible together.
So any FDL system should also make this eager check for conflicts.
What about overlap? Here's Example 2:
{-# LANGUAGE IncoherentInstances #-}
module Bad where
import X
-- Overlapping instances
instance C Int Bool -- Instance 1
instance C a [a] -- Instance 2
f :: Char - T Int
f c = MkT c -- Uses Instance 1
g :: T a - a
g (MkT x) = x-- Uses Instance 2
bad :: Char - Int
bad = g . f
Again, a seg fault if it typechecks. But will it? When typechecking 'g', we
get a constraint (C a ?), where 'a' is a skolem constant. Without
IncoherentInstances GHC would reject the program on the grounds that it does
not know what instance to choose. But *with* IncoherentInstances it would
probably go through, which is unsound. So IncoherentInstances has moved from
causing varying dynamic behaviour to causing seg faults.
Very well, so FDL must get rid of IncoherentInstances altogether, at least for
classes that have functional dependencies (or that have superclasses that do).
But at the moment GHC makes an exception for *existentials*. Consider Example
3:
class C a b | a - b
-- Overlapping instances
instance C Int Bool -- Instance 1
instance C a [a] -- Instance 2
data T where
MkT :: C a b = a - b - T
f :: Bool - T
f x = MkT (3::Int) x -- Uses Instance 1
g :: T - T
g (MkT n x) = MkT n (reverse x) -- Uses Instance 2
bad :: Bool - T
bad = g . f
In the pattern match for MkT in g we have the constraint (C a b), where 'a' is
existentially bound. So under GHC's current rules it'll choose the (C a [a])
instance, and conclude that (b ~ [a]). So it's ok to reverse x. But it isn't;
see function bad!
So to avoid unsoundness we must not choose a particular instance from an
overlapping set unless we know, absolutely positively, that the other cases
cannot match.
(GHC's exception for existentials was introduced in response to user demand.
Usually, overlapping instances are somehow semantically coherent, and with an
existential we are *never* going to learn more about the instantiating type, so
choosing the best available seems like a good thing to do.)
But even nuking IncoherentInstances altogether is not enough. Consider this
variant of Example 3, call it Example 4:
module M where
class C a b | a - b
instance C a
RE: [Haskell-cafe] checking types with type families
| Here's a concrete case I recently ran into: | | type family SomeOtherTypeFamily a | class SomeClass a where type SomeType a | instance a ~ SomeOtherTypeFamily b = SomeClass a where |type SomeType a = (b,Int) |-- (error) Not in scope: type variable `b' | | The same thing with fundeps: | | class SomeClass a b | a - b | instance a ~ SomeOtherTypeFamily b = SomeClass a (b,Int) | -- works fine It's not the same thing at all! The code you give certainly should fail. Suppose you use fundeps thus: class C a b | a-b where op :: a - b - b The idiomatic way to replace this with type functions is to remove the 'b' parameter, thus: class C a where type B a op :: a - B a - B a Sometimes you don't want to do this. For example, you might have a bidirectional fundep. Then you can (or rather will be able to) use a superclass thus: class (B a ~ b) = C a b where type B a The superclass says that you can only instantiate this class with a second argument b that is equal to (B a). Thus you might have an instance instance C Int Bool where type B Int = Bool Meanwhile we are working hard on the new type inference engine, which will allow superclass equalities like these. Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] checking types with type families
Claus | I'm interested in situations where you think fundeps work | and type families don't. Reason: no one knows how to make | fundeps work cleanly with local type constraints (such as GADTs). | | If you think you have such as case, do send me a test case. | | Do you have a wiki page somewhere collecting these examples? I don't think so. Would you feel like starting one? I do try to turn every tricky example into a case in the testsuite though. | Also, what is the difference between fundeps and type families | wrt local type constraints? I had always assumed them to be | equivalent, if fully implemented. Similar to logic vs functional | programming, where Haskellers tend to find the latter more | convenient. Functional logic programming shows that there | are some tricks missing if one just drops the logic part. Until now, no one has know how to combine fundeps and local constraints. For example class C a b | a-b where op :: a - b instance C Int Bool where op n = n0 data T a where T1 :: T a T2 :: T Int -- Does this typecheck? f :: C a b = T a - Bool f T1 = True f T2 = op 3 The function f should typecheck because inside the T2 branch we know that (a~Int), and hence by the fundep (b~Bool). But we have no formal type system for fundeps that describes this, and GHC's implementation certainly rejects it. In GHC, as in Mark Jones's original descrption, fundeps just give rise to some extra unifications of otherwise under-constrained type variables. Now, Dimitrios and I have recently found that our OutsideIn type system and inference algorithm (described in the Epic Paper on my home page) can easily handle functional dependencies too, by adding a couple of extra rules. That's good news both because it improves our understanding (well, mine anyway); and because it will give GHC a solid implementation, and one that will make the above program typecheck. We are deep in the midst of implementing OutsideIn right now. That said, I'd much prefer to express the program like this: class D a where type B a dop :: a - B a instance D Int where type B Int = Bool dop n = n0 g :: D a = T a - Bool g T1 = True g T2 = dop 3 More perspicuous types, simpler reasoning. Bottom line: I now have a clear idea of how to formalise and implement fundeps; but I am dubious about the long-term software engineering merits of supporting both fundeps and type families. They cover the same territory. Copying Oleg in case he has other counter-examples. Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Inferring the most general type
I don't know an algorithm that can always infer the most general types in situations like this. In your example, if you give a signature for the simple function (f :: Y Maybe - Int), and use RelaxedPolyRec, then GHC will happily infer the type you want for g. For RelaxedPolyRec to work its magic, you just need to cut the strongly connected component with a type signature - but you can cut it anywhere you please. Interesting example, though. I've added a test to GHC's regression suite to make sure we do infer the right type for g, given the monomoprhic type for f. Simon From: haskell-cafe-boun...@haskell.org [mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Job Vranish Sent: 22 June 2010 16:06 To: Haskell Cafe mailing list Subject: [Haskell-cafe] Inferring the most general type Esteemed fellow haskellers, I recently ran into a very simple real life case where Haskell's rules for inferring the types for mutually recursive definitions resulted in a type that was less general than it could be. It took me a while to realize that the type error I was getting wasn't actually a problem with my code. I understand why Haskell does this (it infers the strongly connected mutually recursive definitions monomorphically), but I think it _could_ infer the more general type even with recursive definitions like this. Here is a simplified example that illustrates the problem: import Data.Maybe -- The fixed point datatype data Y f = Y (f (Y f)) -- silly dummy function maybeToInt :: Maybe a - Int maybeToInt = length . maybeToList -- f :: Y Maybe - Int f (Y x) = g maybeToInt x g h x = h $ fmap f x This is the type it wants to infer for g g :: (Maybe Int - Int) - Maybe (Y Maybe) - Int This is the type I think it should have, note you can't force the type with a typesig without -XRelaxedPolyRec g :: (Functor f) = (f Int - b) - f (Y Maybe) - b If I use -XRelaxedPolyRec I can manually specify the more general type, but then I have to convince myself that there isn't a more general type that I'm missing. Are there other known algorithms that yield a more general type? and if so, what was the rational for Haskell keeping the current method? I worked out an alternative algorithm that would give a more general type (perhaps the most general type) but it has factorial complexity and probably wouldn't be good for strongly connected groups with 7 or more members. Even so, I would much rather have the inferred types always be the most general ones and be required to add type signatures for mutually recursive groups with 7 or more members (which probably need to be redesigned anyway) than be always required to manually figure out the more general signatures. What do you think? - Job ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] checking types with type families
| Well, from looking at the documentation, it looks like I could maybe | use a type family if I could write: | | class (DerivedOf a ~ derived) = Typecheck a derived where | ... That's the right idiom yes. But see my message of a few minutes ago... It's neater still to remove the 'derived' parameter altogether, which you can do with uni-directional fundeps. Thus instead of class Typecheck a derived where op :: a - derived you have class Typecheck a where type Derived a op :: a - Derived a | Presumably then I could combine functions 'Typecheck a derived' | constraints without getting lots of Could not deduce (Typecheck a | derived3) from the context (Typecheck a derived13) errors. I'm only | guessing though, because it looks like it's not implemented yet as of | 6.12.3. Correct. These equality superclasses will work in 6.14 and (in a few weeks) in the HEAD, but not in 6.12. But you may not need them if you have unidirectional fundeps. Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] RE: proposal: HaBench, a Haskell Benchmark Suite
I'm delighted that you are interested in this benchmarking stuff. Much needed. Thank you! | So I still very much like the approach taken by the venerable nofib | suite where it includes not only the real programs, but also the | microbenchmarks and the small programs; you don't have to use these in | published results, but they're invaluable to us compiler developers, and | having a shared framework for all the benchmarks makes things a lot easier. Yes yes. It's *essential* to retain the micro-benchmarks. They often show up in high relief a performance regression that would be hidden or much less prominent in a big program. The three-way split imaginary/spectral/real has served us well. Let's keep it! Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] checking types with type families
| I think your problem here is that there's no mention of `a' on the | left-hand size of from_val's type signature; you either need to use | MPTC+fundep to associate what result is compared to a, or else use a | phantom type parameter of Val to make it data Val result a = ... and | then from_val :: Val result a - Maybe a. | | Aha! Why didn't I think of plain old MPTC+fundep? For some reason | type families feel a lot more fun. Turns out you can write 'instance | Typecheck (SomeMonad result) result' and instead of complaining about | a duplicate symbol it unifies 'result', exactly like I wanted. I'm interested in situations where you think fundeps work and type families don't. Reason: no one knows how to make fundeps work cleanly with local type constraints (such as GADTs). If you think you have such as case, do send me a test case. Thanks Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Re: Data instance for a GADT
There have been a couple of emails about Template Haskell support for · GADTs · View patterns · Reifying instances There’s a ticket for this already http://hackage.haskell.org/trac/ghc/ticket/3497 It’s mainly a library design question, in this case the design of the Template Haskell data types in Language.Haskell.TH.Syntax. It needs some motivated person to propose a design, get a consensus, and write some boilerplate code. Just use the standard libraries process An issue is the extent to which it’s ok to change the Template Haskell data types (and thereby break people’s code), but that’s something the interested parties can work out together. If you evolve a consensus design I’m more than happy to make it part of GHC. I just don’t want to drive the consensus building! Simon From: haskell-cafe-boun...@haskell.org [mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Ozgur Akgun Sent: 14 April 2010 10:53 To: Haskell cafe Subject: [Haskell-cafe] Re: Data instance for a GADT Seeing this old thread[1], I hope something happened towards enabling this. Does anybody know the current status about using TH on GADTs? [1] http://www.haskell.org/pipermail/template-haskell/2006-August/000567.html On 14 April 2010 10:32, Ozgur Akgun ozgurak...@gmail.commailto:ozgurak...@gmail.com wrote: answering to myself: I guess this is related: http://hackage.haskell.org/trac/ghc/ticket/3497 On 14 April 2010 10:13, Ozgur Akgun ozgurak...@gmail.commailto:ozgurak...@gmail.com wrote: Cafe, How can I provide a Data instance for a GADT? I am trying to TH on it, and Uniplate requires Data. I tried StandaloneDeriving, but it seems not to work. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Good US Grad schools for functional languages?
I'd also think of Harvard (Morrisset), Tufts (Ramsey), Portland State (Jones, Sheard), Yale (Hudak), North Eastern (Wand, Felleisen, Shivers), Utah (Flatt), Chicago (Reppy, MacQueen), North Western (Findler). Simon From: haskell-cafe-boun...@haskell.org [mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Job Vranish Sent: 13 May 2010 18:41 To: Haskell Cafe mailing list Subject: [Haskell-cafe] Good US Grad schools for functional languages? Anybody know of a good grad school in the US for functional languages? (good = has Ph.D. program that covers functional languages, type systems, correctness proofs, etc...) So far Indiana University is the only one I've found that has a strong showing in this area. A way to get into one of the awesome UK schools for free would work too :D - Job ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Modular type inference
Friends Many of you will know that I've been muttering about re-engineering GHC's type inference engine for some time now. Dimitrios, Tom, Martin and I have just completed an epic paper describing the Glorious New Framework that forms the substance of the above mutterings: http://haskell.org/haskellwiki/Simonpj/Talk:OutsideIn We'd love comments and feedback. Dimitrios and I plan to roll up our sleeves and implement it in June. Simon Modular type inference with local assumptions: OutsideIn(X) Abstract. Advanced type system features, such as GADTs, type classes, and type families have have proven to be invaluable language extensions for ensuring data invariants and program correctness among others. Unfortunately, they pose a tough problem for type inference, because they introduce local type assumptions. In this article we present a novel constraint-based type inference approach for local type assumptions. Our system, called OutsideIn(X), is parameterised over the particular underlying constraint domain X, in the same way as HM(X). This stratification allows us to use a common metatheory and inference algorithm. Going beyond the general framework, we also give a particular constraint solver for X = type classes + GADTs + type families, a non-trivial challenge in its own right. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] GHC, odd concurrency space leak
I have not been following the details of this, I'm afraid, but I notice this:
forever' m = do _ - m
forever' m
When I define that version of forever, the space leak goes away.
What was the old version of forever that led to the leak?
If you can boil down the leak to a simple test case, do submit a Trac ticket.
Simon
From: haskell-cafe-boun...@haskell.org
[mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Jason Dagit
Sent: 14 April 2010 22:50
To: Gregory Collins
Cc: Haskell Cafe
Subject: Re: [Haskell-cafe] GHC, odd concurrency space leak
On Wed, Apr 14, 2010 at 2:44 PM, Jason Dagit
da...@codersbase.commailto:da...@codersbase.com wrote:
On Wed, Apr 14, 2010 at 2:13 PM, Gregory Collins
g...@gregorycollins.netmailto:g...@gregorycollins.net wrote:
Jesper Louis Andersen
jesper.louis.ander...@gmail.commailto:jesper.louis.ander...@gmail.com
writes:
This post describes some odd behaviour I have seen in GHC 6.12.1 when writing
Combinatorrent. The post is literate Haskell so you can run it. The executive
summary: A space leak occurs when a new process is spawned from inside another
process - and I can't figure out why. I am asking for help on haskell-cafe.
...[snip]...
import Control.Monad.State
Does the problem go away if you use Control.Monad.State.Strict?
Nope :) That was the first thing I tried here.
I tried playing with optimization level too.
Next I tried making two versions that were as similar as possible and then
comparing the core with ghc-core. I can't see a difference between a version
that uses 1MB and a version that uses 160MB (on my system 160MB is the worst I
can get it to blow up).
The two versions I compared:
Low memory:
\begin{code}
startp4 :: IO ThreadId
startp4 = spawn () () (return ())
startp3 :: IO ThreadId
startp3 = spawn () () (forever $
do liftIO startp4
liftIO $ putStrLn Delaying
liftIO $ threadDelay (3 * 100))
main1 = do
putStrLn Main thread starting
startp3
threadDelay (1 * 100)
main = main1
\end{code}
Too much memory:
\begin{code}
startp4 :: IO ThreadId
startp4 = spawn () () (forever $ return ())
startp3 :: IO ThreadId
startp3 = spawn () () (forever $
do liftIO startp4
liftIO $ putStrLn Delaying
liftIO $ threadDelay (3 * 100))
main1 = do
putStrLn Main thread starting
startp3
threadDelay (1 * 100)
main = main1
\end{code}
The difference is whether or not the threads must keep returning () or if they
returns it once.
I'm not sure what to make of it. My conclusion is that keeping the thread
alive via forever is the problem, but when I test this hypothesis with a
threadDelay the space leak goes away:
\begin{code}
startp4 :: IO ThreadId
startp4 = spawn () () (liftIO $ threadDelay (100 * 100))
startp3 :: IO ThreadId
startp3 = spawn () () (forever $
do liftIO startp4
liftIO $ putStrLn Delaying
liftIO $ threadDelay (3 * 100))
main1 = do
putStrLn Main thread starting
startp3
threadDelay (1 * 100)
main = main1
\end{code}
It will be interesting to hear what fixes this!
forever' m = do _ - m
forever' m
When I define that version of forever, the space leak goes away.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] RE: No warning in GHC
[Redirecting to haskell-cafe] Try http://www.haskell.org/ghc/docs/latest/html/users_guide/flag-reference.html#id2959068 With -Wall I get bash-3.2$ ghc -c -Wall Foo.hs Foo.hs:3:0: Warning: Definition but no type signature for `func' Inferred type: func :: forall t t1. (Num t1) = t - t1 Foo.hs:3:5: Warning: Defined but not used: `x' Foo.hs:4:10: Warning: This binding for `x' shadows the existing binding bound at Foo.hs:3:5 | -Original Message- | From: cvs-ghc-boun...@haskell.org [mailto:cvs-ghc-boun...@haskell.org] On Behalf Of | Grigory Sarnitskiy | Sent: 21 March 2010 19:37 | To: cvs-...@haskell.org | Subject: No warning in GHC | | Hello! I wonder, why GHC shows no warning in situations like | | func x = x | where x = 5 | | Sometimes I forget about argument names used, and use the same names in let or where. | And it can take me quite a lot time to understand what is wrong. I think it would be | nice to warn users if the argument is redefined in let/where clause. Shall I report | a bug/feature request? I'm using ghc 6.10.4. | | btw, I couldn't post to IRC: #ghc :Cannot send to channel | | ___ | Cvs-ghc mailing list | cvs-...@haskell.org | http://www.haskell.org/mailman/listinfo/cvs-ghc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] generalized newtype deriving allows the definition of otherwise undefinable functions
| some time ago, it was pointed out that generalized newtype deriving could be | used to circumvent module borders. Now, I found out that generalized newtype | deriving can even be used to define functions that would be impossible to define | otherwise. To me, this is surprising since I thought that generalized newtype | deriving was only intended to save the programmer from writing boilerplate | code, not to extend expressiveness. Yes indeed. See http://hackage.haskell.org/trac/ghc/ticket/1496 for why this is really a bug in general. The trouble described there really happens when 'item' (in your iso class) in instantiated to a data type with a constructor whose fields use type functions. Stephanie Weirich, Steve Zdancewic, Dimitrios Vytiniotis and I have been working hard on a development of the FC intermediate language, and hence of the source language, that will close this (embarrassing) loophole, and allow some new expressiveness. Nothing written down in a form that someone other than us can make sense of, but there will be! In brief, though, we're going to end up with kinds looking like * = * as well as the existing * - * The new form means a type-indexed function whereas the latter means a type-parametric function. John Meacham's example is also very interesting. Even if the data type doesn't use type functions, it might have invariants concerning type classes (his example is Set), and converting all the elements might destroy the invariants. Excellent point! There's no type-soundness issue (no run-time seg fault) but something nearly as bad. Will have to think about that. Probably declaring Set to have kind (* = *) will do the job. Thanks for the thread. Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Haskell platform for GHC 6.12.1?
See http://trac.haskell.org/haskell-platform/wiki/ReleaseTimetable The Haskell Platform for GHC 6.12 should be out on March 21st. Simon | -Original Message- | From: haskell-cafe-boun...@haskell.org [mailto:haskell-cafe-boun...@haskell.org] On | Behalf Of Peter Verswyvelen | Sent: 04 March 2010 09:38 | To: The Haskell Cafe | Subject: [Haskell-cafe] Haskell platform for GHC 6.12.1? | | Using GHC 6.12.1 on Windows currently is hard, since one must compile | the latest version of cabal-install, which is a nightmare to do for a | typical windows user (install mingw, msys, utils like wget, download | correct package from hackage, compile them in correct order, etc etc) | | What's the status of the Haskell platform for the latest and greatest | Glasgow Haskell Compiler? | ___ | Haskell-Cafe mailing list | Haskell-Cafe@haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] View patterns
| However, as somebody pointed out, the Java version is polymorphic.
| Assuming that length() is defined for multiple types of container, the
| Java version works with lists, arrays, sets, etc. If you try to do this
| in Haskell, you end up with
A standard way to do it would be this:
class ListLike c where
lcase :: c a - LCase a (c a)
lcons :: a - c a - c a
lnil :: c a
data LCase a b = LNil | LCons a b
f :: ListLike c = c (c Int) - Int
f (lcase - LCons (lcase - LCons x (lcase - LNil))
(lcase - LCons (lcase - LCons y (lcase - LCons _ (lcase - LNil)))
(lcase - LNil)))
= x+y
Simon
| -Original Message-
| From: haskell-cafe-boun...@haskell.org
[mailto:haskell-cafe-boun...@haskell.org] On
| Behalf Of Andrew Coppin
| Sent: 27 February 2010 18:11
| To: haskell-cafe@haskell.org
| Subject: [Haskell-cafe] View patterns
|
| One somewhat neat thing about Haskell is that you can say
|
| case list of
| [[x], [y,_], [z,_,_]] - x + y + z
| _ - 0
|
| In Java, you'd have to write something like
|
| if (list.length() == 3)
| {
| List t1 = list.at(0);
| if (t1.length() == 1)
| {
| int x = t1.at(0);
| List t2 = list.at(1);
| if (t2.length() == 2)
| ...
|
| I can't even be bothered to finish typing all that lot!
|
| However, as somebody pointed out, the Java version is polymorphic.
| Assuming that length() is defined for multiple types of container, the
| Java version works with lists, arrays, sets, etc. If you try to do this
| in Haskell, you end up with
|
| case size c of
| 3 -
| case (c ! 0, c ! 1, c ! 2) of
| (xs, ys, zs) | size x == 1 size y == 2 size z == 3 - (xs !
| 0) + (ys ! 0) + (zs ! 0)
| _ - 0
| _ - 0
|
| or similar. Which is shorter than Java, but nowhere near as nice as the
| original list-only version.
|
| Now I was under the impression that view patterns fix this problem,
| but it seems they don't:
|
| case c of
| (size - 3) -
| case (c ! 0, c ! 1, c ! 2) of
| (size - 1, size - 2, size - 3) - (c ! 0 ! 0) + (c ! 1 ! 0) +
| (c ! 2 ! 0)
|
| Any suggestions?
|
| ___
| Haskell-Cafe mailing list
| Haskell-Cafe@haskell.org
| http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Non-termination due to context
It's a feature!
You have
* B is a superclass of A
* Eq is a superclass of B
So every A dictionary has a B dictionary inside it, and every B dictionary has
an Eq dictionary inside it.
Now, your instance declaration
instance (A a, Eq a) = B a
says if you give me an A dictionary and an Eq dictionary, I'll make you a B
dictionary.
Now, 'test' needs a (B Int) dictionary. To get one, we need an (A Int)
dictionary and an (Eq Int) dictionary. But
when solving these sub-problems, GHC assumes that you
have in hand a solution to the original problem, this case (B Int)
Why? Read the SYB3 paper.
OK so now you see the problem: we can solve the (A Int) and (Eq Int)
sub-problems by selection from the (B Int) dictionary.
Still, I confess that I have not fully grokked the relationship between the
SYB3-style recursion stuff and the question of superclasses. So I will think
about your example some more, thank you.
Meanwhile, it's clear that you are on thin ice.
Simon
| -Original Message-
| From: haskell-cafe-boun...@haskell.org
[mailto:haskell-cafe-boun...@haskell.org] On
| Behalf Of Emil Axelsson
| Sent: 22 January 2010 11:25
| To: Haskell Cafe
| Subject: [Haskell-cafe] Non-termination due to context
|
| Hello all!
|
| Consider the following program:
|
| {-# LANGUAGE FlexibleInstances, OverlappingInstances, UndecidableInstances
#-}
|
| class B a = A a
|
| instance A Int
|
| class Eq a = B a
|
| instance (A a, Eq a) = B a
|
| eq :: B a = a - a - Bool
| eq = (==)
|
| test = 1 `eq` (2::Int)
|
| (This is a condensed version of a much larger program that I've been
| debugging.)
|
| It compiles just fine, but `test` doesn't terminate (GHCi 6.10.4). If I
| change the context `B a` to `Eq a` for the function `eq`, it terminates.
|
| Although I don't know all the details of the class system, it seems
| unintuitive that I can make a program non-terminating just by changing
| the context of a function (regardless of UndecidableInstances etc.).
|
| Is this a bug or a feature?
|
| / Emil
|
| ___
| Haskell-Cafe mailing list
| Haskell-Cafe@haskell.org
| http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Restrictions on associated types for classes
Hmm. If you have
class (Diff (D f)) = Diff f where
then if I have
f :: Diff f = ...
f = e
then the constraints available for discharging constraints arising from e are
Diff f
Diff (D f)
Diff (D (D f))
Diff (D (D (D f)))
...
That's a lot of constraints.
Simon
| -Original Message-
| From: haskell-cafe-boun...@haskell.org
[mailto:haskell-cafe-boun...@haskell.org] On
| Behalf Of Conor McBride
| Sent: 17 December 2009 14:48
| To: Haskell Cafe
| Subject: Re: [Haskell-cafe] Restrictions on associated types for classes
|
| Hi all
|
| On 17 Dec 2009, at 14:22, Tom Schrijvers wrote:
|
| class MyClass k where
| type AssociatedType k :: *
|
| Is there a way of requiring AssociatedType be of class Eq, say?
|
| Have you tried:
|
| {-# LANGUAGE TypeFamilies #-}
| {-# LANGUAGE FlexibleContexts #-}
|
| class Eq (AssociatedType k) = MyClass k where
| type AssociatedType k :: *
|
| I just got very excited about this. I'm supposed to be
| setting a test, but this is far more interesting. I tried
| this
|
| {-# LANGUAGE TypeFamilies, FlexibleContexts, EmptyDataDecls,
| TypeOperators #-}
|
| module DDD where
|
| class (Diff (D f)) = Diff f where
| type D f
| plug :: D f x - x - f x
|
| newtype K a x = K a deriving Show
|
| data Void
| magic :: Void - a
| magic x = x `seq` error haha
|
| instance Diff (K a) where
| type D (K a) = K Void
| plug (K c) x = magic c
|
| newtype I x = I x deriving Show
|
| instance Diff I where
| type D I = K ()
| plug (K ()) x = I x
|
| data (f :+: g) x = L (f x) | R (g x) deriving Show
|
| instance (Diff f, Diff g) = Diff (f :+: g) where
| type D (f :+: g) = D f :+: D g
| plug (L f') x = L (plug f' x)
| plug (R g') x = R (plug g' x)
|
| data (f :*: g) x = f x : g x deriving Show
|
| instance (Diff f, Diff g) = Diff (f :*: g) where
| type D (f :*: g) = (D f :*: g) :+: (f :*: D g)
| plug (L (f' : g)) x = plug f' x : g
| plug (R (f : g')) x = f : plug g' x
|
| But I got this message
|
| [1 of 1] Compiling DDD ( DDD.lhs, interpreted )
|
| DDD.lhs:5:2:
| Cycle in class declarations (via superclasses):
|DDD.lhs:(5,2)-(7,28): class (Diff (D f)) = Diff f where {
| type family D f; }
| Failed, modules loaded: none.
|
| and now I have to go back to setting my class test.
|
| Sorry for spam
|
| Conor
|
| ___
| Haskell-Cafe mailing list
| Haskell-Cafe@haskell.org
| http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Restrictions on associated types for classes
| Hmm. If you have |class (Diff (D f)) = Diff f where | | then if I have | f :: Diff f = ... | f = e | then the constraints available for discharging constraints arising | from e are | Diff f | Diff (D f) | Diff (D (D f)) | Diff (D (D (D f))) | ... | | That's a lot of constraints. | | But isn't it a bit like having an instance | |Diff f = Diff (D f) A little bit. And indeed, could you not provide such instances? That is, every time you write an equation for D, such as type D (K a) = K Void make sure that Diff (K Void) also holds. The way you it, when you call f :: Diff f = blah, you are obliged to pass runtime evidence that (Diff f) holds. And that runtime evidence includes as a sub-component runtime evidence that (Diff (D f)) holds. If you like the, the evidence for Diff f looks like this: data Diff f = MkDiff (Diff (D f)) (D f x - x - f x) So you are going to have to build an infinite data structure. You can do that fine in Haskell, but type inference looks jolly hard. For example, suppose we are seeking evidence for Diff (K ()) We might get such evidence from either a) using the instance decl instance Diff (K a) where ... or b) using the fact that (D I) ~ K (), we need Diff I, so we could use the instance instance Diff I Having two ways to get the evidence seems quite dodgy to me, even apart from the fact that I have no clue how to do type inference for it. Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] When are undecidables ok?
I don’t think it’s all that complicated or fragile. To resolve the constraint (C T1 T2), use the appropriate instance declaration to express it in terms of (hopefully simpler) constraints. Keep doing that. If you terminate, GHC should. Example: to resolve Eq [Int], use the instance declaration instance Eq a = Eq [a] That gives rise to the new constraint Eq Int. Use the instance declaration instance Eq Int That gives rise to no new instances. Done. If you terminate and GHC does not, write down your reasoning (ie how you resolved the instance) and send it in. [NB: There is a wrinkle for “recursive dictionaries”, described in the SYB3 paper.] Simon Well, the reasoning for the devil camp (which I admit to being firmly in[1]) is that such proofs must rely on the algorithm the compiler uses to resolve instances. You might be able to prove it, but the proof is necessarily only valid for (possibly current versions of) GHC. The typeclass resolution algorithm is not in the report, and there are several conceivable ways of of going about it. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Monomorphic local let bindings and GHCi
| So I think that if local let generalisation is abandoned, let bindings in GHCi | would somehow have to be modified to remain polymorphic. I agree. They are like top-level bindings in a Haskell module, and should be generalised. They don't suffer from the problems of generalising nested bindings. Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Is Haskell a Fanatic?
Friends One of the absolutely best things about the Haskell community is that it is almost invariably respectful and usually friendly. People often remark on this when they join the community. Beginner questions are greeted with polite and helpful replies. Category theory and elementary type errors show up in successive messages. Etc. But thread is an exception. If you think someone is talking nonsense, I think the best policy is to ignore it or reply privately (not to the list); then the thread dies. I find derogatory discussion of a particular person quite discouraging. It is likely to be unjust, and it encourages more of the same. It's like littering your own house. Respect, guys, please. Simon | This troll was, apparently, invited by one of the Simons | onto the Haskell' list, then asked to move his spiels here. | | I am informed that the invitation I was referring to was actually | about his being invited *out*, not in, so his origin is still a | mystery and troll is likely appropriate. (I can't say he's | demonstrated much of a mathematical basis for his trollery; only a | propensity for pompous declarations, and deflection when challenged on | them. Put up or shut up, troll.) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Type synonym family inside type class
I agree this is wrong. I've created a Trac bug report http://hackage.haskell.org/trac/ghc/ticket/3714 Thanks for pointing it out Simon | -Original Message- | From: haskell-cafe-boun...@haskell.org [mailto:haskell-cafe- | boun...@haskell.org] On Behalf Of Martijn van Steenbergen | Sent: 27 November 2009 10:35 | To: Haskell Cafe | Subject: [Haskell-cafe] Type synonym family inside type class | | Hello, | | I have a type family and a type class: | | type family ErrorAlg (f :: (* - *) - * - *) e ix :: * | | class MkErrorAlg f where |mkErrorAlg :: ErrorAlg f e a - f (K0 a) ix - Either e a | | Instances for these two really go hand in hand, so I thought I would | move the type family into the type class. However, this causes GHC to | complain about the type variables that are bound on the LHS of the type | synonym: | | Not in scope: type variable `e' | Not in scope: type variable `ix' | | In function types, using new type variables (i.e. type variables not | bound by the type class header) implicitly means universal | quantification over these variables. Why is this disallowed in type | families inside type classes? | | Thanks, | | Martijn. | ___ | Haskell-Cafe mailing list | Haskell-Cafe@haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Pointfree rank-2 typed function
| Are there workarounds for uses of impredicative types, or do we lose the | ability to express certain programs as a result? There's usually a workaround. I include the msg I sent below. Simon -Original Message- From: Simon Peyton-Jones Sent: 30 October 2009 09:52 To: GHC users Cc: Dimitrios Vytiniotis Subject: GHC 6.12.1 and impredicative polymorphism Friends One more update about GHC 6.12, concerning impredicative polymorphism. GHC has had an experimental implementation of impredicative polymorphism for a year or two now (flag -XImpredicativePolymorphism). But a) The implementation is ridiculously complicated, and the complexity is pervasive (in the type checker) rather than localized. I'm very unhappy about this, especially as we add more stuff to the type checker for type families. b) The specification (type system) is well-defined [1], but is also pretty complicated, and it's just too hard to predict which programs will typecheck and which will not. So it's time for a re-think. I propose to deprecate it in 6.12, and remove it altogether in 6.14. We may by then have something else to put in its place. (There is no lack of candidates [2,3,4]!) Fortunately, I don't think a lot of people use the feature in anger. Please yell if you *are* using impredicative polymorphism for something serious. But if you are, we need to think of a workaround. The current situation seems unsustainable. Simon [1] http://research.microsoft.com/en-us/um/people/simonpj/papers/boxy/ [2] http://research.microsoft.com/en-us/um/people/crusso/qml/ [3] http://research.microsoft.com/en-us/um/people/daan/pubs.html [4] http://gallium.inria.fr/~remy/mlf/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Pointfree rank-2 typed function
It used to be, because GHC used to implement so-called deep skolemisation.
See Section 4.6.2 of
http://research.microsoft.com/en-us/um/people/simonpj/papers/higher-rank/putting.pdf
Deep skolemisation was an unfortunate casualty of the push to add impredicative
polymoprhism. However, as I mentioned in an earlier email, I'm currently
planning to take impredicative polymorphism *out*, which means that deep
skolemisation might come back *in*.
Simon
| -Original Message-
| From: haskell-cafe-boun...@haskell.org
[mailto:haskell-cafe-boun...@haskell.org] On
| Behalf Of Bas van Dijk
| Sent: 24 November 2009 13:34
| To: Haskell Cafe
| Subject: [Haskell-cafe] Pointfree rank-2 typed function
|
| Hello,
|
| Given this program:
|
|
| {-# LANGUAGE Rank2Types #-}
|
| newtype Region s a = Region a
|
| unRegion :: forall a s. Region s a - a
| unRegion (Region x) = x
|
| runRegionPointfull :: forall a. (forall s. Region s a) - a
| runRegionPointfull r = unRegion r
|
|
| Is it possible to write the rank-2 typed function 'runRegionPointfull'
| in pointfree style?
|
| Unfortunately the following doesn't typecheck:
|
| runRegionPointfree :: forall a. (forall s. Region s a) - a
| runRegionPointfree = unRegion
|
| Couldn't match expected type `forall s. Region s a'
|against inferred type `Region s a1'
| In the expression: unRegion
| In the definition of `runRegionPointfree':
| runRegionPointfree = unRegion
|
| Why can't the typechecker match `forall s. Region s a' and `Region s a1'?
|
| Thanks,
|
| Bas
| ___
| Haskell-Cafe mailing list
| Haskell-Cafe@haskell.org
| http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Status of TypeDirectedNameResolution proposal?
|* General Type Directed Name Resolution (GTDNR): |For every function application f x in the program where f is a |name, f is resolved based on the type of the argument x. | ... | You suggest that GTDNR might not be a good idea, well why not? One | reason is that it can potentially lead to a whole lot of guessing, | slowing the compiler down dramatically and maybe even so much guessing | that there are multiple whole-program resolutions (oh noes!). So how can | we control that combinatorial exploration of alternatives? One way would | be to restrict the places where we allow guessing. There's still | potential room for combinatorial explosions but they're greatly reduced, | both because we reduce the number of variables in the problem (so the | combinatorics are smaller), and because we (generally) will have a good | deal of non-variable context to anchor the disambiguation process and | hopefully resolve the variables easily. Yes. I'm confident that GTDNR is not viable. The TDNR proposal is carefully constrained to give a uni-directional information flow from the record field to select the function. I don't think that the vastly more general idea you propose is going to work when combined with ordinary HM type inference, type classes, type functions, etc etc. Of course, I could be wrong. Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Status of TypeDirectedNameResolution proposal?
| The proposal has this sentence, apparently in reference to using | qualified imports: This is sufficient, but it is just sufficiently | inconvenient that people don't use it much. Does this mean qualified | imports? I clarified. | One thing I'd really like that this would provide is shorter record | selection. b.color is a lot nicer than Button.btn_color b. Or | would it? It seems like under a TDNR scheme to be able to write | b.color I'd have to either import color explicitly or go over to | the unqualified import world. Good qn. I added a subsection Qualified imports to discuss. | I don't really want to do the latter, | but I also wouldn't want to maintain explicit import lists. Also, as | far as I can see this doesn't provide is nice record update syntax. | If I can write b.color I want to be able to write b2 = b.color := | red! Yes, well see Record syntax. Might be doable. | I think this will also lead to either lots of name shadowing warnings | or more trouble picking variable names. The short perspicuous names | this allows are also the most convenient for local variables. I don't | want to suddenly not be able to use a 'color' variable name because | some record has a 'color' field. A record system (and OO languages) | would have no trouble with 'let color = b.color' but as far as I can | see TDNR would have a problem. Good point. I added a subsection Top-level disambiguation only | So as far as records, TDNR doesn't seem too satisfactory. I think these points are all addressable, more or less as OO languages do, as mentioned above. Thanks for the suggestions Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Status of TypeDirectedNameResolution proposal?
| Simon, have you given any thought to how this interacts with type system | extensions, in particular with GADTs and type families? The proposal relies | on being able to find the type of a term but it's not entirely clear to me | what that means. Here is an example: | | foo :: F Int - Int | foo :: Int - Int | | bar1 :: Int - Int | bar1 = foo | | bar2 :: Int ~ F Int = Int - Int | bar2 = foo | | IIUC, bar1 is ok but bar2 isn't. Do we realy want to have such a strong | dependency between name lookup and type inference? Can name lookup be | specified properly without also having to specify the entire inference | algorithm? Yes I think it can, although you are right to point out that I said nothing about type inference. One minor thing is that you've misunderstood the proposal a bit. It ONLY springs into action when there's a dot. So you'd have to write bar1 x = x.foo bar2 x = x.foo OK so now it works rather like type functions. Suppose, the types with which foo was in scope were foo :: Int - Int foo :: Bool - Char Now imagine that we had a weird kind of type function type instance TDNR_foo Int = Int - Int type instance TDNR_foo Bool = Bool - Char Each 'foo' gives a type instance for TDNR_foo, mapping the type of the first argument to the type of that foo. So when we see (x.foo) we produce the following constraints TDNR_foo tx ~ tx - tr where x:tx and the result type is tr. Then we can solve at our leisure. We can't make progress until we know 'tx', but when we do we can choose which foo is used. Of course, there'd be some modest built-in machinery rather than a forest of Now you rightly ask what if foo :: F Int - Int Now under my type function analogy, we'd get type instance TDNR_foo (F Int) = F Int - Int and now we may be in trouble because type functions can't have a type function call in an argument pattern. I hadn't thought of that. The obvious thing to do is to *refrain* from adding a type instance for such a 'foo'. But that would be a bit odd, because it would silently mean that some 'foo's (the ones whose first argument involved type functions) just didn't participate in TDNR at all. But we can hardly emit a warning message for every function with a type function in the first argument! I suppose that if you use x.foo, we could warn if any in-scope foo's have this property, saying you might have meant one of these, but I can't even consider them. GADTs, on the other hand, are no problem. | Another example: suppose we have | | data T a where | TInt :: T Int | TBool :: T Bool | | foo :: T Int - u | foo :: T Bool - u | | bar :: T a - u | bar x = case x of | TInt - foo x | TBool - foo x | | Here, (foo x) calls different functions in the two alternatives, right? To be | honest, that's not something I'd like to see in Haskell. You mean x.foo and x.foo, right? Then yes, certainly. Of course that's already true of type classes: data T a where T1 :: Show a = T a T2 :: Sow a = T a bar :: a - T a - String bar x y = case y of T1 - show x T2 - show x Then I get different show's. Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Status of TypeDirectedNameResolution proposal?
It's always tempting to spend a lot of time on syntax, but in this case it may be justified. Syntactic brevity is a good part of the point of TDNR. And I'm on a train which is a good time to argue about syntax. Personally I think there are strong advantages to .: * For record selectors, currently written (x r), writing r.x is exactly right * For these unary operators, r.x really does mean (abstractly) select the x field from r * And that is the way that . is used for modules: M.x means select the x function from module M * You can think of qualified names for modules in the same way Control.Monad means pick the Monad module from the Control group. * It culturally fits with the way . is used on OO languages What is the disadvantage? Well, Haskell already uses . for composition. But * . is already special. If you write M.x you mean a qualified name, not the composition of data constructor M with function x I merely propose to make it even special-er! I'll keep quiet about syntax now. Simon | -Original Message- | From: haskell-cafe-boun...@haskell.org [mailto:haskell-cafe- | boun...@haskell.org] On Behalf Of wren ng thornton | Sent: 18 November 2009 03:07 | To: Haskell Cafe | Subject: Re: [Haskell-cafe] Status of TypeDirectedNameResolution proposal? | | Neil Brown wrote: | Having skimmed the page, it seems like the re-use of . is one of the | major difficulties of the proposal. Would it be possible to use -? | It has been used for accessing members in C and C++, so it is not too | unusual a choice. | | It's also the one that Perl went with. | | | It is already special in Haskell so it wouldn't break | anyone's code -- but do its other uses (case statements and lambdas) | mean that it would cause problems in the grammar if re-used for TDNR? | | Given the other uses of - in Haskell, I'm hesitant to suggest it | either. I seem to recall # is the option used by OCaml and a few other | functional-OO languages. So far as I know -XMagicHash is the only thing | that would conflict with that name so it seems far less invasive than . | or -. Another option would be to use @ which is currently forbidden in | expressions, though that might cause issues with System F/Core. | | -- | Live well, | ~wren | ___ | Haskell-Cafe mailing list | Haskell-Cafe@haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Status of TypeDirectedNameResolution proposal?
| Each 'foo' gives a type instance for TDNR_foo, mapping the type of the first | argument to the type of that foo. | | Hmm... GHC doesn't allow this: | | type instance TDNR_foo () = forall a. () - a - a | | IIUC this restriction is necessary to guarantee termination. Given your analogy, | wouldn't this proposal run into similar problems? Maybe so. Of course I don't propose to *really* make a type function; just a new form of constraint. I am not sure of the details. But I'm disinclined to work it through unless there's a solid consensus in favour of doing something, and I do not yet sense such a consensus. My nose tells me that the typing questions will not be a blocker. | Of course that's already true of type classes: | | data T a where | T1 :: Show a = T a |T2 :: Show a = T a | |bar :: a - T a - String |bar x y = case y of |T1 - show x |T2 - show x | | Then I get different show's. | | How so? Surely you'll get the same Show instance in both cases unless you have | conflicting instances in your program? T1 and T2 both bind a local (Show a) dictionary. I suppose you could argue that they must be the same, yes. But anyway, the original TDNR thing is perfectly well defined. It might occasionally be surprising. But that doesn't stop the OO folk from loving it. S ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Status of TypeDirectedNameResolution proposal?
| What's the status of the TDNR proposal [1]? Personally I think it is a | very good idea and I'd like to see it in Haskell'/GHC rather sooner | than later. Working around the limitations of the current record | system is one of my biggest pain points in Haskell and TDNR would be a | major improvement. Thus I wonder if someone is actively working on | this proposal? It's stalled. As far as I know, there's been very little discussion about it. It's not a trivial thing to implement, and it treads on delicate territory (how . is treated). So I'd need to be convinced there was a strong constituency who really wanted it before adding it. I've added an informal straw poll to the bottom of [1] to allow you to express an opinion. Also I'm not very happy with the stacking operations part, and I'd like a better idea. Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
FW: [Haskell-cafe] Status of TypeDirectedNameResolution proposal?
[Resending, this time with link; sorry] | What's the status of the TDNR proposal [1]? Personally I think it is a | very good idea and I'd like to see it in Haskell'/GHC rather sooner | than later. Working around the limitations of the current record | system is one of my biggest pain points in Haskell and TDNR would be a | major improvement. Thus I wonder if someone is actively working on | this proposal? It's stalled. As far as I know, there's been very little discussion about it. It's not a trivial thing to implement, and it treads on delicate territory (how . is treated). So I'd need to be convinced there was a strong constituency who really wanted it before adding it. I've added an informal straw poll to the bottom of [1] to allow you to express an opinion. Also I'm not very happy with the stacking operations part, and I'd like a better idea. Simon [1] http://hackage.haskell.org/trac/haskell-prime/wiki/TypeDirectedNameResolution ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Status of TypeDirectedNameResolution proposal?
Sigh. Apologies. Turns out that [1] is not publicly editable. So I've created a HaskellWiki page [2] and cross-linked them. [2] http://haskell.org/haskellwiki/TypeDirectedNameResolution You should be able to edit that! Simon | -Original Message- | From: haskell-cafe-boun...@haskell.org [mailto:haskell-cafe-boun...@haskell.org] On | Behalf Of Luke Palmer | Sent: 17 November 2009 17:08 | To: Simon Peyton-Jones | Cc: Levi Greenspan; Haskell Cafe | Subject: Re: [Haskell-cafe] Status of TypeDirectedNameResolution proposal? | | On Tue, Nov 17, 2009 at 5:18 AM, Simon Peyton-Jones | simo...@microsoft.com wrote: | | What's the status of the TDNR proposal [1]? Personally I think it is a | | very good idea and I'd like to see it in Haskell'/GHC rather sooner | | than later. Working around the limitations of the current record | | system is one of my biggest pain points in Haskell and TDNR would be a | | major improvement. Thus I wonder if someone is actively working on | | this proposal? | | It's stalled. As far as I know, there's been very little discussion about it. | It's not a trivial thing to implement, and it treads on delicate territory (how . | is treated). So I'd need to be convinced there was a strong constituency who really | wanted it before adding it. | | I've added an informal straw poll to the bottom of [1] to allow you to express an | opinion. | | And how I love expressing my opinion :-P. I would if only I could | figure out how to edit the page! Am I being dense? (Yes, I am logged | in) | | Luke | | Also I'm not very happy with the stacking operations part, and I'd like a better | idea. | | Simon | | | ___ | Haskell-Cafe mailing list | Haskell-Cafe@haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe | | | ___ | Haskell-Cafe mailing list | Haskell-Cafe@haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] The weirdest error I've ever seen...
It's not a bad error message -- it's a crash, and that should never happen. Ideally, boil down the program to something small that still exhibits the crash, and submit that. Perhaps just the newtype declaration alone, with supporting definitions for ContextMatch etc? Try removing unnecessary stuff, to get it as small as possible. Thanks Simon | -Original Message- | From: haskell-cafe-boun...@haskell.org [mailto:haskell-cafe-boun...@haskell.org] On | Behalf Of Joe Fredette | Sent: 12 November 2009 18:12 | To: Joe Fredette | Cc: Simon Peyton-Jones; Haskell Cafè | Subject: Re: [Haskell-cafe] The weirdest error I've ever seen... | | Actually, I just solved the problem... I think... | | In my original code, I had the newtype: | | |newtype FilterState t = Filter t a = Filter (ContextMatch t a) |deriving (Functor, Monad, MonadReader Email, MonadState Bool, | MonadIO) | | I was trying to confirm that it actually was the `deriving ... | MonadState Bool ...` part that was causing the problem, and then I | realized, it's not `MonadState Bool` I want, it's `MonadState t`. | | Upon changing that, everything compiles fine and ghc hums along happily. | | Should I still submit a bug report for a bad error message? | | /Joe | | On Nov 12, 2009, at 12:58 PM, Joe Fredette wrote: | | Okay, so -- I feel totally awesome -- I never found a GHC bug | before... and a Haskell Celebrity responded to my post! *swoons* :) | | Serious question now, There's a fair amount of definitely irrelevant | code (like the definition of the `Email` type, etc), should I post | that in the report too (assuming it doesn't work in 6.12 or I can't | get 6.12 working to try it)? | | Thanks, | | /Joe | | On Nov 12, 2009, at 4:07 AM, Simon Peyton-Jones wrote: | | | [1 of 3] Compiling Network.HackMail.Email.ParseEmail ( Network/ | | HackMail/Email/ParseEmail.hs, interpreted ) | | [2 of 3] Compiling Network.HackMail.Email.Email ( Network/HackMail/ | | Email/Email.hs, interpreted ) | | [3 of 3] Compiling Network.HackMail.Filter.Filter ( Network/ | HackMail/ | | Filter/Filter.hs, interpreted ) | | *** Exception: No match in record selector Var.tcTyVarDetails | | This is a bug in GHC without a doubt. | | It's possible that it's fixed in 6.12 -- can you try the release | candidate? If it is not fixed, or if it's too hard for you to try, | can you submit a Trac bug report please? (Include your code, and | instructions for how to reproduce. | | Thanks | | Simon | | | ___ | Haskell-Cafe mailing list | Haskell-Cafe@haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] The weirdest error I've ever seen...
| [1 of 3] Compiling Network.HackMail.Email.ParseEmail ( Network/ | HackMail/Email/ParseEmail.hs, interpreted ) | [2 of 3] Compiling Network.HackMail.Email.Email ( Network/HackMail/ | Email/Email.hs, interpreted ) | [3 of 3] Compiling Network.HackMail.Filter.Filter ( Network/HackMail/ | Filter/Filter.hs, interpreted ) | *** Exception: No match in record selector Var.tcTyVarDetails This is a bug in GHC without a doubt. It's possible that it's fixed in 6.12 -- can you try the release candidate? If it is not fixed, or if it's too hard for you to try, can you submit a Trac bug report please? (Include your code, and instructions for how to reproduce. Thanks Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Bulding a library for C users on OS X
There is some stuff on using the FFI under Collaborative documentation at http://haskell.org/haskellwiki/GHC. The FFI link takes you to http://haskell.org/haskellwiki/GHC/Using_the_FFI It's called collaborative because it's When you solve your problem, can I urge you to update that page (its a wiki) to embody what you have learned? Simon | -Original Message- | From: haskell-cafe-boun...@haskell.org [mailto:haskell-cafe-boun...@haskell.org] On | Behalf Of Chris Eidhof | Sent: 02 November 2009 10:22 | To: Manuel M T Chakravarty | Cc: Haskell Cafe | Subject: Re: [Haskell-cafe] Bulding a library for C users on OS X | | On 2 nov 2009, at 03:30, Manuel M T Chakravarty wrote: | | Chris Eidhof: | I'm trying to call a Haskell function from C, on OS X. There's an | excellent post [1] by Tomáš Janoušek that explains how to do this | on Linux. However, on OS X, it's different. First of all, it looks | like the -no-hs-main flag is ignored, because I get the following | error: | | ghc -O2 --make -no-hs-main -optl '-shared' -optc '- | DMODULE=Test' -o Test.so Test.hs module_init.c | [1 of 1] Compiling Main ( Test.hs, Test.o ) | | Test.hs:1:0: The function `main' is not defined in module `Main''' | | The flag -no-hs-main is a link-time flag that allows you to link | without a main function, but you are getting a compile time error. | It's as if you try to export main, but don't define it. | | Have you had a look at | http://www.haskell.org/ghc/docs/latest/html/users_guide/ffi-ghc.html#foreign-export- | ghc | ? | | | Interesting! I didn't see that section before, thanks a lot. | | -chris | | ___ | Haskell-Cafe mailing list | Haskell-Cafe@haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
