[jhc] what to work on next?

John Meacham john at repetae.net
Tue Jun 30 21:49:07 EDT 2009

On Mon, Jun 29, 2009 at 05:16:02PM -0400, Isaac Dupree wrote:
> on the subject of deducing dependencies.  What about code that can  
> function with or without the functionality of a given library?  Is there  
> any trouble with using CPP for that (say, #ifdef PARSE_YAML.  Or more  
> annoyingly, #ifdef  

It depends actually, this is something that the cabal scheme doesn't
work for, since you need to specify everything your package _might_
depend on, even though the dependencies may be irrelevant for a given
system or not even compile. Ideally it would do something like
franchise, build-depends are things you depend on for sure, but the
initial configuration can decide that it needs some more dependencies.
franchise-install (or whatever) is simply recursively invoked to install
any dependencies it didn't get in the first pass. Incidentally, this is
how pretty much every other CxAN style system works.

I think the #ifdef SOME_FEATURE_etc... problem is more an issue with
haskell' being so long in coming so such things are needed more often
than they should be.

Though, this touches on an interesting point that may become an issue
for jhc. Since jhc libraries are machine independent, this means that
your preprocessor doesn't have knowledge of the target architecture. so
things like #if WORD_SIZE == 64 won't work. the proper way to do it is
'if sizeOf (undefined :: Ptr ()) == 64 then ... else ...' or "if
isBigEndian then ... else ..." rather than relying on the preprocessor.
I imagine it will be something that comes up when porting code to jhc,
but I don't think it will be a big deal, just something to remember.

> but well. I guess this is getting a little off topic.

The practicalities of writing haskell code that is portable between
compilers is quite relevant. I certainly welcome discussion on the
topic. :)


John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/

More information about the jhc mailing list