Re: A type checker plugin for row types
Hello Nick,
very nice! Do you have any thoughts on how to use rows in class/type
family declarations (i.e. how do we match on them)? For example, if I was
to use the rows to make up some sort of record, system (i.e. declare `Rec
:: Row -> Type`), how might I define the `Show` instance for `Rec`?
-Iavor
On Mon, Sep 11, 2017 at 12:10 AM Ara Adkins wrote:
> Glad I could be of help! I just gave it a read and that generated core is
> much better than I expected. I’d still have some concerns regarding certain
> uses (e.g. named arguments) having more performance overhead than hoped,
> but at this stage it’s far better than I would’ve initially thought!
>
> Definitely a useful addition to the wiki page.
>
>
> _ara
>
> On 10 Sep 2017, at 23:58, Nicolas Frisby wrote:
>
> Whoops! I forgot about that section of my draft. I added a little blurb
> ("Performance?") Thanks Ara!
>
>
>
> On Sun, Sep 10, 2017 at 3:41 PM Ara Adkins wrote:
>
>> Just given this a read!
>>
>> It looks like you’ve put a fantastic amount of effort into this so far,
>> and I can certainly see how it’s finding its legs! I’m very much looking
>> forward to seeing this develop further. I can definitely foresee some uses
>> for polykinded column types, and the possibility for named arguments is
>> certainly interesting (though I have some concerns about performance —
>> though none are relevant at such an early stage).
>>
>> Unfortunately I don’t think I can answer any of the questions that I
>> spotted on my read-through.
>>
>> Again, I’m looking forward to seeing this develop, and the naming of
>> `coxswain` and `sculls` gave me a giggle.
>>
>> _ara
>>
>> On 10 Sep 2017, at 23:24, Nicolas Frisby
>> wrote:
>>
>> Hi all. I've been spending my free time for the last couple months on a
>> type checker plugin for row types. The free time waxes and wanes; sending
>> an email like this one was my primary goal for the past couple weeks.
>>
>> At the very least, I hoped this project would let me finally get some
>> hands on experience with OutsideIn. And I definitely have. But I've also
>> made more progress than I anticipated, and I think the plugin is starting
>> to have legs!
>>
>> I haven't uploaded the code yet to github -- it's not quite ready to
>> share. But I did do a write up on the dev wiki.
>>
>>
>> https://ghc.haskell.org/trac/ghc/wiki/Plugins/TypeChecker/RowTypes/Coxswain
>>
>> I would really appreciate and questions, comments, and --- boy, oh boy
>> --- answers.
>>
>> I hope to upload within a week or so, and I'll update that wiki page and
>> reply to this email when I do.
>>
>> Thanks very much. -Nick
>>
>> P.S. -- I've CC'd and BCC'd people who I anticipate would be specifically
>> interested in this (e.g. plugins, row types, etc). Please feel free to
>> forward to others that come to mind; I know some inboxes abjectly can't
>> afford default list traffic.
>>
>> P.P.S. -- One hold up for the upload is: which license? I intend to
>> release under BSD3, mainly to match GHC since one ideal scenario would
>> involve being packaged with/integrated into GHC. But my brief recent
>> research suggests that the Apache license might be more conducive to
>> eventual widespread adoption. If you'd be willing to advise or even just
>> refer me to other write ups, please feel free to email me directly or to
>> start a separate thread on a more appropriate distribution list (CC'ing me,
>> please). Thanks again.
>>
>> ___
>> ghc-devs mailing list
>> ghc-devs@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: A type checker plugin for row types
Hi Nick, This is great work, and I look forward to seeing the code once it is ready. I've had a quick glance over your wiki page, and thought I should send you some initial comments, though it deserves deeper attention which I will try to find time to give it. :-) I don't see a reference to Iavor's paper "Improving Haskell Types with SMT" (http://yav.github.io/publications/improving-smt-types.pdf). If you've not come across it, it might give a useful alternative perspective on how plugins work, especially with regard to derived constraints. The following is based on my faulty memory, so apologies if it is out of date or misleading... > When/where exactly do Derived constraints arise? Suppose I have a class with an equality superclass class a ~ b => C a b and a wanted constraint `C alpha Int`, for some touchable variable `alpha`. This leads to a derived constraint `alpha ~ Int` thanks to the superclass (derived means we don't actually need evidence for it in order to build the core term, but solving it might help fill in some touchable variables). Sorry if this is obvious and not exact enough! > When do touchables "naturally" arise in Given constraints? Do you mean "touchable" or "unification variable" here (and elsewhere?). A skolem is always untouchable, but the converse is not true. I think that unification variables can arise in Given constraints, but that they will always be untouchable. Suppose we have defined f :: forall a b . ((a ~ b) => a -> b) -> Int (never mind that it is ambiguous) and consider type-checking the call `f id`. We end up checking `id` against type `a -> b` with given `a ~ b` where `a` and `b` are unification variables. They must be untouchable, however, otherwise we might unify them, which would be wrong. Hope this helps, Adam On 10/09/17 23:24, Nicolas Frisby wrote: > Hi all. I've been spending my free time for the last couple months on a > type checker plugin for row types. The free time waxes and wanes; > sending an email like this one was my primary goal for the past couple > weeks. > > At the very least, I hoped this project would let me finally get some > hands on experience with OutsideIn. And I definitely have. But I've also > made more progress than I anticipated, and I think the plugin is > starting to have legs! > > I haven't uploaded the code yet to github -- it's not quite ready to > share. But I did do a write up on the dev wiki. > > > https://ghc.haskell.org/trac/ghc/wiki/Plugins/TypeChecker/RowTypes/Coxswain > > I would really appreciate and questions, comments, and --- boy, oh boy > --- answers. > > I hope to upload within a week or so, and I'll update that wiki page and > reply to this email when I do. > > Thanks very much. -Nick > > P.S. -- I've CC'd and BCC'd people who I anticipate would be > specifically interested in this (e.g. plugins, row types, etc). Please > feel free to forward to others that come to mind; I know some inboxes > abjectly can't afford default list traffic. > > P.P.S. -- One hold up for the upload is: which license? I intend to > release under BSD3, mainly to match GHC since one ideal scenario would > involve being packaged with/integrated into GHC. But my brief recent > research suggests that the Apache license might be more conducive to > eventual widespread adoption. If you'd be willing to advise or even just > refer me to other write ups, please feel free to email me directly or to > start a separate thread on a more appropriate distribution list (CC'ing > me, please). Thanks again. -- Adam Gundry, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: A type checker plugin for row types
Ah, yes, derived constraints. The mapping to logic I have in my mind is as follows: Given = assumption, used in proofs Wanted = goal, needs proof Derived = implied by assumptions and goals A derived constraint may be used to instantiate touchable unification variables, and guarantees that in doing so we are not loosing any generally. Consider, for example, a wanted: `(x + 5) ~ 8`. From this we can generate a new derived constraint `x ~ 3`, which would allow GHC to instantiate `x` to 3. A derived constraint could also be used to detect that the current set of goals is inconsistent, for example if we got a derived constraint equivalent to False, we would immediately know that the current set of goals has no solution. -Iavor On Mon, Sep 11, 2017, 9:35 AM Adam Gundry wrote: > Hi Nick, > > This is great work, and I look forward to seeing the code once it is > ready. I've had a quick glance over your wiki page, and thought I should > send you some initial comments, though it deserves deeper attention > which I will try to find time to give it. :-) > > I don't see a reference to Iavor's paper "Improving Haskell Types with > SMT" (http://yav.github.io/publications/improving-smt-types.pdf). If > you've not come across it, it might give a useful alternative > perspective on how plugins work, especially with regard to derived > constraints. > > The following is based on my faulty memory, so apologies if it is out of > date or misleading... > > > When/where exactly do Derived constraints arise? > > Suppose I have a class with an equality superclass > > class a ~ b => C a b > > and a wanted constraint `C alpha Int`, for some touchable variable > `alpha`. This leads to a derived constraint `alpha ~ Int` thanks to the > superclass (derived means we don't actually need evidence for it in > order to build the core term, but solving it might help fill in some > touchable variables). Sorry if this is obvious and not exact enough! > > > When do touchables "naturally" arise in Given constraints? > > Do you mean "touchable" or "unification variable" here (and elsewhere?). > A skolem is always untouchable, but the converse is not true. > > I think that unification variables can arise in Given constraints, but > that they will always be untouchable. Suppose we have defined > > f :: forall a b . ((a ~ b) => a -> b) -> Int > > (never mind that it is ambiguous) and consider type-checking the call `f > id`. We end up checking `id` against type `a -> b` with given `a ~ b` > where `a` and `b` are unification variables. They must be untouchable, > however, otherwise we might unify them, which would be wrong. > > Hope this helps, > > Adam > > > On 10/09/17 23:24, Nicolas Frisby wrote: > > Hi all. I've been spending my free time for the last couple months on a > > type checker plugin for row types. The free time waxes and wanes; > > sending an email like this one was my primary goal for the past couple > > weeks. > > > > At the very least, I hoped this project would let me finally get some > > hands on experience with OutsideIn. And I definitely have. But I've also > > made more progress than I anticipated, and I think the plugin is > > starting to have legs! > > > > I haven't uploaded the code yet to github -- it's not quite ready to > > share. But I did do a write up on the dev wiki. > > > > > > > https://ghc.haskell.org/trac/ghc/wiki/Plugins/TypeChecker/RowTypes/Coxswain > > > > I would really appreciate and questions, comments, and --- boy, oh boy > > --- answers. > > > > I hope to upload within a week or so, and I'll update that wiki page and > > reply to this email when I do. > > > > Thanks very much. -Nick > > > > P.S. -- I've CC'd and BCC'd people who I anticipate would be > > specifically interested in this (e.g. plugins, row types, etc). Please > > feel free to forward to others that come to mind; I know some inboxes > > abjectly can't afford default list traffic. > > > > P.P.S. -- One hold up for the upload is: which license? I intend to > > release under BSD3, mainly to match GHC since one ideal scenario would > > involve being packaged with/integrated into GHC. But my brief recent > > research suggests that the Apache license might be more conducive to > > eventual widespread adoption. If you'd be willing to advise or even just > > refer me to other write ups, please feel free to email me directly or to > > start a separate thread on a more appropriate distribution list (CC'ing > > me, please). Thanks again. > > > -- > Adam Gundry, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com/ > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: GHC Threads affinity
On 10 September 2017 at 04:03, Michael Baikov wrote: > Greetings > > > Currently GHC supports two kinds of threads - pinned to a specific > capability (bound threads) and those it can migrate between any > capabilities (unbound threads). For purposes of achieving lower latency in > Haskell applications it would be nice to have something in between - > threads GHC can migrate but within a certain subset of capabilities only. > That's not correct actually: a bound thread is associated with a particular OS thread, but it can migrate between capabilities just like unbound threads. > I'm developing a program that contains several kinds of threads - those > that do little work and sensitive to latency and those that can spend more > CPU time and less latency sensitive. I looked into several cases of > increased latency in those sensitive threads (using GHC eventlog) and in > all cases sensitive threads were waiting for non-sensitive threads to > finish working. I was able to reduce worst case latency by factor of 10 by > pinning all the threads in the program to specific capability but manually > distributing threads (60+ of them) between capabilities (several different > machines with different numbers of cores available) seems very fragile. > World stopping GC is still a problem but at least in my case is much less > frequently so. > If you have a fixed set of threads you might just want to use -N -qn, and then pin every thread to a different capability. This gives you 1:1 scheduling at the GHC level, delegating the scheduling job to the OS. You will also want to use nursery chunks with something like -n2m, so you don't waste too much nursery space on the idle capabilities. Even if your set of threads isn't fixed you might be able to use a hybrid scheme with -N -qn and pin the high-priority threads on their own capability, while putting all the low-priority threads on a single capability, or a few separate ones. It would be nice to be able to allow GHC runtime to migrate a thread > between a subset of capabilities using interface similar to this one: > > -- creates a thread that is allowed to migrate between capabilities > according to following rule: ghc is allowed to run this thread on Nth > capability if Nth `mod` size_of_word bit in mask is set. > forkOn' :: Int -> IO () -> IO ThreadId > forkOn' mask act = undefined > > This should allow to define up to 64 (32) distinct groups and allow user > to break down their threads into bigger number of potentially intersecting > groups by specifying things like capability 0 does latency sensitive > things, caps 1..5 - less sensitive things, caps 6-7 bulk things. > We could do this, but it would add some complexity to the scheduler and load balancer (which has already been quite hard to get right, I fixed a handful of bugs there recently). I'd be happy review a patch if you want to try it though. Cheers Simon Anything obvious I'm missing? Any recommendations to how to implement this? > > > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: GHC Threads affinity
>> I'm developing a program that contains several kinds of threads - those that do little work and sensitive to latency and those that can spend more CPU time and less latency sensitive. I looked into several cases of increased latency in those sensitive threads (using GHC eventlog) and in all cases sensitive threads were waiting for non-sensitive threads to finish working. I was able to reduce worst case latency by factor of 10 by pinning all the threads in the program to specific capability but manually distributing threads (60+ of them) between capabilities (several different machines with different numbers of cores available) seems very fragile. World stopping GC is still a problem but at least in my case is much less frequently so. > > If you have a fixed set of threads you might just want to use -N -qn, and then pin every thread to a different capability. This gives you 1:1 scheduling at the GHC level, delegating the scheduling job to the OS. You will also want to use nursery chunks with something like -n2m, so you don't waste too much nursery space on the idle capabilities. > > Even if your set of threads isn't fixed you might be able to use a hybrid scheme with -N -qn and pin the high-priority threads on their own capability, while putting all the low-priority threads on a single capability, or a few separate ones. There's about 80 threads right now and some of them are very short lived. Most of them are low priority and require lots of CPU which means having to manually distribute them over several capabilities - this process I'd like to avoid. >> It would be nice to be able to allow GHC runtime to migrate a thread between a subset of capabilities using interface similar to this one: >> >> -- creates a thread that is allowed to migrate between capabilities according to following rule: ghc is allowed to run this thread on Nth capability if Nth `mod` size_of_word bit in mask is set. >> forkOn' :: Int -> IO () -> IO ThreadId >> forkOn' mask act = undefined >> >> This should allow to define up to 64 (32) distinct groups and allow user to break down their threads into bigger number of potentially intersecting groups by specifying things like capability 0 does latency sensitive things, caps 1..5 - less sensitive things, caps 6-7 bulk things. > > > We could do this, but it would add some complexity to the scheduler and load balancer (which has already been quite hard to get right, I fixed a handful of bugs there recently). I'd be happy review a patch if you want to try it though. I guess I'll start by studying the scheduler and load balancer in more details. Thank you for your input Simon! ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Feedback request regarding HSOC project (bringing sanity to the GHC performance test-suite)
Hi Phyx, Sorry for the late reply. I already implemented a wait and retry approach since it seemed the most sensible. Let me see if I can clear this up a bit. Suppose you want to check out a new branch and work on a feature. You check out that branch, run the testsuite once (using ONLY_PERFORMANCE_TESTS=YES if you just want to populate the performance test comparison data). Every commit you would ideally run the testsuite again, although you don't have to. Let's say you finish up your new feature in 10 commits and you ran the testsuite in each commit; you can use the comparison tool across all 10 commits to track performance changes over the development of the feature. But if you only ran the performance testsuite once before you started coding the feature, you could run the testsuite again after you're finished and then use the comparison tool using the last and first commit as data-points. If you forgot to run the performance testsuite at all you can always check out the first commit and run it on there and then check the branch back out and compare from the HEAD. While the notes will not be pushed, if you create a branch from your branch, the notes will copy over. They will also not be deleted ever (although they are tied to their respective commit hashes so a rebase will "remove them" as it changes the commit hashes; however you can manually copy over the notes from the "old hash" to the "new hash" if you want to--the data is not lost ever). As such, long time GHC developers will eventually build up a very long and respectable data-set that will be almost as comprehensive as the data-set that the CI builders will develop. Your local history of performance tests will be as perfect as you want it to be since it doesn't really matter for the CI story. Does that clarify things regarding the local story? -- Now, on the CI side of things... You are right that performance is very platform specific. In fact, due to the very platform specific nature of performance testing, it's just really ridiculously hard to come up with a "perfect" way to normalize scores and have some way to push numbers somewhere to be referenced. So, as far as I can see, the only really sensible approach is to only consider numbers gathered by "that" computer relative to each other (as performance is something that is inherently relative to some perspective). This means that, yes, if there is not a CI running tests for that OS then automated performance regression testing will suffer a bit; however, if there is not a CI running tests for that OS then that OS is not being tested *at all* and the lack of accurate performance regression testing is the least of GHC's concerns. The way I see it is that performance can only truthfully be tracked on platforms it's actually measured on. Further, *correctness* of the compiler can only truthfully be tracked on platforms that it's being tested on; if no CI or builder exists for OSX or Windows at all, then the entire concept of measuring performance is already moot; how can one evaluate a comparison that never happened? This change should make things much easier as regressions can be very tightly tracked on every platform that the testsuite is regularly ran on. Right now, Linux is the only platform that the tests are regularly run on; it is a lie to continue to pretend that the testsuite is fully functional on Windows (it is not) and on OSX (it is not)--in an environment where "clean test run" means "same amount of broken tests as there used to be", any performance metric would just be a lie. I'd even go so far as to say that if any builder is broken at all, the performance has ceased to be measured in any meaningful way and that all of the numbers that exist inside the current testsuite are basically meaningless for OSX and Windows and only *barely* useful for Linux. On the other hand, information gathered from Linux can now be used to tightly control performance regressions in GHC for Linux; since Linux is the only platform being tested regularly right now, it's an overall vast improvement since any tight regression control is better than none. Once a regular CI builder is constructed for OSX and one is constructed for Windows, the situation will improve by leaps and bounds--entirely for free. I look forward to your thoughts, Jared On Wed, Sep 6, 2017 at 11:44 PM, Phyx wrote: > Hi Jared, > > > On Tue, Sep 5, 2017, 19:39 Jared Weakly wrote: >> >> Hi Tamar, >> >> That framework failure is due to a somewhat embarrassing error that I >> thought I had caught earlier; line 298 shouldn't have existed (it was >> a small mistake from converting the all.T file from using the old >> function to using the new collect_stats function. I have fixed this >> and it will be pushed by the time you read this email. That being >> said, the individual tests or units are very isolated and a framework >> failure simply means that unit didn't get run; in this case it means >> that entire all.T f
Re: A type checker plugin for row types
Adam, thanks for: 1) The reference to Iavor's paper --- it is a nice more-detailed description of the plugin API/semantics, and the Nelson-Oppen parallel is very illuminating! 2) Asking "Do you mean "touchable" or "unification variable" here and elsewhere?" That prompted me to finally dig deeper into something, and I've updated/simplified the wiki page accordingly. Basically, I was just using newFlexiTyVar (since it's pretty much the only option in the "official" TcPluginsM interface) without understanding if it's the touchability or the skolem-vs-unification status that was enabling the Given-Given interactions. I'm happy to report that touchability apparently has nothing to do with any of my test cases (including the record and variant library, etc). I'm relieved about that: touchability is a restriction on unification, and my general goal with my plugin architecture is to leave as many of the unification details to GHC's type equality solver as possible. Thanks. -Nick On Mon, Sep 11, 2017 at 1:34 AM Adam Gundry wrote: > Hi Nick, > > This is great work, and I look forward to seeing the code once it is > ready. I've had a quick glance over your wiki page, and thought I should > send you some initial comments, though it deserves deeper attention > which I will try to find time to give it. :-) > > I don't see a reference to Iavor's paper "Improving Haskell Types with > SMT" (http://yav.github.io/publications/improving-smt-types.pdf). If > you've not come across it, it might give a useful alternative > perspective on how plugins work, especially with regard to derived > constraints. > > The following is based on my faulty memory, so apologies if it is out of > date or misleading... > > > When/where exactly do Derived constraints arise? > > Suppose I have a class with an equality superclass > > class a ~ b => C a b > > and a wanted constraint `C alpha Int`, for some touchable variable > `alpha`. This leads to a derived constraint `alpha ~ Int` thanks to the > superclass (derived means we don't actually need evidence for it in > order to build the core term, but solving it might help fill in some > touchable variables). Sorry if this is obvious and not exact enough! > > > When do touchables "naturally" arise in Given constraints? > > Do you mean "touchable" or "unification variable" here (and elsewhere?). > A skolem is always untouchable, but the converse is not true. > > I think that unification variables can arise in Given constraints, but > that they will always be untouchable. Suppose we have defined > > f :: forall a b . ((a ~ b) => a -> b) -> Int > > (never mind that it is ambiguous) and consider type-checking the call `f > id`. We end up checking `id` against type `a -> b` with given `a ~ b` > where `a` and `b` are unification variables. They must be untouchable, > however, otherwise we might unify them, which would be wrong. > > Hope this helps, > > Adam > > > On 10/09/17 23:24, Nicolas Frisby wrote: > > Hi all. I've been spending my free time for the last couple months on a > > type checker plugin for row types. The free time waxes and wanes; > > sending an email like this one was my primary goal for the past couple > > weeks. > > > > At the very least, I hoped this project would let me finally get some > > hands on experience with OutsideIn. And I definitely have. But I've also > > made more progress than I anticipated, and I think the plugin is > > starting to have legs! > > > > I haven't uploaded the code yet to github -- it's not quite ready to > > share. But I did do a write up on the dev wiki. > > > > > > > https://ghc.haskell.org/trac/ghc/wiki/Plugins/TypeChecker/RowTypes/Coxswain > > > > I would really appreciate and questions, comments, and --- boy, oh boy > > --- answers. > > > > I hope to upload within a week or so, and I'll update that wiki page and > > reply to this email when I do. > > > > Thanks very much. -Nick > > > > P.S. -- I've CC'd and BCC'd people who I anticipate would be > > specifically interested in this (e.g. plugins, row types, etc). Please > > feel free to forward to others that come to mind; I know some inboxes > > abjectly can't afford default list traffic. > > > > P.P.S. -- One hold up for the upload is: which license? I intend to > > release under BSD3, mainly to match GHC since one ideal scenario would > > involve being packaged with/integrated into GHC. But my brief recent > > research suggests that the Apache license might be more conducive to > > eventual widespread adoption. If you'd be willing to advise or even just > > refer me to other write ups, please feel free to email me directly or to > > start a separate thread on a more appropriate distribution list (CC'ing > > me, please). Thanks again. > > > -- > Adam Gundry, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com/ > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Semigroup repeat (base package)
Am Montag, den 11.09.2017, 06:55 +0530 schrieb Harendra Kumar: > On 11 September 2017 at 02:46, Wolfgang Jeltsch wrote: > > Am Sonntag, den 10.09.2017, 10:39 +0200 schrieb Herbert Valerio > > Riedel: > > > What you seem to be searching for looks more like what we know as > > > `cycle :: [a] -> [a]`, and in fact there is its generalisation at > > > > > > http://hackage.haskell.org/package/base-4.10.0.0/docs/Data-Semigroup.html#v:cycle1 > > > > Why is this function called cycle1, not cycle? What does the “1” > > stand for? > > I guess this is not named "cycle" to avoid conflict with > "Data.List.cycle". Why? We have qualified imports. It seems very wrong to add single characters to identifiers to denote name spaces. > I was also wondering why it is "cycle1" instead of, say "scycle". It > can be thought of as cycling just one value instead of cycling a list > in case of "Data.List.cycle". Also Data.List.cycle cycles only one value. It is just that this single value happens to be a list. If you specialize cycle1 to the list monoid, you get exactly Data.List.cycle. All the best, Wolfgang ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: A type checker plugin for row types
On September 11, 2017 9:34:15 AM GMT+01:00, Adam Gundry wrote: >Hi Nick, > >This is great work, and I look forward to seeing the code once it is >ready. I've had a quick glance over your wiki page, and thought I >should >send you some initial comments, though it deserves deeper attention >which I will try to find time to give it. :-) > >I don't see a reference to Iavor's paper "Improving Haskell Types with >SMT" (http://yav.github.io/publications/improving-smt-types.pdf). If >you've not come across it, it might give a useful alternative >perspective on how plugins work, especially with regard to derived >constraints. > >The following is based on my faulty memory, so apologies if it is out >of >date or misleading... > >> When/where exactly do Derived constraints arise? > >Suppose I have a class with an equality superclass > >class a ~ b => C a b > >and a wanted constraint `C alpha Int`, for some touchable variable >`alpha`. This leads to a derived constraint `alpha ~ Int` thanks to the >superclass (derived means we don't actually need evidence for it in >order to build the core term, but solving it might help fill in some >touchable variables). Sorry if this is obvious and not exact enough! > >> When do touchables "naturally" arise in Given constraints? > >Do you mean "touchable" or "unification variable" here (and >elsewhere?). >A skolem is always untouchable, but the converse is not true. > >I think that unification variables can arise in Given constraints, but >that they will always be untouchable. Suppose we have defined > >f :: forall a b . ((a ~ b) => a -> b) -> Int > >(never mind that it is ambiguous) and consider type-checking the call >`f >id`. We end up checking `id` against type `a -> b` with given `a ~ b` >where `a` and `b` are unification variables. They must be untouchable, >however, otherwise we might unify them, which would be wrong. > >Hope this helps, > >Adam > > >On 10/09/17 23:24, Nicolas Frisby wrote: >> Hi all. I've been spending my free time for the last couple months on >a >> type checker plugin for row types. The free time waxes and wanes; >> sending an email like this one was my primary goal for the past >couple >> weeks. >> >> At the very least, I hoped this project would let me finally get some >> hands on experience with OutsideIn. And I definitely have. But I've >also >> made more progress than I anticipated, and I think the plugin is >> starting to have legs! >> >> I haven't uploaded the code yet to github -- it's not quite ready to >> share. But I did do a write up on the dev wiki. >> >> >> >https://ghc.haskell.org/trac/ghc/wiki/Plugins/TypeChecker/RowTypes/Coxswain >> >> I would really appreciate and questions, comments, and --- boy, oh >boy >> --- answers. >> >> I hope to upload within a week or so, and I'll update that wiki page >and >> reply to this email when I do. >> >> Thanks very much. -Nick >> >> P.S. -- I've CC'd and BCC'd people who I anticipate would be >> specifically interested in this (e.g. plugins, row types, etc). >Please >> feel free to forward to others that come to mind; I know some inboxes >> abjectly can't afford default list traffic. >> >> P.P.S. -- One hold up for the upload is: which license? I intend to >> release under BSD3, mainly to match GHC since one ideal scenario >would >> involve being packaged with/integrated into GHC. But my brief recent >> research suggests that the Apache license might be more conducive to >> eventual widespread adoption. If you'd be willing to advise or even >just >> refer me to other write ups, please feel free to email me directly or >to >> start a separate thread on a more appropriate distribution list >(CC'ing >> me, please). Thanks again. > > >-- >Adam Gundry, Haskell Consultant >Well-Typed LLP, http://www.well-typed.com/ >___ >ghc-devs mailing list >ghc-devs@haskell.org >http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs It would be great if someone could extract the conclusion of this thread into a Note. Clearly there is a hole in the current state of our source documentation. Cheers, - Ben ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
