RE: backward compatibility
| So, again, for this particular extension I suggest that the layout | rule in the standard(s) should be revised Indeed I suspect the NonDecreasingIndentation change is a proposal for Haskell Prime pocess. Or if it isn't it could be is if someone proposed it. That's the process we have in place for changing the base language. Simon | -Original Message- | From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell- | users-boun...@haskell.org] On Behalf Of Axel Simon | Sent: 20 January 2011 20:23 | To: Simon Marlow | Cc: GHC users | Subject: Re: backward compatibility | | Hi Simon, | | On Jan 20, 2011, at 17:54, Simon Marlow wrote: | | The layout fix is this change: | | | http://hackage.haskell.org/trac/ghc/changeset/9a82b1ffa35fa4c3927c66a1037a37d | 436cf6aac | | Another case where GHC was not strictly standards-compliant, and it | was fixed by adding a flag for the extension. | | | These were all bugs, but fixing them broke some code, | unfortunately. In cases like this we *could* deprecate the | behaviour for one major release with a warning, before removing it. | However there's a non-trivial cost to doing so, and in some of these | cases it would have been quite awkward to implement the warning | (plus the cost of adding tests to make sure we actually got the | warning right; it's easy to introduce yet more bugs). Furthermore, | deprecations are often ignored, so sometimes the breakage is just | delayed. | | Hopefully that explains why sometimes we make breaking changes. If | the breaking change has a high enough impact, then it becomes | worthwhile to add backwards compatibility (via warnings / | deprecation or whatever). Of course from the point of view of the | user, the impact is always either high (it broke) or zero (it | didn't) :-) We have to make a judgement as to whether we should | spend effort on backwards compatibility or not. Perhaps we're | getting it wrong - so feedback from users is always valuable. | | I appreciate that you want to make ghc compliant to the standard. But | to be honest, it is still the case that ghc defines the de-facto | standard of what a Haskell program can be, since many programs do | employ one or more ghc-only extensions. | | In the case of the layout bug, I think it might be worth considering | going the other way: adjusting the standard with what ghc has always | done. If I understand correctly, all my code using: | | foo = do |some computation |trace I am here $ do |some more computation | | will break. I use this style of coding a lot to avoid too much | indentation and thus I would have to enable this extension everywhere | (and get warnings (or errors?) for older ghcs). Even if we had 2 or 3 | implementations of Haskell 2010 in a decade, then they might not have | this extension. Furthermore, if they claim they actually do implement | the layout extension then they still might get it wrong in some subtle | way. An extension is never as well exercised as the non-extension part | of the compiler. I therefore think that keeping the number of | extensions to a minimum should be a high priority. It seems that the | ghc team is going overboard with the amount of extensions and their | granularity that I do not believe that there will ever be another | compiler since implementing all these extensions is a nightmare. The | road of may extensions is leading down the road that the Haskell | standards aimed to avoid: having a single implementation defining what | a Haskell program can be. | | So, again, for this particular extension I suggest that the layout | rule in the standard(s) should be revised -- if I'm mistaken, this | will not break other programs. | | Cheers, | Axel | | | ___ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: backward compatibility
On 21.01.2011, at 09:10, Simon Peyton-Jones wrote: | So, again, for this particular extension I suggest that the layout | rule in the standard(s) should be revised Indeed I suspect the NonDecreasingIndentation change is a proposal for Haskell Prime pocess. Or if it isn't it could be is if someone proposed it. That's the process we have in place for changing the base language. I have proposed to incorporate this extension into the Haskell standard. Axel Simon | -Original Message- | From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell- | users-boun...@haskell.org] On Behalf Of Axel Simon | Sent: 20 January 2011 20:23 | To: Simon Marlow | Cc: GHC users | Subject: Re: backward compatibility | | Hi Simon, | | On Jan 20, 2011, at 17:54, Simon Marlow wrote: | | The layout fix is this change: | | | http://hackage.haskell.org/trac/ghc/changeset/9a82b1ffa35fa4c3927c66a1037a37d | 436cf6aac | | Another case where GHC was not strictly standards-compliant, and it | was fixed by adding a flag for the extension. | | | These were all bugs, but fixing them broke some code, | unfortunately. In cases like this we *could* deprecate the | behaviour for one major release with a warning, before removing it. | However there's a non-trivial cost to doing so, and in some of these | cases it would have been quite awkward to implement the warning | (plus the cost of adding tests to make sure we actually got the | warning right; it's easy to introduce yet more bugs). Furthermore, | deprecations are often ignored, so sometimes the breakage is just | delayed. | | Hopefully that explains why sometimes we make breaking changes. If | the breaking change has a high enough impact, then it becomes | worthwhile to add backwards compatibility (via warnings / | deprecation or whatever). Of course from the point of view of the | user, the impact is always either high (it broke) or zero (it | didn't) :-) We have to make a judgement as to whether we should | spend effort on backwards compatibility or not. Perhaps we're | getting it wrong - so feedback from users is always valuable. | | I appreciate that you want to make ghc compliant to the standard. But | to be honest, it is still the case that ghc defines the de-facto | standard of what a Haskell program can be, since many programs do | employ one or more ghc-only extensions. | | In the case of the layout bug, I think it might be worth considering | going the other way: adjusting the standard with what ghc has always | done. If I understand correctly, all my code using: | | foo = do |some computation |trace I am here $ do |some more computation | | will break. I use this style of coding a lot to avoid too much | indentation and thus I would have to enable this extension everywhere | (and get warnings (or errors?) for older ghcs). Even if we had 2 or 3 | implementations of Haskell 2010 in a decade, then they might not have | this extension. Furthermore, if they claim they actually do implement | the layout extension then they still might get it wrong in some subtle | way. An extension is never as well exercised as the non-extension part | of the compiler. I therefore think that keeping the number of | extensions to a minimum should be a high priority. It seems that the | ghc team is going overboard with the amount of extensions and their | granularity that I do not believe that there will ever be another | compiler since implementing all these extensions is a nightmare. The | road of may extensions is leading down the road that the Haskell | standards aimed to avoid: having a single implementation defining what | a Haskell program can be. | | So, again, for this particular extension I suggest that the layout | rule in the standard(s) should be revised -- if I'm mistaken, this | will not break other programs. | | Cheers, | Axel | | | ___ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Release/git plans
Austin | So, given that 7.2 will be released much earlier than the normal | release cycle, is there any room for anything else to get into HEAD | for the 7.2 release before everything is switched? In particular I | fixed up Max Bolingbroke's old compiler plugin work to be usable with | the latest HEAD, and all the fundamental work is there and done, just | some additional small things are needed (notably having ghc dump | plugin information a la -ddump flags, and testsuite patches are about | it I think.) The patch itself is pretty small and doesn't touch *too* | much code, mostly adding dynamic loading and the plugin API, but it's | arguably adding a 'big' feature for users of GHC to start utilizing, | and perhaps a release in 7.2 would cause problems merging changes | until you cut a new STABLE branch with git, like you said. I'm sorry I've been slow on this. Review and apply the plugins patch is in my inbox, but it's been queued up behind too many other things, notably making the new typechecker work. I'm pretty keen on the whole plugin idea, because it makes the compiler more extensible and lowers the barrier to entry. My only reason for delay is that I wanted to review the design (as seen by a plug-in author). Once we provide it, we have to support it, and it's harder to change. The fact that you are actively engaged, have done the work with Max, and are (I assume) happy to respond to user queries, fix bugs etc, is a major incentive. Thank you! So yes, because of that I undertake to do this for 7.2 [unless Simon M tells me no :-)]. I'll add a few thoughts to the ticket right now. http://hackage.haskell.org/trac/ghc/ticket/3843. Interested parties, add yourselves to the cc list of the ticket. Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: backward compatibility
On 20/01/2011 20:22, Axel Simon wrote: In the case of the layout bug, I think it might be worth considering going the other way: adjusting the standard with what ghc has always done. If I understand correctly, all my code using: foo = do some computation trace I am here $ do some more computation will break. I use this style of coding a lot to avoid too much indentation and thus I would have to enable this extension everywhere (and get warnings (or errors?) for older ghcs). Even if we had 2 or 3 implementations of Haskell 2010 in a decade, then they might not have this extension. Furthermore, if they claim they actually do implement the layout extension then they still might get it wrong in some subtle way. An extension is never as well exercised as the non-extension part of the compiler. I therefore think that keeping the number of extensions to a minimum should be a high priority. It seems that the ghc team is going overboard with the amount of extensions and their granularity that I do not believe that there will ever be another compiler since implementing all these extensions is a nightmare. The road of may extensions is leading down the road that the Haskell standards aimed to avoid: having a single implementation defining what a Haskell program can be. So, again, for this particular extension I suggest that the layout rule in the standard(s) should be revised -- if I'm mistaken, this will not break other programs. You've convinced me. The benefit from fixing GHC in this case is outweighed by the cost, I think we should revert the change (or at least enable RelaxedLayout by default), and propose the change for Haskell 2011/2012. Ian, Simon, what do you think? Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: backward compatibility
| You've convinced me. The benefit from fixing GHC in this case is | outweighed by the cost, I think we should revert the change (or at least | enable RelaxedLayout by default), and propose the change for Haskell | 2011/2012. Ian, Simon, what do you think? I'm ok with that ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Release/git plans
On 21 January 2011 09:13, Simon Peyton-Jones simo...@microsoft.com wrote: I'm pretty keen on the whole plugin idea, because it makes the compiler more extensible and lowers the barrier to entry. My only reason for delay is that I wanted to review the design (as seen by a plug-in author). Once we provide it, we have to support it, and it's harder to change. The Scala compiler has a plugin system. Here's a document that describes their approach to dealing with phase ordering of plugins: http://www.scala-lang.org/sid/2. It seems rather complex, but seems necessary (or the document is just very long). There's also a tutorial on writing Scala plugins, which may help to get a feel for how their API works. http://www.scala-lang.org/node/140 / Thomas ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Cleaning up after the Close button is pressed
On 20/01/2011 05:27, Colin Hume wrote: Hi everyone, I posted previously on haskell-beginners about an issue which would have been better directed to this list. Since then, I have revisited the issue and am now even less certain of its cause. I have to perform cleanup when my application terminates. GHC.ConsoleHandler handles cleanup from Ctrl-C and Ctrl-Break very nicely under Windows. My sample handler and main function are shown at [1]. When I press Ctrl-C and Ctrl-Break during threadDelay, messages are written to console_event.log as I expected. When I press the Close button during threadDelay, no message is written to console_event.log. Am I missing something fundamental about handling the Close button or installing handlers? In case it makes a difference, I'm using GHC 6.12.3 under Windows XP. I don't know a great deal about this, but if you think it might be a bug please report it at http://hackage.haskell.org/trac/ghc/newticket?type=bug giving as much information as you can. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: backward compatibility
On Fri, Jan 21, 2011 at 10:18:57AM +, Simon Marlow wrote: On 20/01/2011 20:22, Axel Simon wrote: So, again, for this particular extension I suggest that the layout rule in the standard(s) should be revised -- if I'm mistaken, this will not break other programs. You've convinced me. The benefit from fixing GHC in this case is outweighed by the cost, I think we should revert the change (or at least enable RelaxedLayout by default), and propose the change for Haskell 2011/2012. Ian, Simon, what do you think? You mean NondecreasingIndentation, right? (RelaxedLayout only makes a difference with explicit braces). NondecreasingIndentation is already on by default; are you suggesting we also add it to Haskell98 and Haskell2010? Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] Splittable random numbers
Hi cafe, I want to add the ability to use AES-NI instructions on Intel architectures to GHC. Mainly I'd like to do splittable random number generators based on AES as was suggested at the outset of this email. (I met Burton Smith last week and this topic came up.) I was just reading the below thread about the plugin architecture which got me thinking about what the right way to add AES-NI is. (Disregarding for a moment portability and the issue of where to test cpuid...) http://www.haskell.org/pipermail/glasgow-haskell-users/2011-January/019874.html The FFI is always an option. But after reading the first N pages I could come across from google I'm still not totally clear on whether unsafe foreign calls can happen simultaneously from separate Haskell threads (and with sufficiently low overhead for this purpose). I also ran across the phrase compiler primitive somewhere wrt GHC: http://hackage.haskell.org/trac/ghc/wiki/AddingNewPrimitiveOperations Is that the right way to go? Or would the compiler plugin mechanism possibly allowing doing this without modifying mainline GHC? Thanks, -Ryan On Fri, Nov 12, 2010 at 6:26 PM, wren ng thornton w...@freegeek.org wrote: On 11/12/10 5:33 AM, Richard Senington wrote: It does not give the results you would want. This may have something to do with picking good parameters for the mkLehmerTree function. For example, using a random setup, I just got these results result expected range 16.814 expected = 16.0 (1,31) 16.191 expected = 16.5 (1,32) 16.576 expected = 17.0 (1,33) 17.081 expected = 17.5 (1,34) 17.543 expected = 18.0 (1,35) Have you run any significance tests? I wouldn't be surprised to see +/-0.5 as within the bounds of expected randomness. I'm more worried about it seeming to be consistently on the -0.5 end of things, than I am about it not matching expectation (how many samples did you take again?). For small ranges like this, a consistent -0.5 (or +0.5) tends to indicate off-by-one errors in the generator. -- Live well, ~wren ___ Haskell-Cafe mailing list haskell-c...@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] Splittable random numbers
Ryan, If you make an AES based RNG then consider making an instance for CryptoRandomGen (see DRBG [1] for example instances). Such an instance means you can use splitGen [2], which can split generators in the manner described in this thread. If you make the RNG match NIST SP 800-90 then feel free to send it to me for inclusion in the DRBG package, I've been meaning to make the block cipher based DRBG for a while now. Finally, any implementation of AES (using NI or not) could probably go in its own package or a cipher-specific package like CryptoCipher[3]. Its a shame we don't have an AES implementation on Hackage that 1) exposes the fundamental block interface instead of some higher-level wrapping and 2) isn't tied to a large library. Cheers, Thomas [1] http://hackage.haskell.org/package/DRBG and http://hackage.haskell.org/packages/archive/DRBG/0.1.2/doc/html/src/Crypto-Random-DRBG.html#HmacDRBG [2] http://hackage.haskell.org/packages/archive/crypto-api/0.3.1/doc/html/Crypto-Random.html#v:splitGen [3] http://hackage.haskell.org/package/cryptocipher On Fri, Jan 21, 2011 at 2:19 PM, Ryan Newton rrnew...@gmail.com wrote: Hi cafe, I want to add the ability to use AES-NI instructions on Intel architectures to GHC. Mainly I'd like to do splittable random number generators based on AES as was suggested at the outset of this email. (I met Burton Smith last week and this topic came up.) I was just reading the below thread about the plugin architecture which got me thinking about what the right way to add AES-NI is. (Disregarding for a moment portability and the issue of where to test cpuid...) http://www.haskell.org/pipermail/glasgow-haskell-users/2011-January/019874.html The FFI is always an option. But after reading the first N pages I could come across from google I'm still not totally clear on whether unsafe foreign calls can happen simultaneously from separate Haskell threads (and with sufficiently low overhead for this purpose). I also ran across the phrase compiler primitive somewhere wrt GHC: http://hackage.haskell.org/trac/ghc/wiki/AddingNewPrimitiveOperations Is that the right way to go? Or would the compiler plugin mechanism possibly allowing doing this without modifying mainline GHC? Thanks, -Ryan On Fri, Nov 12, 2010 at 6:26 PM, wren ng thornton w...@freegeek.org wrote: On 11/12/10 5:33 AM, Richard Senington wrote: It does not give the results you would want. This may have something to do with picking good parameters for the mkLehmerTree function. For example, using a random setup, I just got these results result expected range 16.814 expected = 16.0 (1,31) 16.191 expected = 16.5 (1,32) 16.576 expected = 17.0 (1,33) 17.081 expected = 17.5 (1,34) 17.543 expected = 18.0 (1,35) Have you run any significance tests? I wouldn't be surprised to see +/-0.5 as within the bounds of expected randomness. I'm more worried about it seeming to be consistently on the -0.5 end of things, than I am about it not matching expectation (how many samples did you take again?). For small ranges like this, a consistent -0.5 (or +0.5) tends to indicate off-by-one errors in the generator. -- Live well, ~wren ___ Haskell-Cafe mailing list haskell-c...@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Release/git plans
Simon, On Fri, Jan 21, 2011 at 3:13 AM, Simon Peyton-Jones simo...@microsoft.com wrote: Austin | So, given that 7.2 will be released much earlier than the normal | release cycle, is there any room for anything else to get into HEAD | for the 7.2 release before everything is switched? In particular I | fixed up Max Bolingbroke's old compiler plugin work to be usable with | the latest HEAD, and all the fundamental work is there and done, just | some additional small things are needed (notably having ghc dump | plugin information a la -ddump flags, and testsuite patches are about | it I think.) The patch itself is pretty small and doesn't touch *too* | much code, mostly adding dynamic loading and the plugin API, but it's | arguably adding a 'big' feature for users of GHC to start utilizing, | and perhaps a release in 7.2 would cause problems merging changes | until you cut a new STABLE branch with git, like you said. I'm sorry I've been slow on this. Review and apply the plugins patch is in my inbox, but it's been queued up behind too many other things, notably making the new typechecker work. That's fine! One thing at a time. The typechecker overhaul is great IMO, and I've noticed it's fixed many strange GHC bugs relating to type system feature interactions (including a few I hit.) Much appreciated work! I'm pretty keen on the whole plugin idea, because it makes the compiler more extensible and lowers the barrier to entry. My only reason for delay is that I wanted to review the design (as seen by a plug-in author). Once we provide it, we have to support it, and it's harder to change. This is very reasonable and I was going to mention it once someone responded. Up to this point, Max has really been the main person to write any plugins for GHC using the current interface. I would really welcome anybody interested in hacking on GHC look at the current API in the patch - my main concern up to this point is that the actual means of installing passes into the Core pipeline, the installation function of type `[CoreToDo] - CoreM [CoreToDo]`, is a little fragile. Scala's approach seems to be to have plugins specify 'runAfter' and 'runBefore' constraints, which specify what compiler phases should run before and after the plugin's pass in question (and certain phases may run multiple times, so as a consequence, so does your plugin.) If I remember correctly, this was somewhat similar to the original design Max proposed which was to specify in which phase the pass is run, and it essentially amounted to a phase constraint. Perhaps Max can elaborate on why this design was rejected in favor of the current one, so we can see how and where it falls down, and what we really want. Thomas pointed out the Scala compiler plugin design document, so I'll be sure to read over it this weekend when I get the chance to cook up ideas. Also worth noting, like I said, is I would inevitably like to extend compiler plugins to work on Cmm, once the new codegen (using hoopl) hits. Maybe even allow you to write a new backend ultimately if you wanted to, although I'd call that the last and ultimate challenge at this point (because from my cursory glances, it would require quite a bit of re-engineering and re-design of the driver and compilation pipeline, much more so than just the Core plugins did or Cmm plugins might. That's a bit more time than I have... at the moment ;) To accumulate ideas and comments I've spent the past few days writing up a wiki page (mostly written in the wee hours of the morning no less), documenting the current API, how it might be improved, and future work like C-- plugins or plugins implementing new backends. Most of it is half baked. And half-written. Probably grammatical errors and run-on sentences. Incomplete sections. Likely with big, stupid ideas. Caveat emptor, etc. The wiki page in all its (horrid, half-written and mangled) glory can be located here: http://hackage.haskell.org/trac/ghc/wiki/NewPlugins If people can comment and add ideas, it will be much easier to determine if this should go into 7.2.1. If the current API is too fragile or needs to be expanded, it would likely be best to back out and do some work, and try again for 7.4.1. That will also give a much bigger window for feedback and testing, since 7.2 will be on a much shorter cycle it seems. I'll probably end up throwing up a RFC on both glasgow-haskell-users and cvs-ghc sometime in the next week to get feedback after more brainstorming, because it's the most important thing as of right now and for any future work in this area, in my opinion, since it will be a publicly exposed API for users to write code against. The fact that you are actively engaged, have done the work with Max, and are (I assume) happy to respond to user queries, fix bugs etc, is a major incentive. Thank you! I'm more than happy to respond to any user queries and respond to bugs people come up with, yes (Max seems to be working
Re: Release/git plans
Llvm is also a good reference for compiler plugin design; it would appear that Scala borrowed from their approach. -scooter Sent from my Verizon Wireless BlackBerry -Original Message- From: austin seipp a...@hacks.yi.org Sender: glasgow-haskell-users-boun...@haskell.org Date: Fri, 21 Jan 2011 17:59:32 To: Simon Peyton-Jonessimo...@microsoft.com Cc: Simon Marlowmarlo...@gmail.com; glasgow-haskell-users@haskell.orgglasgow-haskell-users@haskell.org Subject: Re: Release/git plans Simon, On Fri, Jan 21, 2011 at 3:13 AM, Simon Peyton-Jones simo...@microsoft.com wrote: Austin | So, given that 7.2 will be released much earlier than the normal | release cycle, is there any room for anything else to get into HEAD | for the 7.2 release before everything is switched? In particular I | fixed up Max Bolingbroke's old compiler plugin work to be usable with | the latest HEAD, and all the fundamental work is there and done, just | some additional small things are needed (notably having ghc dump | plugin information a la -ddump flags, and testsuite patches are about | it I think.) The patch itself is pretty small and doesn't touch *too* | much code, mostly adding dynamic loading and the plugin API, but it's | arguably adding a 'big' feature for users of GHC to start utilizing, | and perhaps a release in 7.2 would cause problems merging changes | until you cut a new STABLE branch with git, like you said. I'm sorry I've been slow on this. Review and apply the plugins patch is in my inbox, but it's been queued up behind too many other things, notably making the new typechecker work. That's fine! One thing at a time. The typechecker overhaul is great IMO, and I've noticed it's fixed many strange GHC bugs relating to type system feature interactions (including a few I hit.) Much appreciated work! I'm pretty keen on the whole plugin idea, because it makes the compiler more extensible and lowers the barrier to entry. My only reason for delay is that I wanted to review the design (as seen by a plug-in author). Once we provide it, we have to support it, and it's harder to change. This is very reasonable and I was going to mention it once someone responded. Up to this point, Max has really been the main person to write any plugins for GHC using the current interface. I would really welcome anybody interested in hacking on GHC look at the current API in the patch - my main concern up to this point is that the actual means of installing passes into the Core pipeline, the installation function of type `[CoreToDo] - CoreM [CoreToDo]`, is a little fragile. Scala's approach seems to be to have plugins specify 'runAfter' and 'runBefore' constraints, which specify what compiler phases should run before and after the plugin's pass in question (and certain phases may run multiple times, so as a consequence, so does your plugin.) If I remember correctly, this was somewhat similar to the original design Max proposed which was to specify in which phase the pass is run, and it essentially amounted to a phase constraint. Perhaps Max can elaborate on why this design was rejected in favor of the current one, so we can see how and where it falls down, and what we really want. Thomas pointed out the Scala compiler plugin design document, so I'll be sure to read over it this weekend when I get the chance to cook up ideas. Also worth noting, like I said, is I would inevitably like to extend compiler plugins to work on Cmm, once the new codegen (using hoopl) hits. Maybe even allow you to write a new backend ultimately if you wanted to, although I'd call that the last and ultimate challenge at this point (because from my cursory glances, it would require quite a bit of re-engineering and re-design of the driver and compilation pipeline, much more so than just the Core plugins did or Cmm plugins might. That's a bit more time than I have... at the moment ;) To accumulate ideas and comments I've spent the past few days writing up a wiki page (mostly written in the wee hours of the morning no less), documenting the current API, how it might be improved, and future work like C-- plugins or plugins implementing new backends. Most of it is half baked. And half-written. Probably grammatical errors and run-on sentences. Incomplete sections. Likely with big, stupid ideas. Caveat emptor, etc. The wiki page in all its (horrid, half-written and mangled) glory can be located here: http://hackage.haskell.org/trac/ghc/wiki/NewPlugins If people can comment and add ideas, it will be much easier to determine if this should go into 7.2.1. If the current API is too fragile or needs to be expanded, it would likely be best to back out and do some work, and try again for 7.4.1. That will also give a much bigger window for feedback and testing, since 7.2 will be on a much shorter cycle it seems. I'll probably end up throwing up a RFC on both glasgow-haskell-users and cvs-ghc sometime in the next week to get feedback after
Re: [Haskell-cafe] Splittable random numbers
I'm not too familiar with all the Haskell API's for RNGs. This is the first time I've looked at CryptoRandomGen, but I can see the benefit of having a bytestring interface rather than the System.Random Int based one. Is there a reason that the AES implementation in the AES or crypto packages can't be ripped out and repackage in the way you would like? Cheers, -Ryan On Fri, Jan 21, 2011 at 6:11 PM, Thomas DuBuisson thomas.dubuis...@gmail.com wrote: Ryan, If you make an AES based RNG then consider making an instance for CryptoRandomGen (see DRBG [1] for example instances). Such an instance means you can use splitGen [2], which can split generators in the manner described in this thread. If you make the RNG match NIST SP 800-90 then feel free to send it to me for inclusion in the DRBG package, I've been meaning to make the block cipher based DRBG for a while now. Finally, any implementation of AES (using NI or not) could probably go in its own package or a cipher-specific package like CryptoCipher[3]. Its a shame we don't have an AES implementation on Hackage that 1) exposes the fundamental block interface instead of some higher-level wrapping and 2) isn't tied to a large library. Cheers, Thomas [1] http://hackage.haskell.org/package/DRBG and http://hackage.haskell.org/packages/archive/DRBG/0.1.2/doc/html/src/Crypto-Random-DRBG.html#HmacDRBG [2] http://hackage.haskell.org/packages/archive/crypto-api/0.3.1/doc/html/Crypto-Random.html#v:splitGen [3] http://hackage.haskell.org/package/cryptocipher On Fri, Jan 21, 2011 at 2:19 PM, Ryan Newton rrnew...@gmail.com wrote: Hi cafe, I want to add the ability to use AES-NI instructions on Intel architectures to GHC. Mainly I'd like to do splittable random number generators based on AES as was suggested at the outset of this email. (I met Burton Smith last week and this topic came up.) I was just reading the below thread about the plugin architecture which got me thinking about what the right way to add AES-NI is. (Disregarding for a moment portability and the issue of where to test cpuid...) http://www.haskell.org/pipermail/glasgow-haskell-users/2011-January/019874.html The FFI is always an option. But after reading the first N pages I could come across from google I'm still not totally clear on whether unsafe foreign calls can happen simultaneously from separate Haskell threads (and with sufficiently low overhead for this purpose). I also ran across the phrase compiler primitive somewhere wrt GHC: http://hackage.haskell.org/trac/ghc/wiki/AddingNewPrimitiveOperations Is that the right way to go? Or would the compiler plugin mechanism possibly allowing doing this without modifying mainline GHC? Thanks, -Ryan On Fri, Nov 12, 2010 at 6:26 PM, wren ng thornton w...@freegeek.org wrote: On 11/12/10 5:33 AM, Richard Senington wrote: It does not give the results you would want. This may have something to do with picking good parameters for the mkLehmerTree function. For example, using a random setup, I just got these results result expected range 16.814 expected = 16.0 (1,31) 16.191 expected = 16.5 (1,32) 16.576 expected = 17.0 (1,33) 17.081 expected = 17.5 (1,34) 17.543 expected = 18.0 (1,35) Have you run any significance tests? I wouldn't be surprised to see +/-0.5 as within the bounds of expected randomness. I'm more worried about it seeming to be consistently on the -0.5 end of things, than I am about it not matching expectation (how many samples did you take again?). For small ranges like this, a consistent -0.5 (or +0.5) tends to indicate off-by-one errors in the generator. -- Live well, ~wren ___ Haskell-Cafe mailing list haskell-c...@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
