- jhc - Haskell.org

Microsoft Customer Lists
by mike gordon 22 Mar '09

22 Mar '09

We are pleased to announce the availability of the following Microsoft customer lists: Sharepoint Dynamics SQL Exchange Biztalk FRX CRM System Center Visual Studio VAR If you would like more information or a sample off any of our lists, please contact us at (905) 721-8456 or email us at repharm1(a)aol.com, Also we have the following lists as well Below are just some of the lists available: ERP (ENTERPRISE RESOURCE PLANNING): Baan JD Edwards Lawson Made2Manage Mapics Marcam Oracle Peoplesoft SAP SSA E-BUSINESS APPLICATIONS: Ariba BMC BroadVision Commerce One Webtrends MIDDLEWARE/CONNECTIVITY/APP SERVERS/WEB SERVERS: Bea Systems Iona Unisys OPERATING SYSTEMS/HARDWARE/SOFTWARE: COMPAQ HP 3000 HP 9000 HP-UX IBM AS/400 IBM OS/390 Lotus Notes Microsoft Sun Microsystems DATABASE: DB2 FileMaker Informix Oracle SQL SybaseCRM (CUSTOMER RELATIONSHIP MANAGEMENT): Clarify E.piphany HNC Onyx Pivotal Siebel Vantive Xchange SUPPLY CHAIN: Agile i2 Technologies Manugistics QAD Webplan COMMUNICATIONS: Nortel Cisco 3com Siemens Alcatel Telecom Vars ASP’s CLECS ISP’s E-COMMERCE: Dot Com Directory Consultant Directory Software Directory EXECUTIVE DIRECTORIES: Chief Executive Officer Chief Financial Officer Chief Information Officer Engineering Human Resources Purchasing Sales/Marketing INDUSTRY SPECIFIC LISTS: Agriculture, Forestry and Fishing, Communications, Construction, Finance, Insurance and Real Estate, Manufacturing, Mining, Public Administration, Retail Trade, Services, Transportation, Utilities, Wholesale Trade

1 0

some jhc weirdness
by sylvain 21 Mar '09

21 Mar '09

Hi, after having adapted "binaries-tree" from http://shootout.alioth.debian.org/u32q/benchmark.php?test=binarytrees&lang=… to remove the dependency on Text.Printf (program below), I get the following results. 1. reference run. $ghc --make -O2 -fglasgow-exts -fasm prog.hs -o prog.ghc $./prog.ghc 1 "stretch tree" of depth 7 check: -1 "128 trees" of depth 4 check: -128 "32 trees" of depth 6 check: -32 "long lived tree" of depth 6 check: -1 2. jhc run. $jhc -o prog of depth 77 check: -1 of depth 44 check: -128 of depth 66 check: -32 of depth 66 check: -1 $ ./prog.jhc 18 of depth 1919 check: -1 segmentation fault Maybe is it time to set up a bug tracker :) Sylvain --snip-- import System import Data.Bits -- -- an artificially strict tree. -- -- normally you would ensure the branches are lazy, but this benchmark -- requires strict allocation. -- data Tree = Nil | Node !Int !Tree !Tree minN = 4 io s n t = putStrLn (show s++" of depth "++(show n)++" check: "++(show t)) main = do n <- getArgs >>= readIO . head let maxN = max (minN + 2) n stretchN = maxN + 1 -- stretch memory tree let c = check (make 0 stretchN) io "stretch tree" stretchN c -- allocate a long lived tree let long = make 0 maxN -- allocate, walk, and deallocate many bottom-up binary trees let vs = depth minN maxN mapM_ (\((m,d,i)) -> io (show m ++ " trees") d i) vs -- confirm the the long-lived binary tree still exists io "long lived tree" maxN (check long) -- generate many trees depth :: Int -> Int -> [(Int,Int,Int)] depth d m | d <= m = (2*n,d,sumT d n 0) : depth (d+2) m | otherwise = [] where n = 1 `shiftL` (m - d + minN) -- allocate and check lots of trees sumT :: Int -> Int -> Int -> Int sumT d 0 t = t sumT d i t = sumT d (i-1) (t + a + b) where a = check (make i d) b = check (make (-i) d) -- traverse the tree, counting up the nodes check :: Tree -> Int check Nil = 0 check (Node i l r) = i + check l - check r -- build a tree make :: Int -> Int -> Tree make i 0 = Node i Nil Nil make i d = Node i (make (i2-1) d2) (make i2 d2) where i2 = 2*i; d2 = d-1 --snip--

3 2

some more jhc weirdness
by sylvain 20 Mar '09

20 Mar '09

Hi, I have rewritten the program in my previous mail. io s n t = do putStr s putStr " of depth " putStr (show n) putStr " check: " putStrLn (show t) With this workaround, the ghc and jhc generated programs give the same output. Let do some speed comparison. $ ghc --make -O2 -fglasgow-exts -fasm prog.hs -o prog.ghc $ jhc prog.hs -o prog.jhc You can get a reference C version, supposedly optimized, here: http://shootout.alioth.debian.org/u32q/benchmark.php?test=binarytrees&lang=… $ gcc -pipe -Wall -O3 -fomit-frame-pointer -march=native -lm prog.c -o prog.gcc below are the results for the third run (to mitigate cache miss effect) of each program: $ time ./prog.ghc 17 real 0m5.606s user 0m5.104s sys 0m0.032s $ time ./prog.gcc 17 real 0m5.269s user 0m5.264s sys 0m0.004s C is faster than GHC Haskell, things are in order. $ time ./prog.jhc 17 real 0m2.656s user 0m1.364s sys 0m1.048s What is wrong with my computer, I wonder? :) Sylvain Nahas

1 0

Re: [Haskell] ANNOUNCE: jhc 0.6.0 Haskell Compiler
by John Meacham 19 Mar '09

19 Mar '09

nice, although not quite fair, as jhc always has optimization turned on, so compiling the others with -O is more appropriate. The 'show' instance is clearly eating up most of the time in the jhc version, if you look at the generated C code. here is main as generated by jhc annotated with the haskell it cooresponds to in the comments : static void A_STD ftheMain(void) { // passing in 100000000 to countdown uint32_t v184744394 = 10000000; // countdown :: Int -> IO () fW_a__fMain__fl_aMain__countdown_d43_u8:; { sptr_t v261990436 = ((sptr_t)VALUE(v184744394)); // check if it is zero if (0 == v184744394) { // putStr "finished" fPrelude__IO__putStr(c8); // putChar '\n' return (void)jhc_utf8_putchar((int)10); } else { // let s = show x wptr_t v100000 = fInstance_a__iJhc__Show__show__default(v261990436); sptr_t v118875000 = demote(v100000); // putsStr s fPrelude__IO__putStr(v118875000); // putChar '\n' (void)jhc_utf8_putchar((int)10); // jump to countdown with x = x - 1 uint32_t v14532078 = (v184744394 - 1); v184744394 = v14532078; goto fW_a__fMain__fl_aMain__countdown_d43_u8; } } } John -- John Meacham - ⑆repetae.net⑆john⑈

2 1

Re: [Haskell] ANNOUNCE: jhc 0.6.0 Haskell Compiler
by Taral 19 Mar '09

19 Mar '09

2009/3/18 Brandon S. Allbery KF8NH <allbery(a)ece.cmu.edu>: > I suspect if you profile you'll find that Haskell's show is faster than C's > printf, especially if the appropriate show instance is selected at compile > time. Probably why the executable is bigger, too. Try static linking if you want apples-to-apples. -- Taral <taralx(a)gmail.com> "Please let me know if there's any further trouble I can give you." -- Unknown

1 0

[john@repetae.net: Re: [Haskell-cafe] I want to write a compiler]
by John Meacham 10 Mar '09

10 Mar '09

forwarding this to the jhc list as it is jhc relevant ----- Forwarded message from John Meacham <john(a)repetae.net> ----- To: haskell-cafe(a)haskell.org List-Id: The Haskell Cafe <haskell-cafe.haskell.org> Date: Mon, 9 Mar 2009 17:41:01 -0700 From: John Meacham <john(a)repetae.net> Subject: Re: [Haskell-cafe] I want to write a compiler On Mon, Mar 09, 2009 at 09:25:58AM -0500, Austin Seipp wrote: > Indeed, I stumbled upon it whilst looking at how unsafeCoerce worked > (to find out it is super-duper-special and implemented as part of E.) > I think it's actually pretty clever, and who knows, maybe it could be > useful as at least a debugging aid. :) It is actually not all that special, it is just a primitive like any other than transates to a nop, or no code. Since the optimizer can't know what is inside a primitive in general, it leaves it alone and the only affect is the type coercion implicit in its signature. When translating to Grin, the unsafeCoerces are simply dropped. Coercions used to be more complicated because once upon a time I required them to be used to translate to/from newtype declared synonyms, I found they inhibited optimizations too much so switched to the current mechanism whereby newtype expansion happens transparently in the type checker when needed. As a side effect I worked hard to try to recognize and optimize around coercions, but now that they occur fairly rarely, it isn't much of an issue any more. > This is a very good point I hadn't even thought about! Indeed, since > GRIN represents thunks in a defunctionalized way - encoded as nodes - > dealing with boxed/unboxed values becomes more of the compiler's job, > since the nature of unboxed values etc. becomes more transparent. The main reason I think it is important is because I feel not including unboxed values from the get-go was one of the biggest false starts I had when writing jhc. When I initially started writing it I considered unboxed values as a feature to be added later. When I started implementing them, I found that there were a lot of decisions I would have made differently and a lot of places they would have greatly simplified my initial design had I had them from the start. Namely, A whole host of 'compiler magic' could have gone away if I implemented all primitive types in pure haskell like I implement floats and chars now, data Float = Float_ Float32_ data Char = Char Bits32_ (where Float32_ and Bits32_ are the unboxed raw types) Since instead I had the compiler implement Int and friends directly, it suddenly had the responisibity to conjure up all sorts of operations on them, such as the Num instances, creating the big mess of compiler magic in PrimitiveOperators.hs. The more I can express in the haskell source directly the better, it raises odd questions when the compiler has to do things like implement Num instances directly, like the instances are built in, but we might not have 'imported' the types needed to declare them into the current scope, so we end up having to deal with instancse for types that don't exist yet. In any case, yeah. if you plan on unboxed types at some point, include them from the start because they can simplify a lot to offset their cost of implementation, by trying to add them on later I ended up having to pay the cost of implementing them, but also had to deal with the cruft left over from not utilizing them from the beginning. > Since you bring this up, I figure this decision also had some > influence on E in lhc/jhc, considering its type system is rich enough > to distinguish values in whnf/boxed/unboxed etc.? Yeah, there were a couple things that motivated this. A big one is that evals are bad in jhc, signifigantly moreso than traditional ghc. The points-to analysis is the main way to fight it, but I also decided I wanted to give it the best shot possible by getting rid of as many evals as I could in higher level optimizations, which necessitated a fairly rich type system since it actually made sense for jhc to keep strict track of what was in WHNF vs not even if they were both boxed. in general ghc didn't care unless a value was either CPRable or unboxable, but jhc can benefit from such knowledge no matter what the type, even if it is a partially applied function. Though, it is interesting that GHC may be moving to a jhc-style semi-tagging mechanism according to this paper[1] so more optimizations may help both equally in the future. The other main motivating factor was that I was always enamoured with the idea of jhc supporting more than one source language, in particular, I wanted to explore it having an SML front end, so wanted a core type system that was equally good at expressing lazy haskell as strict ML, and more importantly would be able to seamlessly intermingle the two without difficulty. So, when designing it, I kept that in mind, "is this equally useful as a ML compilers core?" or a "wacky ML/Haskell hybrid?". Although the ML front end is more of a thought experiment at this point, I think it helped me come up with a coherent type system that had intruiging possibilies for haskell optimizations, as well as some language implications, such as the ability to declare new 'strict' algebraic types that may lead to new ideas for language extensions. John [1] http://research.microsoft.com/en-us/um/people/simonpj/papers/ptr-tag/ -- John Meacham - ⑆repetae.net⑆john⑈ -- Haskell-Cafe mailing list Haskell-Cafe(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ----- End forwarded message ----- -- John Meacham - ⑆repetae.net⑆john⑈

1 0

darcs patch: update building documentation (and 11 more)
by John Meacham 07 Mar '09

07 Mar '09

Wed Mar 4 19:37:39 PST 2009 John Meacham <john(a)repetae.net> * update building documentation Thu Mar 5 02:06:33 PST 2009 John Meacham <john(a)repetae.net> * fix foreign import of c_strcmp to have pointers as arguments Thu Mar 5 02:16:54 PST 2009 John Meacham <john(a)repetae.net> * fix Grin.Devolve to catch all lifted functions in a single pass and not have to recurse Thu Mar 5 03:04:59 PST 2009 John Meacham <john(a)repetae.net> * remove superfluous 'Atom' argument to the tyvar [binary format change] Thu Mar 5 03:06:30 PST 2009 John Meacham <john(a)repetae.net> * update version number to 0.6.0 Thu Mar 5 17:40:27 PST 2009 John Meacham <john(a)repetae.net> * code cleanups and tweak strictness and UNPACK pragmas Thu Mar 5 20:43:27 PST 2009 John Meacham <john(a)repetae.net> * don't include '()' in parameters to primitives. Thu Mar 5 20:44:08 PST 2009 John Meacham <john(a)repetae.net> * add various ways to test compile time properties in Jhc.Options Thu Mar 5 21:30:12 PST 2009 John Meacham <john(a)repetae.net> * clean up handling of Jhc.Options options Fri Mar 6 00:58:52 PST 2009 John Meacham <john(a)repetae.net> * clean up core and grin dumping some Fri Mar 6 00:59:22 PST 2009 John Meacham <john(a)repetae.net> * add back in an optimization step after lambda lifting to fix up some core that translates to pessismal grin Fri Mar 6 02:36:07 PST 2009 John Meacham <john(a)repetae.net> * minor improvements

1 0

new packages for jhc, applicative and containers
by John Meacham 05 Mar '09

05 Mar '09

I am happy to announce that as of the 0.5.20090304 release, the default jhc install comes with a few more packages that make it a lot easier to compile random code out there, applicative: Control.Applicative, Control.Arrow, Control.Category, Data.Foldable, Data.Traversable containers: Data.Graph, Data.IntMap, Data.IntSet, Data.Map, Data.Sequence, Data.Set, Data.Tree They are included in the tarball and rpms and the default build. you have to pull containers from the darcs repository as mentioned on the building page, but other than that it builds directly from the shared containers source with no hackery required! Information on installing jhc is here: http://repetae.net/computer/jhc/building.shtml and the main jhc page is here: http://repetae.net/computer/jhc John -- John Meacham - ⑆repetae.net⑆john⑈

1 0

darcs patch: clean up renaming code, collect free var... (and 6 more)
by John Meacham 05 Mar '09

05 Mar '09

Wed Mar 4 17:12:29 PST 2009 John Meacham <john(a)repetae.net> * clean up renaming code, collect free variables from SPECIALIZATION pragmas before renaming Wed Mar 4 17:12:34 PST 2009 John Meacham <john(a)repetae.net> * clean out unneeeded hsQualTypeHsContext function Wed Mar 4 17:13:15 PST 2009 John Meacham <john(a)repetae.net> * perform specialization of SPECIALIZE pragmas that have free variables properly Wed Mar 4 17:54:37 PST 2009 John Meacham <john(a)repetae.net> * disable bang patterns for now Wed Mar 4 18:07:13 PST 2009 John Meacham <john(a)repetae.net> * add applicative and containers to distributed libraries Wed Mar 4 18:07:39 PST 2009 John Meacham <john(a)repetae.net> tagged neopdoxhedvo Wed Mar 4 18:08:02 PST 2009 John Meacham <john(a)repetae.net> * update datestamp

1 0

darcs patch: clean up renaming code, collect free var... (and 6 more)
by John Meacham 05 Mar '09

05 Mar '09

Wed Mar 4 17:12:29 PST 2009 John Meacham <john(a)repetae.net> * clean up renaming code, collect free variables from SPECIALIZATION pragmas before renaming Wed Mar 4 17:12:34 PST 2009 John Meacham <john(a)repetae.net> * clean out unneeeded hsQualTypeHsContext function Wed Mar 4 17:13:15 PST 2009 John Meacham <john(a)repetae.net> * perform specialization of SPECIALIZE pragmas that have free variables properly Wed Mar 4 17:54:37 PST 2009 John Meacham <john(a)repetae.net> * disable bang patterns for now Wed Mar 4 18:07:13 PST 2009 John Meacham <john(a)repetae.net> * add applicative and containers to distributed libraries Wed Mar 4 18:07:39 PST 2009 John Meacham <john(a)repetae.net> tagged neopdoxhedvo Wed Mar 4 18:08:02 PST 2009 John Meacham <john(a)repetae.net> * update datestamp

1 0