July 2007 - jhc - Haskell.org

Typechecker hiccup?
by Samuel J.J.Bronson 18 Jul '07

18 Jul '07

I just tried to compile this program (based on figure one in "The GRIN Project: A Highly Optimising Back End for Lazy Functional Languages"): {-# OPTIONS_JHC -N -fffi #-} import Jhc.Basics import Jhc.Int import Jhc.Num import Jhc.Order default (Integer, Double) main = sum (upto 1 10) upto m n | m > n = [] | otherwise = m : upto (m+1) n sum [] = 0 sum (x:xs) = x + sum xs And I got a stupid error about a missing "put" method for IORef. It seems that the typechecker isn't getting rid of all the MetaVars in this program...

3 4

foreign import "wrapper"
by Samuel Bronson 16 Jul '07

16 Jul '07

On IRC, you (JohnMeacham) (what -- there is someone else who reads this list?) said something about region inference and foreign import "wrapper". It just occured to me earlier today that you probably can't do much of that at all. You can basically do as much as you can do for a StablePtr. I remind you that the C functions made by a wrapper stub can be passed to C code and held there indefinately, just like a StablePtr, and can only be deallocated when the Haskell program calls freeHaskellFunPtr on them. We also talked about how a nice way to implement these wrapper stubs, by generating tiny thunks that would redirect calls to an evaluation routine after adding the closure to be called as an additional argument. (Actually, I suppose the evaluation routine would need a wrapper, like a foreign export does...). What I'm not sure about is how to refer to the address of the (wrapper around the) evaluation routine in the code for the "wrapper stub" (the function that is actually declared by the 'foreign import "wrapper"' declaration).

4 4

darcs patch: Be more specific about monadic imports, for compatibil...
by Samuel Bronson 16 Jul '07

16 Jul '07

Mon Jul 16 18:15:45 EDT 2007 Samuel Bronson <naesten(a)gmail.com> * Be more specific about monadic imports, for compatibility (especially 6.6/6.6.1)

1 0

darcs patch: Document lookupCType/lookupCType' (and 1 more)
by Samuel Bronson 14 Jul '07

14 Jul '07

Fri Jul 13 13:57:31 EDT 2007 Samuel Bronson <naesten(a)gmail.com> * Document lookupCType/lookupCType' Fri Jul 13 23:00:50 EDT 2007 Samuel Bronson <naesten(a)gmail.com> * Implement "foreign export"

1 0

darcs patch: Get pure foreign exports through E... Gr... (and 6 more)
by Samuel Bronson 13 Jul '07

13 Jul '07

Fri Jul 6 18:56:11 EDT 2007 Samuel Bronson <naesten(a)gmail.com> * Get pure foreign exports through E... Grin forgets them though Sat Jul 7 16:43:26 EDT 2007 Samuel Bronson <naesten(a)gmail.com> * Implement foreign exports returning IO () (clumsily) Mon Jul 9 19:38:11 EDT 2007 Samuel Bronson <naesten(a)gmail.com> * Yay! "foreign export", really working! Fri Jul 13 13:56:44 EDT 2007 Samuel Bronson <naesten(a)gmail.com> * Rollback Grin.Val.convertName Fri Jul 13 13:57:31 EDT 2007 Samuel Bronson <naesten(a)gmail.com> * Document lookupCType/lookupCType' Fri Jul 13 16:34:35 EDT 2007 Samuel Bronson <naesten(a)gmail.com> * Fix up "foreign export" support in E.FromHs Fri Jul 13 16:48:22 EDT 2007 Samuel Bronson <naesten(a)gmail.com> * Excorcize trace calls

1 0

Jhc's tangled base
by Samuel Bronson 10 Jul '07

10 Jul '07

Jhc's Prelude seems to be at the center of a giant tangle (SCC) of modules. This tangle of modules takes a *lot* of resources to compile -- I might possibly have gotten it to typecheck once. What's the plan for dealing with it? It almost makes me like GHC's way :-(. It seems like a lot of code would need to be moved to remove more than a couple of modules from the SCC... One problem is that the code to implement Read and Show pulls in Numeric and the list functions currently in Prelude, which pull in a whole bunch of other stuff... including Foreign.Marshal.Utils, Foreign.Marshal.Alloc, Foreign.Ptr, and lots more... Actually, I think the list functions from Prelude could escape the tangle if Maybe didn't derive Read...

2 2

darcs patch: Dump dependancy graph to scc_graph.dot with -dscc-modules
by Samuel Bronson 10 Jul '07

10 Jul '07

Tue Jul 10 18:06:35 EDT 2007 Samuel Bronson <naesten(a)gmail.com> * Dump dependancy graph to scc_graph.dot with -dscc-modules This probably isn't the best option or the best filename or anything, but it seems like it would be handy for untangling Prelude (and user code)

1 0

darcs patch: Allow empty import lists
by Samuel Bronson 10 Jul '07

10 Jul '07

Mon Jul 9 22:55:32 EDT 2007 Samuel Bronson <naesten(a)gmail.com> * Allow empty import lists

2 1

darcs patch: Make Foreign.StablePtr not depend on Prelude
by Samuel Bronson 10 Jul '07

10 Jul '07

Mon Jul 9 23:43:49 EDT 2007 Samuel Bronson <naesten(a)gmail.com> * Make Foreign.StablePtr not depend on Prelude

2 1

hmm. this approach to FFI export's types isn't working :-(.
by Samuel Bronson 10 Jul '07

10 Jul '07

It seems that the types that would be appropriate for the arguments of an FFI-exported function are not really allowed to exist in E or Grin :-(. What should I do about this? Perhaps the marshalling should be saved for the very end, and done in C.FromGrin2 or thereabouts?

2 1