Re: [Haskell-cafe] GSoC proposal: Units for GHC
This sounds pretty cool and useful. How much of this can be implemented in a library and how much of this would need to be supported on a compiler level? Ideally, most of this would be solved on the library level. Jurriën On 4 Apr 2012, at 13:38, Nils Schweinsberg wrote: Hi Haskell-Cafe GHC-users! I'm looking to apply for the GSoC and since I've worked on GHC before I'd like to continue to do so. My proposal would be something that tempted me (as a physics student) for a while: Units for Haskell/GHC. This project has been suggested for a long time on the GHC wiki, and there is already a lot of work done for other languages like ML, F# etc[1]. I have tried to implement e.g. the unification algorithm from the Types for Units-of-Measure in F# talk[2] for an abstract syntax tree[3] and it was pretty much straight forward. As I see it, the project would consist of: 1.) Find appropriate rules/algorithms for unit analysis. Most (if not all?) of this should be covered in those papers/talks on [1]. 2.) Applying the rules to the Haskell syntax tree used in GHC. I have approximately 3 years of experience with Haskell, I worked for the database research group[4] at the University of Tübingen (Germany) on the Database Supported Haskell[5] library. I've done most of the coding for the monad comprehension[6] extension, which has been added to the latest GHC release version. I'm already quite familiar with the GHC internals of the compiler/typechecker, and even though I'd have to look up how exactly type interference etc. works in GHC (as I've only *used* it, but never tried to understand/modify it) I'm confident that the work on GHC itself should be doable in the given timeframe. So my questions would be: Do you think this is a appropriate GSoC project? What should I include in the application/project proposal? Anything else? Opinions, suggestions? I realize that I'm kind of late and probably should have written this email a long time ago. But there are still 2 days left for the student application and hopefully I'll get some good feedback by then. - Nils [1]: http://research.microsoft.com/en-us/um/people/akenn/units/index.html [2]: http://research.microsoft.com/en-us/um/people/akenn/units/MLWorkshop2008.pdf [3]: https://github.com/mcmaniac/units/blob/master/src/Unification.hs [4]: http://db.inf.uni-tuebingen.de/team [5]: http://hackage.haskell.org/package/DSH [6]: http://db.inf.uni-tuebingen.de/files/giorgidze/haskell2011.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
Re: [Haskell-cafe] GSoC proposal: Units for GHC
Am 04.04.2012 13:48, schrieb Jurriën Stutterheim: This sounds pretty cool and useful. How much of this can be implemented in a library and how much of this would need to be supported on a compiler level? Ideally, most of this would be solved on the library level. The compiler would have to know how to typecheck units, e.g. the addition (+) would combine two values of the same unit, the (/) operation would divide them: (+) :: a - a - a (/) :: a - b - a/b The idea is to have the compiler complain whenever you try to add b to a or if you expect something other than a/b as result from a division. This would require modifications to GHC at compiler level. A library could offer some basic units (SI units for example) and maybe even unit aliases (N = kg*m/s^2), but I don't see how the core of this unit verification system could be placed into a library. - Nils ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GSoC proposal: Units for GHC
Implementing this proposal in GHC, as opposed to the library-only approach, would allow for generation of much more useful and user friendly error messages. I believe this aspect is important when it comes to type systems supporting physical units. Cheers, George This sounds pretty cool and useful. How much of this can be implemented in a library and how much of this would need to be supported on a compiler level? Ideally, most of this would be solved on the library level. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GSoC proposal: Units for GHC
Hi, I don't see any mention here of the dimensional library ( http://hackage.haskell.org/package/dimensional), or its type-family variant --- in order to be a viable proposal you should describe how you would improve on the approach taken there. G On Wed, Apr 4, 2012 at 1:38 PM, Nils Schweinsberg m...@n-sch.de wrote: Hi Haskell-Cafe GHC-users! I'm looking to apply for the GSoC and since I've worked on GHC before I'd like to continue to do so. My proposal would be something that tempted me (as a physics student) for a while: Units for Haskell/GHC. This project has been suggested for a long time on the GHC wiki, and there is already a lot of work done for other languages like ML, F# etc[1]. I have tried to implement e.g. the unification algorithm from the Types for Units-of-Measure in F# talk[2] for an abstract syntax tree[3] and it was pretty much straight forward. As I see it, the project would consist of: 1.) Find appropriate rules/algorithms for unit analysis. Most (if not all?) of this should be covered in those papers/talks on [1]. 2.) Applying the rules to the Haskell syntax tree used in GHC. I have approximately 3 years of experience with Haskell, I worked for the database research group[4] at the University of Tübingen (Germany) on the Database Supported Haskell[5] library. I've done most of the coding for the monad comprehension[6] extension, which has been added to the latest GHC release version. I'm already quite familiar with the GHC internals of the compiler/typechecker, and even though I'd have to look up how exactly type interference etc. works in GHC (as I've only *used* it, but never tried to understand/modify it) I'm confident that the work on GHC itself should be doable in the given timeframe. So my questions would be: Do you think this is a appropriate GSoC project? What should I include in the application/project proposal? Anything else? Opinions, suggestions? I realize that I'm kind of late and probably should have written this email a long time ago. But there are still 2 days left for the student application and hopefully I'll get some good feedback by then. - Nils [1]: http://research.microsoft.com/**en-us/um/people/akenn/units/** index.htmlhttp://research.microsoft.com/en-us/um/people/akenn/units/index.html [2]: http://research.microsoft.com/**en-us/um/people/akenn/units/** MLWorkshop2008.pdfhttp://research.microsoft.com/en-us/um/people/akenn/units/MLWorkshop2008.pdf [3]: https://github.com/mcmaniac/**units/blob/master/src/**Unification.hshttps://github.com/mcmaniac/units/blob/master/src/Unification.hs [4]: http://db.inf.uni-tuebingen.**de/teamhttp://db.inf.uni-tuebingen.de/team [5]: http://hackage.haskell.org/**package/DSHhttp://hackage.haskell.org/package/DSH [6]: http://db.inf.uni-tuebingen.**de/files/giorgidze/**haskell2011.pdfhttp://db.inf.uni-tuebingen.de/files/giorgidze/haskell2011.pdf __**_ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/**mailman/listinfo/haskell-cafehttp://www.haskell.org/mailman/listinfo/haskell-cafe -- Gregory Collins g...@gregorycollins.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
