From john at repetae.net Thu Jul 3 20:52:37 2014 From: john at repetae.net (John Meacham) Date: Thu, 3 Jul 2014 13:52:37 -0700 Subject: [jhc] Integer for JHC In-Reply-To: <53B31A3B.4070907@henning-thielemann.de> References: <53B31A3B.4070907@henning-thielemann.de> Message-ID: It should work, when I looked at it before it wasn't written to be that efficient, more of a proof of concept. the main reason I have not included something in jhc so far is holding out hope someone will implement a pure haskell Integer that is suitable, I don't want to put any magic in jhcs rts since for embedded platforms you want things like Char to be 8 bits and maybe a 16 bit Int or something, making sure the Integer code doesn't accidentally sneak in would come for free were it written in normal haskell. A library using the standard FFI to link to gmp would also be useful. jhc allows overlapping module names so no magic would be needed to switch between them, you would just bring libraries with different Prelude's into scope. John On Tue, Jul 1, 2014 at 1:29 PM, Henning Thielemann wrote: > Would this package help JHC to get a real Integer type? > > http://hackage.haskell.org/package/integer-pure -- John Meacham - http://notanumber.net/ From dmitry.kulagin at gmail.com Mon Jul 21 07:30:40 2014 From: dmitry.kulagin at gmail.com (Dmitry Kulagin) Date: Mon, 21 Jul 2014 11:30:40 +0400 Subject: [jhc] JHC: problem with transformers Message-ID: Hi John, I experiment with JHC, trying to get working some code. Could you help with following code: > module Main where > import Data.Map as M > g :: M.Map String Int > g = M.delete "b" M.empty > main = print g If it is compiled with: -f no-global-optimize, then incorrect C-code generated. (([N],"Prelude.error: Map.deleteFindMax: can not return the maximal element of an empty map"),Berr_18131) (([N],"Prelude.error: Map.deleteFindMin: can not return the minimal element of an empty map"),Berr_18132) ... tmp1/main_code.c:5956:21: error: variable ?_c7? has initializer but incomplete type tmp1/main_code.c:5959:21: error: variable ?_c6? has initializer but incomplete type Compiler version: jhc 0.8.2 (0.8.2-55) (the most recent from darcs) Full compiler output is in attach. PS.: This code _does_ compile if I don't use -f no-global-optimize. However, I experiment with larger code, which is only compiled if I turn this optimization off. That is why I try to stick with this option. Thanks! Dmitry -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: out.log Type: text/x-log Size: 35127 bytes Desc: not available URL: From john at repetae.net Mon Jul 21 09:17:23 2014 From: john at repetae.net (John Meacham) Date: Mon, 21 Jul 2014 02:17:23 -0700 Subject: [jhc] JHC: problem with transformers In-Reply-To: References: Message-ID: On Mon, Jul 21, 2014 at 12:30 AM, Dmitry Kulagin wrote: > > PS.: This code _does_ compile if I don't use -f no-global-optimize. However, > I experiment with larger code, which is only compiled if I turn this > optimization off. That is why I try to stick with this option. Hi, Interesting. I have not tested with no-global-optimize in a while, it is possible there is an optimization I accidentally depended on happening in the GRIN backend that is disabled by it. Is the main reason you are doing it is for code size? I should investigate why the code blows up for that case too. John -- John Meacham - http://notanumber.net/ From dmitry.kulagin at gmail.com Mon Jul 21 09:41:51 2014 From: dmitry.kulagin at gmail.com (Dmitry Kulagin) Date: Mon, 21 Jul 2014 13:41:51 +0400 Subject: [jhc] JHC: problem with transformers In-Reply-To: References: Message-ID: Hi John, Yes, original code seems to be pretty large. It fails to compile before code generation. I will try tonight to get the minimal example of the case. If I am not mistaken 'global-optimize' does not play nicely with monad transformers. Thanks! On Mon, Jul 21, 2014 at 1:17 PM, John Meacham wrote: > On Mon, Jul 21, 2014 at 12:30 AM, Dmitry Kulagin > wrote: > > > > PS.: This code _does_ compile if I don't use -f no-global-optimize. > However, > > I experiment with larger code, which is only compiled if I turn this > > optimization off. That is why I try to stick with this option. > > > Hi, Interesting. I have not tested with no-global-optimize in a while, > it is possible there is an optimization I accidentally depended on > happening in the GRIN backend that is disabled by it. > > Is the main reason you are doing it is for code size? I should > investigate why the code blows up for that case too. > > John > > -- > John Meacham - http://notanumber.net/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From john at repetae.net Mon Jul 21 12:26:01 2014 From: john at repetae.net (John Meacham) Date: Mon, 21 Jul 2014 05:26:01 -0700 Subject: [jhc] JHC: problem with transformers In-Reply-To: References: Message-ID: On Mon, Jul 21, 2014 at 2:41 AM, Dmitry Kulagin wrote: > > Yes, original code seems to be pretty large. It fails to compile before code > generation. I will try tonight to get the minimal example of the case. > If I am not mistaken 'global-optimize' does not play nicely with monad > transformers. It is possible, there are some optimizatinos that can blow up in size in certain cases. Usually I can fix them once identified. John -- John Meacham - http://notanumber.net/ From dmitry.kulagin at gmail.com Mon Jul 21 21:22:52 2014 From: dmitry.kulagin at gmail.com (Dmitry Kulagin) Date: Tue, 22 Jul 2014 01:22:52 +0400 Subject: [jhc] JHC: problem with transformers In-Reply-To: References: Message-ID: Hi John, Here is the case I was talking about (transformers + 'global-optimize'): > import Control.Monad.Trans.Class (lift) > import Control.Monad.Trans.Error > x :: ErrorT String IO () > x = lift (print "hello") >> return () > main = runErrorT x This code fails to compile with 'global-optimize' enabled: Collected Compilation... -- TypeAnalyzeMethods -- BoxifyProgram -- Boxy WorkWrap Stack: transformProgram: Simplify-SuperSimplify after Boxy WorkWrap jhc: E.TypeCheck.getType: (EPi x20202872::Jhc.Prim.IO.State_ Jhc.Prim.IO.RealWorld::*::# (EAp Jhc at .Box.*::* (EVar x20202872::Jhc.Prim.IO.State_ Jhc.Prim.IO.RealWorld::*::#)),#,Jhc at .Box.*::*) My original code (which is still too big) fails with very similar error. However, if you change line: > x = lift (print "hello") >> return () to: > x = lift (print "hello") then it is compiled successfully. Thanks! On Mon, Jul 21, 2014 at 4:26 PM, John Meacham wrote: > On Mon, Jul 21, 2014 at 2:41 AM, Dmitry Kulagin > wrote: > > > > Yes, original code seems to be pretty large. It fails to compile before > code > > generation. I will try tonight to get the minimal example of the case. > > If I am not mistaken 'global-optimize' does not play nicely with monad > > transformers. > > > It is possible, there are some optimizatinos that can blow up in size > in certain cases. Usually I can fix them once identified. > > John > > -- > John Meacham - http://notanumber.net/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: