
Is it already a known problem that the preprocessor cannot cope with the whole set of possible string declarations? $ cat long1.hs {-# OPTIONS -cpp #-} s = "abc\ \defg" main = putStrLn s $ ghc long1.hs long1.hs:3:14: lexical error in string/character literal at character 'e' $ cat long2.hs s = "abc\ \defg" main = putStrLn s $ ghc long2.hs $ a.out abcdefg

Am Donnerstag, 6. Dezember 2007 10:43 schrieb Bernd Brassel:
Is it already a known problem that the preprocessor cannot cope with the whole set of possible string declarations?
Yes, it is. There is cpphs (http://www.cs.york.ac.uk/fp/cpphs/) as an alternative.
[…]
Best wishes, Wolfgang

Wolfgang Jeltsch wrote:
Am Donnerstag, 6. Dezember 2007 10:43 schrieb Bernd Brassel:
Is it already a known problem that the preprocessor cannot cope with the whole set of possible string declarations?
Yes, it is. There is cpphs (http://www.cs.york.ac.uk/fp/cpphs/) as an alternative.
Yes, or just don't use string gaps. ++ works just as well, and GHC will optimise it away when applied to constant strings. Cheers, Simon

Hi
Yes, or just don't use string gaps. ++ works just as well, and GHC will optimise it away when applied to constant strings.
There are also other issues, such as ' in variable names (can cause bits to be skipped in that line), /* as an operator, unboxed varids in #define's Thanks Neil

Neil Mitchell wrote:
Yes, or just don't use string gaps. ++ works just as well, and GHC will optimise it away when applied to constant strings.
There are also other issues, such as ' in variable names (can cause bits to be skipped in that line), /* as an operator, unboxed varids in #define's
Yes, sure. (although the ' thing doesn't bite us - perhaps it doesn't apply with -traditional?) Cheers, Simon

Hi Simon,
Yes, sure. (although the ' thing doesn't bite us - perhaps it doesn't apply with -traditional?)
I think it bit me last week. I had something like: #define a b foo'bar a In this case it did because "a" wasn't changed to "b". It may have been other complex things going on as well, but removing the ' fixed the issue. It's less likely to bite, but still hiding out :-) Thanks Neil

Simon Marlow wrote:
Neil Mitchell wrote:
Yes, or just don't use string gaps. ++ works just as well, and GHC will optimise it away when applied to constant strings.
There are also other issues, such as ' in variable names (can cause bits to be skipped in that line), /* as an operator, unboxed varids in #define's
Yes, sure. (although the ' thing doesn't bite us
it seems to have bitten at least at one time: there is a workaround in Data.Bits (see "wsib") : (I# x#) `rotate` (I# i#) = I# (word2Int# ((x'# `uncheckedShiftL#` i'#) `or#` (x'# `uncheckedShiftRL#` (wsib -# i'#)))) where x'# = int2Word# x# i'# = word2Int# (int2Word# i# `and#` int2Word# (wsib -# 1#)) wsib = WORD_SIZE_IN_BITS# {- work around preprocessor problem (??) -} Isaac

On Thu, Dec 06, 2007 at 10:43:30AM +0100, Bernd Brassel wrote:
Is it already a known problem that the preprocessor cannot cope with the whole set of possible string declarations?
The cpp is a *C* preprocessor, and if it has been written to adhere to the C standard, it is required to diagnose tokens that are not valid C preprocessing tokens (such as string literals that do not end before the end of a line). As such, this is unsurprising. It would probably make most sense to make cpphs the (only) preprocessor used with -cpp instead of using whatever *C* preprocessor happens to be in the path. -- Antti-Juhani Kaijanaho, Jyväskylä, Finland http://antti-juhani.kaijanaho.fi/newblog/ http://www.flickr.com/photos/antti-juhani/

On Thu, Dec 06, 2007 at 04:59:48PM +0200, Antti-Juhani Kaijanaho wrote:
On Thu, Dec 06, 2007 at 10:43:30AM +0100, Bernd Brassel wrote:
Is it already a known problem that the preprocessor cannot cope with the whole set of possible string declarations?
The cpp is a *C* preprocessor, and if it has been written to adhere to the C standard, it is required to diagnose tokens that are not valid C preprocessing tokens (such as string literals that do not end before the end of a line). As such, this is unsurprising.
It would probably make most sense to make cpphs the (only) preprocessor used with -cpp instead of using whatever *C* preprocessor happens to be in the path.
I have added an option to jhc to allow 'm4' as a preprocessor. (-fm4), I have found it to play much nicer with haskell than cpp and is signifigantly more powerful. perhaps other compilers could do likewise? I invoke it with changequote({{,}}) at the beginning which seems to work well for haskell. John -- John Meacham - ⑆repetae.net⑆john⑈
participants (7)
-
Antti-Juhani Kaijanaho
-
Bernd Brassel
-
Isaac Dupree
-
John Meacham
-
Neil Mitchell
-
Simon Marlow
-
Wolfgang Jeltsch