2012-02-10 12 views
1

haskell-src-extsを使用して一連のhaskellソースファイルの解析を行っていますが、最初にテストしたファイルで問題が発生しました。ここで最初のビットは次のとおりです。haskell-src-extsの解決策または回避策CPPが失敗したモジュールの解析

{-# LANGUAGE CPP, MultiParamTypeClasses, ScopedTypeVariables #-} 
{-# OPTIONS_GHC -Wall -fno-warn-orphans #-} 
---------------------------------------------------------------------- 
-- | 
-- Module  : FRP.Reactive.Fun 
-- Copyright : (c) Conal Elliott 2007 
-- License  : GNU AGPLv3 (see COPYING) 
-- 
-- Maintainer : [email protected] 
-- Stability : experimental 
-- 
-- Functions, with constant functions optimized, with instances for many 
-- standard classes. 
---------------------------------------------------------------------- 

module FRP.Reactive.Fun (Fun, fun, apply, batch) where 

import Prelude hiding 
    (zip, zipWith 
#if __GLASGOW_HASKELL__ >= 609 
       , (.), id 
#endif 
) 
#if __GLASGOW_HASKELL__ >= 609 
import Control.Category 
#endif 

そして、私がテストに使用しているコード:

*Search> f <- parseFile "/tmp/file.hs" 
*Search> f 
ParseFailed (SrcLoc {srcFilename = "/tmp/file.hs", srcLine = 19, srcColumn = 1}) "Parse error: ;" 

問題は、CPP、条件付きセクションのように見えるが、それはCPPがsupported extenstionであることが表示されます。私はhaskell-src-exts-1.11.1とghcを使用しています7.0.4

私はちょっとした分析をしようとしているので、解析する前にこれらのセクションを取り除いても構いませんが、より良い解決策が歓迎されます。

答えて

1

おそらくcpphsを使用してプリプロセッサステートメントを最初に評価しますか?

また、それはからコピーされた(そして拡張された)既知の拡張リストです。Cabal; haskell-src-exts doesn't support CPP。

+0

ああ、私はリンク先のドキュメントを読んでいると思います。そして私はそのバグレポートを見ましたが、バグが1.9.xで解決されたと誤解しました。なぜhaskell-src-extsが 'cpphs'に依存しているのか教えてください。(私はコードを見ても不思議ではありません) – jberryman

+0

@ jberrymanこれはcpphsの 'Language.Preprocessor.Unlit'モジュールを使ってLiterate Haskellソースを読み込みます。 – ivanm

関連する問題