Re: [Haskell-cafe] jhc speed
2009/2/22 Luke Palmer lrpal...@gmail.com: On Sun, Feb 22, 2009 at 8:15 AM, John Meacham j...@repetae.net wrote: On Sun, Feb 22, 2009 at 03:36:34PM +0100, Peter Verswyvelen wrote: Would it be possible to separate the frontend (Haskell to Core) and backend (Core to machine code) from the Haskell compilers (requiring a standard Core language?) I'm not sure how many extensions required a change to the Core language. Well, it depends on what you mean by 'core'. If you mean a desugared version of haskell, I think such a front end could be quite useful. By the way, coming up pretty soon, I will need a desugared annotated Haskell for Dana. If anybody has something like this in the works, I'd love to help with it. If it does not exist by the time I need it, I will make it, so if anyone is interested in working on it with me, let me know :-) The ghc-api exposes a type for annotated source: http://haskell.org/ghc/docs/latest/html/libraries/ghc/GHC.html#t%3ATypecheckedSource Not that i know how to use it. Luke in particular, I'd like to see a standalone implementation of template haskell. If you mean something lower level, as in the ghc core intermediate language the compiler uses internally, or jhc's core or grin representation, things get a bit more tricky. Although many core languages are somewhat similar, based on a typed lambda calculus of some sort, the details will differ, and translating between them can be lossy. For instance, looking at jhc core: http://repetae.net/computer/jhc/manual.html#jhc-core-type-system you can see it has a very rich language for dealing with strictness and boxedness. For instances, a boxed value known to be in WHNF actually has a different _type_ than one that is possibly unevaluated. Such distinctions are quite useful for jhc's back end but not so much for ghc's, hence ghc core doesn't make that distinction and any translation between the two would 'lose' that useful information. In other cases things are even worse, for instance ghc has a powerful type equality concept in its core language which jhc has no counterpart for, so that information will be lost on translation. But losing that information will actually cause the core to not type check, since ghc core can type some things jhc core cannot (and vice versa) so coercions or other mechanisms to bypass the type system will have to be introduced. So, it is certainly possible to translate between the two, in fact, I made a jhc core - ghc core translator, but the code it produced was necessarily riddled with unsafeCoerce#'s for everywhere the type systems didn't quite match up. John -- John Meacham - ⑆repetae.net⑆john⑈ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] jhc speed
On 23/02/2009, at 2:22 AM, Luke Palmer wrote: By the way, coming up pretty soon, I will need a desugared annotated Haskell for Dana. If anybody has something like this in the works, I'd love to help with it. If it does not exist by the time I need it, I will make it, so if anyone is interested in working on it with me, let me know :-) Luke Hi Luke, Any progress on that front? How much desugaring do you want? What kind of annotations do you want? Can you get what you need from the GHC API? Cheers, Bernie. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] jhc speed
On Wed, Feb 25, 2009 at 7:43 PM, Bernie Pope bj...@csse.unimelb.edu.auwrote: On 23/02/2009, at 2:22 AM, Luke Palmer wrote: By the way, coming up pretty soon, I will need a desugared annotated Haskell for Dana. If anybody has something like this in the works, I'd love to help with it. If it does not exist by the time I need it, I will make it, so if anyone is interested in working on it with me, let me know :-) Luke Hi Luke, Any progress on that front? Not yet. It's still a few items down in the queue. How much desugaring do you want? What kind of annotations do you want? Enough desugaring to make Haskell simple (yes, I know that's subjective). Probably somewhere around System-F (Fw perhaps, once I learn what that is). The main things I can think of are getting rid of special notation (do, list comp., where clauses, infix operators) and expanding typeclasses to dictionary passing. Can you get what you need from the GHC API? I haven't looked into it, but my guess is not. The main requirement is that it (and its desugared target) needs to be really pure (no IO, FFI, or polymorphic seq), and that it must be able to desugar itself. It might provide a good launching point though. Luke ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] jhc speed
Is there any conceivable factoring of GHC that would allow you to sandwich the core of jhc in between the front and back ends of GHC? Or are the architectures so fundamentally incompatible as to make this impossible? Such a factoring would be one way the community could help, and if successful, it would allow you to better focus on the really important stuff. Regards, John A. De Goes N-BRAIN, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Feb 20, 2009, at 4:14 PM, John Meacham wrote: On Fri, Feb 20, 2009 at 11:52:27PM +0100, Thomas Davie wrote: On 20 Feb 2009, at 23:44, Bulat Ziganshin wrote: Hello John, Saturday, February 21, 2009, 1:33:12 AM, you wrote: Don't forget jhc: i was pretty sure that jhc will be as fast as gcc :) unfortunately, jhc isn't our production compiler Why not? There's nothing stopping you from choosing any Haskell compiler you like. If jhc gives you the performance you need – use it. Heh. He probably meant something more like jhc is not a production compiler which is true for a lot of projects. For projects of substantial size or that require many extensions, jhc falls somewhat short. It is getting better though. Of course, help is always appreciated. :) John -- John Meacham - ⑆repetae.net⑆john⑈ ___ 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] jhc speed
Would it be possible to separate the frontend (Haskell to Core) and backend (Core to machine code) from the Haskell compilers (requiring a standard Core language?) I'm not sure how many extensions required a change to the Core language. Most likely this is nice in theory but hard in practice? On Sun, Feb 22, 2009 at 3:25 PM, John A. De Goes j...@n-brain.net wrote: Is there any conceivable factoring of GHC that would allow you to sandwich the core of jhc in between the front and back ends of GHC? Or are the architectures so fundamentally incompatible as to make this impossible? Such a factoring would be one way the community could help, and if successful, it would allow you to better focus on the really important stuff. Regards, John A. De Goes N-BRAIN, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Feb 20, 2009, at 4:14 PM, John Meacham wrote: On Fri, Feb 20, 2009 at 11:52:27PM +0100, Thomas Davie wrote: On 20 Feb 2009, at 23:44, Bulat Ziganshin wrote: Hello John, Saturday, February 21, 2009, 1:33:12 AM, you wrote: Don't forget jhc: i was pretty sure that jhc will be as fast as gcc :) unfortunately, jhc isn't our production compiler Why not? There's nothing stopping you from choosing any Haskell compiler you like. If jhc gives you the performance you need – use it. Heh. He probably meant something more like jhc is not a production compiler which is true for a lot of projects. For projects of substantial size or that require many extensions, jhc falls somewhat short. It is getting better though. Of course, help is always appreciated. :) John -- John Meacham - ⑆repetae.net⑆john⑈ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] jhc speed
On Sun, Feb 22, 2009 at 07:25:26AM -0700, John A. De Goes wrote: Is there any conceivable factoring of GHC that would allow you to sandwich the core of jhc in between the front and back ends of GHC? Or are the architectures so fundamentally incompatible as to make this impossible? Well, it wouldn't really be useful sandwiched between the front and back end of ghc, the main advantages jhc has over ghc's model are in its lower level optimizations closer to the back end. Feeding ghc core into jhc shouldn't be impossible. Oddly enough, I have written a ghc back end for jhc, mainly for testing purposes rather than a serious back end. The tricky part isn't so much the translation of ghc to jhc core, the type system and representation are quite similar, but the difference in the primitives that the two systems expect to exist. for instance, ghc has high level primitives, such as operations on Integers and primitive types that high signedness. While jhcs primitives are much lower level, it has no special concept of Integer for instance, you implement Integer either in pure haskell code or FFI bindings to GMP or some other way, and jhc's primitive numerical types are simply bit patterns with no interpretation, for instance data Int = I Bits32_ data Word = W Bits32_ and the only thing that makes Int signed and Word not is in the 'Num' instances for those types. That said, i don't see any reason a ghc-core front end for jhc wouldn't be possible, an adapter library could be written to provide ghc style primitives on top of the jhc ones. It would certainly be an interesting project. John -- John Meacham - ⑆repetae.net⑆john⑈ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] jhc speed
On Sun, Feb 22, 2009 at 03:36:34PM +0100, Peter Verswyvelen wrote: Would it be possible to separate the frontend (Haskell to Core) and backend (Core to machine code) from the Haskell compilers (requiring a standard Core language?) I'm not sure how many extensions required a change to the Core language. Well, it depends on what you mean by 'core'. If you mean a desugared version of haskell, I think such a front end could be quite useful. in particular, I'd like to see a standalone implementation of template haskell. If you mean something lower level, as in the ghc core intermediate language the compiler uses internally, or jhc's core or grin representation, things get a bit more tricky. Although many core languages are somewhat similar, based on a typed lambda calculus of some sort, the details will differ, and translating between them can be lossy. For instance, looking at jhc core: http://repetae.net/computer/jhc/manual.html#jhc-core-type-system you can see it has a very rich language for dealing with strictness and boxedness. For instances, a boxed value known to be in WHNF actually has a different _type_ than one that is possibly unevaluated. Such distinctions are quite useful for jhc's back end but not so much for ghc's, hence ghc core doesn't make that distinction and any translation between the two would 'lose' that useful information. In other cases things are even worse, for instance ghc has a powerful type equality concept in its core language which jhc has no counterpart for, so that information will be lost on translation. But losing that information will actually cause the core to not type check, since ghc core can type some things jhc core cannot (and vice versa) so coercions or other mechanisms to bypass the type system will have to be introduced. So, it is certainly possible to translate between the two, in fact, I made a jhc core - ghc core translator, but the code it produced was necessarily riddled with unsafeCoerce#'s for everywhere the type systems didn't quite match up. John -- John Meacham - ⑆repetae.net⑆john⑈ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] jhc speed
On Sun, Feb 22, 2009 at 8:15 AM, John Meacham j...@repetae.net wrote: On Sun, Feb 22, 2009 at 03:36:34PM +0100, Peter Verswyvelen wrote: Would it be possible to separate the frontend (Haskell to Core) and backend (Core to machine code) from the Haskell compilers (requiring a standard Core language?) I'm not sure how many extensions required a change to the Core language. Well, it depends on what you mean by 'core'. If you mean a desugared version of haskell, I think such a front end could be quite useful. By the way, coming up pretty soon, I will need a desugared *annotated*Haskell for Dana. If anybody has something like this in the works, I'd love to help with it. If it does not exist by the time I need it, I will make it, so if anyone is interested in working on it with me, let me know :-) Luke in particular, I'd like to see a standalone implementation of template haskell. If you mean something lower level, as in the ghc core intermediate language the compiler uses internally, or jhc's core or grin representation, things get a bit more tricky. Although many core languages are somewhat similar, based on a typed lambda calculus of some sort, the details will differ, and translating between them can be lossy. For instance, looking at jhc core: http://repetae.net/computer/jhc/manual.html#jhc-core-type-system you can see it has a very rich language for dealing with strictness and boxedness. For instances, a boxed value known to be in WHNF actually has a different _type_ than one that is possibly unevaluated. Such distinctions are quite useful for jhc's back end but not so much for ghc's, hence ghc core doesn't make that distinction and any translation between the two would 'lose' that useful information. In other cases things are even worse, for instance ghc has a powerful type equality concept in its core language which jhc has no counterpart for, so that information will be lost on translation. But losing that information will actually cause the core to not type check, since ghc core can type some things jhc core cannot (and vice versa) so coercions or other mechanisms to bypass the type system will have to be introduced. So, it is certainly possible to translate between the two, in fact, I made a jhc core - ghc core translator, but the code it produced was necessarily riddled with unsafeCoerce#'s for everywhere the type systems didn't quite match up. John -- John Meacham - ⑆repetae.net⑆john⑈ ___ 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] jhc speed
I think doing this work would improve the design of GHC by improving modularity and factoring out generalized abstractions. The richest possible core language makes the most sense for a common core, because what's not needed can always be discarded. From your description, it sounds like such a common core language would be a hybrid of jhc and ghc core, because each contains more information for particular subsets of the language. Layering higher-level primitives on lower-level primitives also makes sense, as it's a very flexible approach. How much support and direction can you provide if we get enough people interested in this? Regards, John A. De Goes N-BRAIN, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Feb 22, 2009, at 7:45 AM, John Meacham wrote: On Sun, Feb 22, 2009 at 07:25:26AM -0700, John A. De Goes wrote: Is there any conceivable factoring of GHC that would allow you to sandwich the core of jhc in between the front and back ends of GHC? Or are the architectures so fundamentally incompatible as to make this impossible? Well, it wouldn't really be useful sandwiched between the front and back end of ghc, the main advantages jhc has over ghc's model are in its lower level optimizations closer to the back end. Feeding ghc core into jhc shouldn't be impossible. Oddly enough, I have written a ghc back end for jhc, mainly for testing purposes rather than a serious back end. The tricky part isn't so much the translation of ghc to jhc core, the type system and representation are quite similar, but the difference in the primitives that the two systems expect to exist. for instance, ghc has high level primitives, such as operations on Integers and primitive types that high signedness. While jhcs primitives are much lower level, it has no special concept of Integer for instance, you implement Integer either in pure haskell code or FFI bindings to GMP or some other way, and jhc's primitive numerical types are simply bit patterns with no interpretation, for instance data Int = I Bits32_ data Word = W Bits32_ and the only thing that makes Int signed and Word not is in the 'Num' instances for those types. That said, i don't see any reason a ghc-core front end for jhc wouldn't be possible, an adapter library could be written to provide ghc style primitives on top of the jhc ones. It would certainly be an interesting project. John -- John Meacham - ⑆repetae.net⑆john⑈ ___ 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
