From mfdyck at google.com Fri Sep 2 23:11:27 2016 From: mfdyck at google.com (Matthew Farkas-Dyck) Date: Fri, 2 Sep 2016 16:11:27 -0700 Subject: Exposing target language in Haskell with GHC API In-Reply-To: <57BFF61C.8090507@gmail.com> References: <57BFF61C.8090507@gmail.com> Message-ID: Hi, thanks for the response. On 26/08/2016, Christiaan Baaij wrote: > You mentioned that GHC does name mangling, but I must say I've never > seen GHC do this. I guess this was unclear: our compiler is mangling the names from GHC core, lest any clash with a BlueSpec keyword. We need to find a way to annotate the Haskell source to tell our compiler to not mangle a name. > What GHC does do is inlining and specialisation, which might optimise > away your carefully constructed "primitive". > > What I do in this case, is simply mark my "primitive" function, your > "exposed" BlueSpec functions, as NOINLINE. Ah, yes, it seems we will need to do this too. From adam at well-typed.com Mon Sep 5 14:38:50 2016 From: adam at well-typed.com (Adam Gundry) Date: Mon, 5 Sep 2016 15:38:50 +0100 Subject: GHC proposal for OverloadedRecordFields (plus some amendments to OverloadedLabels) Message-ID: <14d79356-c334-b819-00c7-7e93399e8b8d@well-typed.com> Hi GHC users, I've recently posted a slightly revised proposal for the next step in the epic OverloadedRecordFields saga. If you're interested, please read it and give your feedback at: https://github.com/ghc-proposals/ghc-proposals/pull/6 Many thanks, Adam P.S. Apologies for jumping the gun on the GHC proposals process being formally sanctioned. ;-) -- Adam Gundry, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From ben at well-typed.com Mon Sep 5 16:15:03 2016 From: ben at well-typed.com (Ben Gamari) Date: Mon, 05 Sep 2016 12:15:03 -0400 Subject: Call for Nominations: GHC Steering Committee In-Reply-To: <87r39dq76d.fsf@smart-cactus.org> References: <87r39dq76d.fsf@smart-cactus.org> Message-ID: <87wpiqcohk.fsf@smart-cactus.org> Hello everyone, As you likely know, over the last few months we have been discussing options for reforming the process for proposing language and compiler changes to GHC. After much discussion, we have a process [1] which, while not perfect, is acceptable to a majority of our contributor base and will be an improvement over the status quo. While we invite suggestions for future improvements, we are at a point where we can move ahead with implementation. Consequently, we are seeking nominations for the initial GHC steering committee. This body is responsible for overseeing the progression of proposals through the process, working with authors on refining their ideas, and evaluating proposals for acceptance. The committee will consist of five to eight members of diverse backgrounds. We would like to offer the following as a criteria for membership. Note that a candidate is not expected to satisfy all or even most of these criteria, but a good candidate should satisfy at least one: * A history of contributions to the design of new language features * Experience developing Haskell libraries and applications * A demonstrated track record of contributing code to GHC * A pedagogical background, with experience in either teaching or authoring educational materials * Experience in compiler development * Knowledge of functional programming language theory I'd like to emphasize that committee membership is as much a duty as it is a privilege. Membership is not intended to be a platform to be used by members to drive their own ideas; rather it is a way of serving the Haskell community by helping other community members refine and advance their proposals. This, of course, requires an investment of time and effort, which you should be willing and able to consistently put forth. If you'd like to be considered for committee membership then please write a statement describing why you feel you are well-qualified to serve, in terms of the criteria above and any others that you would like to offer. Please send your statements to ben at well-typed.com by September 30th. The initial committee selection will be made by the Simons soon thereafter. Thanks to everyone for their feedback and cooperation so far! Cheers, - Ben [1] http://github.com/ghc-proposals/ghc-proposals -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From Clive.Lee at edifera.com Mon Sep 12 12:53:39 2016 From: Clive.Lee at edifera.com (Clive Lee) Date: Mon, 12 Sep 2016 12:53:39 +0000 Subject: File Type of source code Message-ID: I am a beginner in a mess over file type I wrote a little Haskell source code 6 months ago and returning I find the source files have type Haskell Source File" When I try to store new source code it fails to load either "not found" or "does not contain module or source code" The files all have type Text Document even when I try extension ".hs" The "Save as" in Word or NotePad does not give me the option of Haskell Source File. I've even tried to start with my original files (OK load) but they save as Text Documents and then won't load I'm embarrassed I can't get over first step - I find the user guide a little complicated for a raw beginner and I must miss something in tutorials. Any help appreciated Best regards Clive -------------- next part -------------- An HTML attachment was scrubbed... URL: From jake at requisitebits.com Mon Sep 12 15:20:15 2016 From: jake at requisitebits.com (Jake Mitchell) Date: Mon, 12 Sep 2016 08:20:15 -0700 Subject: File Type of source code In-Reply-To: References: Message-ID: <1473693615.1913092.723162617.51D4D43D@webmail.messagingengine.com> On Mon, Sep 12, 2016, at 05:53 AM, Clive Lee wrote: > I am a beginner in a mess over file type > I wrote a little Haskell source code 6 months ago and returning I find > the source files have type Haskell Source File” > When I try to store new source code it fails to load either “not > found” or “does not contain module or source code” The files all have > type Text Document even when I try extension “.hs” "Text document" has a couple different meanings: (1) a file with a '.txt' extension and (2) a file containing human-readable characters (filed with non-human readable data are called 'binary'). For Haskell source you want the second kind, and not the first. > The “Save as” in Word or NotePad does not give me the option of > Haskell Source File. > I’ve even tried to start with my original files (OK load) but they > save as Text Documents and then won’t load By default Windows hides file extensions and programs often add an extension. Your '.hs' file may actually be a '.hs.txt'. A search for "windows show file extensions" should help you out. Word and NotePad will be fussy about file extensions. You need an editor designed for programming. A good one to start with is NotePad++: https://notepad-plus-plus.org > I’m embarrassed I can’t get over first step – I find the user guide a > little complicated for a raw beginner and I must miss something in > tutorials. We were all beginners once, so no need to be embarrassed. I hope this helps. > Any help appreciated > Best regards > > Clive > _________________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at zednenem.com Fri Sep 23 04:48:22 2016 From: dave at zednenem.com (David Menendez) Date: Fri, 23 Sep 2016 00:48:22 -0400 Subject: Type families in kind signatures with TypeInType Message-ID: Should the code below work in GHC 8.0.1? {-# LANGUAGE TypeInType, TypeFamilies #-} import Data.Kind (Type) type family K t :: Type type family T t :: K t -> Type data List type instance K List = Type type instance T List = [] Right now, I get an error like this one: min.hs:12:24: error: • Expected kind ‘K List -> Type’, but ‘[]’ has kind ‘* -> *’ • In the type ‘[]’ In the type instance declaration for ‘T’ which is puzzling, since K List -> Type and * -> * should be the same. Obviously, TypeInType is experimental and incomplete. I’m just wondering if this sort of thing is expected to work, or if I’m doing something not yet supported or never to be supported In particular, the kind signature for T is forall t -> K t -> Type, which looks like DependentHaskell. -- Dave Menendez -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Fri Sep 23 07:19:32 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 23 Sep 2016 07:19:32 +0000 Subject: Type families in kind signatures with TypeInType In-Reply-To: References: Message-ID: This is an example of https://ghc.haskell.org/trac/ghc/ticket/12088. The “type instance T List” declaration actually depends on the “type instance K List” declaration; the latter must be typechecked before the former. But this dependency is absolutely unclear. There’s a long discussion on the thread. Bottom line: we don’t know a solid automated way to spot this kind of problem, so I think we are going to ask for programmer assistance. In this case, we’d put a “separator” after the “type instance K List” decl, to explain that it must be done first: type instance K List = Type =========== type instance T List = [] Currently you have to write $(return []) to get the separator, but I think we’ll add a special separator. Simon From: Glasgow-haskell-users [mailto:glasgow-haskell-users-bounces at haskell.org] On Behalf Of David Menendez Sent: 23 September 2016 05:48 To: glasgow-haskell-users at haskell.org Mailing List Subject: Type families in kind signatures with TypeInType Should the code below work in GHC 8.0.1? {-# LANGUAGE TypeInType, TypeFamilies #-} import Data.Kind (Type) type family K t :: Type type family T t :: K t -> Type data List type instance K List = Type type instance T List = [] Right now, I get an error like this one: min.hs:12:24: error: • Expected kind ‘K List -> Type’, but ‘[]’ has kind ‘* -> *’ • In the type ‘[]’ In the type instance declaration for ‘T’ which is puzzling, since K List -> Type and * -> * should be the same. Obviously, TypeInType is experimental and incomplete. I’m just wondering if this sort of thing is expected to work, or if I’m doing something not yet supported or never to be supported In particular, the kind signature for T is forall t -> K t -> Type, which looks like DependentHaskell. -- Dave Menendez > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at zednenem.com Fri Sep 23 18:51:23 2016 From: dave at zednenem.com (David Menendez) Date: Fri, 23 Sep 2016 14:51:23 -0400 Subject: Type families in kind signatures with TypeInType In-Reply-To: References: Message-ID: On Fri, Sep 23, 2016 at 3:19 AM, Simon Peyton Jones wrote: > This is an example of https://ghc.haskell.org/trac/ghc/ticket/12088. > Interesting. Is this case also an example, or is it a non-feature? class C t where type K t :: Type type T t :: K t -> Type m :: t -> T t a min.hs:21:17: error: • Type constructor ‘K’ cannot be used here (it is defined and used in the same recursive group) • In the kind ‘K t -> Type’ Failed, modules loaded: none. GHC accepts this if K t is moved outside of C. > The “type instance T List” declaration actually depends on the “type > instance K List” declaration; the latter must be typechecked before the > former. But this dependency is absolutely unclear. There’s a long > discussion on the thread. Bottom line: we don’t know a solid automated way > to spot this kind of problem, so I think we are going to ask for > programmer assistance. In this case, we’d put a “separator” after the > “type instance K List” decl, to explain that it must be done first: > > > > type instance K List = Type > > =========== > > type instance T List = [] > > > > Currently you have to write $(return []) to get the separator, but I think > we’ll add a special separator. > > Yes, this works. Thanks. It would be disappointing if this is the best we can do, but I guess other dependent languages don’t need to deal with open type families and everything being potentially mutually recursive. -- Dave Menendez -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Fri Sep 23 19:00:36 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 23 Sep 2016 19:00:36 +0000 Subject: Type families in kind signatures with TypeInType In-Reply-To: References: Message-ID: Interesting. Is this case also an example, or is it a non-feature? class C t where type K t :: Type type T t :: K t -> Type m :: t -> T t a Ah, that’s quite different! We should do strongly-connected-component analysis of the associated-type declarations within a single class declaration…. but we don’t currently do that. No difficulty in principle, I think. You could open a ticket. (Do include a link to this email thread and to #12088) Simon From: d4ve.menendez at gmail.com [mailto:d4ve.menendez at gmail.com] On Behalf Of David Menendez Sent: 23 September 2016 19:51 To: Simon Peyton Jones Cc: glasgow-haskell-users at haskell.org Mailing List Subject: Re: Type families in kind signatures with TypeInType On Fri, Sep 23, 2016 at 3:19 AM, Simon Peyton Jones > wrote: This is an example of https://ghc.haskell.org/trac/ghc/ticket/12088. Interesting. Is this case also an example, or is it a non-feature? class C t where type K t :: Type type T t :: K t -> Type m :: t -> T t a min.hs:21:17: error: • Type constructor ‘K’ cannot be used here (it is defined and used in the same recursive group) • In the kind ‘K t -> Type’ Failed, modules loaded: none. GHC accepts this if K t is moved outside of C. The “type instance T List” declaration actually depends on the “type instance K List” declaration; the latter must be typechecked before the former. But this dependency is absolutely unclear. There’s a long discussion on the thread. Bottom line: we don’t know a solid automated way to spot this kind of problem, so I think we are going to ask for programmer assistance. In this case, we’d put a “separator” after the “type instance K List” decl, to explain that it must be done first: type instance K List = Type =========== type instance T List = [] Currently you have to write $(return []) to get the separator, but I think we’ll add a special separator. Yes, this works. Thanks. It would be disappointing if this is the best we can do, but I guess other dependent languages don’t need to deal with open type families and everything being potentially mutually recursive. -- Dave Menendez > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at zednenem.com Fri Sep 23 19:19:04 2016 From: dave at zednenem.com (David Menendez) Date: Fri, 23 Sep 2016 15:19:04 -0400 Subject: Type families in kind signatures with TypeInType In-Reply-To: References: Message-ID: On Fri, Sep 23, 2016 at 3:00 PM, Simon Peyton Jones wrote: > Interesting. Is this case also an example, or is it a non-feature? > > > > class C t where > > type K t :: Type > > type T t :: K t -> Type > > > > m :: t -> T t a > > > > > > Ah, that’s quite different! We should do strongly-connected-component > analysis of the associated-type declarations within a single class > declaration…. but we don’t currently do that. No difficulty in principle, > I think. > > > > You could open a ticket. (Do include a link to this email thread and to > #12088) > I’ve opened ticket #12612 . Assuming GHC accepted this definition, would the Template Haskell trick (or whatever replaces it) allow defining instances of C? -- Dave Menendez -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Mon Sep 26 07:59:13 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 26 Sep 2016 07:59:13 +0000 Subject: FW: Getting rid of -XImpredicativeTypes In-Reply-To: References: Message-ID: Friends GHC has a flag -XImpredicativeTypes that makes a half-hearted attempt to support impredicative polymorphism. But it is vestigial…. if it works, it’s really a fluke. We don’t really have a systematic story here at all. I propose, therefore, to remove it entirely. That is, if you use -XImpredicativeTypes, you’ll get a warning that it does nothing (ie. complete no-op) and you should remove it. Before I pull the trigger, does anyone think they are using it in a mission-critical way? Now that we have Visible Type Application there is a workaround: if you want to call a polymorphic function at a polymorphic type, you can explicitly apply it to that type. For example: {-# LANGUAGE ImpredicativeTypes, TypeApplications, RankNTypes #-} module Vta where f x = id @(forall a. a->a) id @Int x You can also leave out the @Int part of course. Currently we have to use -XImpredicativeTypes to allow the @(forall a. a->a). Is that sensible? Or should we allow it regardless? I rather think the latter… if you have Visible Type Application (i.e. -XTypeApplications) then applying to a polytype is nothing special. So I propose to lift that restriction. I should go through the GHC Proposals Process for this, but I’m on a plane, so I’m going to at least start with an email. Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ATT00001.txt URL: From simonpj at microsoft.com Mon Sep 26 08:49:42 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 26 Sep 2016 08:49:42 +0000 Subject: Getting rid of -XImpredicativeTypes In-Reply-To: References: Message-ID: 1) ImpredicativeTypes enables types like `Maybe (forall a. a)`. Do those just disappear, or are they also enabled anyway? (I would guess the former.) Yes, they’d disappear. 2) There was a sketch drawn up around a year ago (I think) aiming to actually fix ImpredicativeTypes. I don't recall who was working on it, but I think when I mentioned it in the context of something else, you didn't seem to be aware of it. I guess it's safe to say that nothing ever came of it, at least inasmuch as no one ever showed you their proposal for a properly functioning ImpredicativeTypes? It’s just a swamp. I have tried multiple times to fix ImpredicativeTypes, and failed every time. Which is not to say that someone shouldn’t try again, with new thinking. Simon From: Dan Doel [mailto:dan.doel at gmail.com] Sent: 26 September 2016 00:54 To: Simon Peyton Jones Cc: ghc-users at haskell.org; ghc-devs at haskell.org Subject: Re: Getting rid of -XImpredicativeTypes I don't use the extension, because it's more pleasant to use newtypes with polymorphic contents. But here are some questions: 1) ImpredicativeTypes enables types like `Maybe (forall a. a)`. Do those just disappear, or are they also enabled anyway? (I would guess the former.) 2) There was a sketch drawn up around a year ago (I think) aiming to actually fix ImpredicativeTypes. I don't recall who was working on it, but I think when I mentioned it in the context of something else, you didn't seem to be aware of it. I guess it's safe to say that nothing ever came of it, at least inasmuch as no one ever showed you their proposal for a properly functioning ImpredicativeTypes? Anyhow, if it can't be fixed, I think not having the extension is superior to its current state. And really, I think even if fixing it were on the roadmap, it'd be better to get rid of it until it were actually fixed. -- Dan On Sun, Sep 25, 2016 at 2:05 PM, Simon Peyton Jones via ghc-devs > wrote: Friends GHC has a flag -XImpredicativeTypes that makes a half-hearted attempt to support impredicative polymorphism. But it is vestigial…. if it works, it’s really a fluke. We don’t really have a systematic story here at all. I propose, therefore, to remove it entirely. That is, if you use -XImpredicativeTypes, you’ll get a warning that it does nothing (ie. complete no-op) and you should remove it. Before I pull the trigger, does anyone think they are using it in a mission-critical way? Now that we have Visible Type Application there is a workaround: if you want to call a polymorphic function at a polymorphic type, you can explicitly apply it to that type. For example: {-# LANGUAGE ImpredicativeTypes, TypeApplications, RankNTypes #-} module Vta where f x = id @(forall a. a->a) id @Int x You can also leave out the @Int part of course. Currently we have to use -XImpredicativeTypes to allow the @(forall a. a->a). Is that sensible? Or should we allow it regardless? I rather think the latter… if you have Visible Type Application (i.e. -XTypeApplications) then applying to a polytype is nothing special. So I propose to lift that restriction. I should go through the GHC Proposals Process for this, but I’m on a plane, so I’m going to at least start with an email. Simon _______________________________________________ ghc-devs mailing list ghc-devs at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: