2014-04-10 30 views

Odpowiedz

8

Komentarz powyżej tej funkcji daje wskazówkę:

-- Assertion function. This simply ignores its boolean argument. 
-- The compiler may rewrite it to @('assertError' line)@. 

Tak, wystarczy użyć kodu GitHub szukanie i wyszukać assertError: search results

To podkręca plik RnExpr.lhs. Szukając dochodzić w tym pliku, znajdziesz następujący kod:

finishHsVar :: Name -> RnM (HsExpr Name, FreeVars) 
-- Separated from rnExpr because it's also used 
-- when renaming infix expressions 
-- See Note [Adding the implicit parameter to 'assert'] 
finishHsVar name 
= do { this_mod <- getModule 
     ; when (nameIsLocalOrFrom this_mod name) $ 
     checkThLocalName name 

     ; ignore_asserts <- goptM Opt_IgnoreAsserts 
     ; if ignore_asserts || not (name `hasKey` assertIdKey) 
     then return (HsVar name, unitFV name) 
     else do { e <- mkAssertErrorExpr 
       ; return (e, unitFV name) } } 

To gdzie zastępuje assert przez assertError, ale tylko wtedy, gdy twierdzenia są włączone. assertError jest zdefiniowany w GHC.IO.Exception

+1

Interesujące. Czy istnieje powód, dla którego nie można tego zrobić w sposób bardziej ogólny? Sądzę, że wyraźniejsza "pragmatyczna" zasada pakowana w preprocesorową magię, która testuje dla opcji ignorowania GHC, będzie łatwiejsza do naśladowania. – dfeuer

+2

@dfeuer To byłoby łatwiejsze do naśladowania, ale ghc przepisuje również assert na 'assertError' + informacje o lokalizacji. Próba "RULE" nie może uzyskać tej informacji o lokalizacji. Nie jestem nawet pewien, czy pragma 'RULE' może sprawdzić flagi optymalizacji GHC. – bennofs

+1

Sugerowałem, że 'REGUŁA' powinna być kompilowana warunkowo na podstawie flagi. Nie wiem, czy to możliwe, ale jest to coś, co nawet CPP może poradzić sobie w niektórych sytuacjach. Informacje o lokalizacji wydają się generalnie przydatne - dlaczego nie magiczna funkcja "lokalizacji", która rozszerza się do informacji o miejscu, w którym się pojawia? – dfeuer