state of the cabal (preprocessors)

[Graham Klyne]

At 12:46 19/10/04 +0100, Simon Marlow wrote:
>Also, I recommend that we use the compiler itself for preprocessing:
>
>   ghc -E foo.hs -o foo.phs

Er, shouldn't it be possible to use Cabal with a system that has just Hugs 
installed?

#g
--

At 12:46 19/10/04 +0100, Simon Marlow wrote:
>On 19 October 2004 09:58, Malcolm Wallace wrote:
>
> > Isaac Jones <ijones at syntaxpolice.org> writes:
> >
> >> The issue with cpp is that we can't go by extensions as we do with
> >> the rest of the preprocessors... There is a function in HMake which
> >> tests to see if a file needs to be cpp'd, so we can employ that.  I
> >> think we'll probably have to just treat cpp a little differently
> >> from the others, unfortunitely, and I haven't gotten around to it.
> >
> > On the other hand, you could reject the convention that cpp sources
> > are not distinguished by file extension - e.g. create a new convention
> > that, say, a .cpphs extension is preprocessed by cpp(hs) to get a
> > plain .hs file.
> >
> > Since Cabal is pretty new, this won't break any existing Cabal
> > packages, and when converting non-Cabal packages to Cabal, there is
> > some work to do anyway, so why not just adopt this as one extra rule
> > to follow?
> >
> > This is just a suggestion - I'm in two minds whether it is a good
> > idea myself, but it is at least worth considering the possibility.
>
>And I suppose the literate version would be .lcpphs? (unlit first, then
>cpp, then Haskell).  It would be more consistent and arguably correct,
>but I'm not sure that we should do it.
>
>Another solution is to adopt a new extension for plain Haskell, say
>.phs.  The conversion from .hs to .phs is either via CPP or just 'cat',
>depending on some setting somewhere.  Also, I recommend that we use the
>compiler itself for preprocessing:
>
>   ghc -E foo.hs -o foo.phs
>
>because only the compiler knows what the values for the preprocessor
>symbols __HASKELL__, __GLASGOW_HASKELL__, i386_TARGET_ARCH etc. should
>be.  Otherwise we'll have to run the compiler during ./setup configure
>to find out the values of these symbols (isn't that what hmake does?
>What about when a new compiler comes along?).
>
>Cheers,
>         Simon
>_______________________________________________
>Libraries mailing list
>Libraries at haskell.org
>http://www.haskell.org/mailman/listinfo/libraries

------------
Graham Klyne
For email:
http://www.ninebynine.org/#Contact