2016-07-16 13 views
10

Zauważyłem, że GHC (powszechnie używany kompilator Haskell) ma pakiet testowy napisany w Pythonie, a nie w Haskell (jak naiwnie oczekiwałbym). Jaka jest historia tego? Czy zapisywanie zestawu testów w innym języku ma szczególne zalety?Dlaczego zestaw testów GHC jest napisany w języku Python, a nie w Haskell?

edytuj: Za sugestię w komentarzach, poprosiłem o to w /r/haskell. Obecnie generowane trzy odpowiedzi, które mam podane poniżej:

tathougies powiedział:

Test kierowca pakiet wydaje się być napisany w Pythonie. Python jest dobrym językiem skryptowym wysokiego poziomu.

To jak pytanie "dlaczego GHC używa Make zamiast haskell"? Prawdopodobnie dlatego, że make jest lepszy w uruchamianiu programów powłoki z wbudowaną zewnętrzną rozdzielczością zależności.

Same testy wydają się być napisane w Haskell, weryfikując pewne właściwości kompilatora i łapiąc regresje. Jeśli się nie powiedzie, wygląda na to, że sterownik Pythona jest informowany, a następnie zgłosiłby błąd użytkownikowi.

phadej dodania:

FWIW GHC wbudowany system jest przepisany do korzystania z biblioteki drgania: Haskell.

eacameron powiedział:

nie wiem. Ale GHC nie ma luksusu używania Haskella w taki sam sposób jak ty i ja. Musi bootstrap używać poprzedniej wersji samego siebie i chce uniknąć zależności. Python jest wymaganie dość lekki, ponieważ większość systemów (z wyjątkiem Windows) wyposażone jest zbudowany w

+12

Głosuję, aby zamknąć to pytanie jako nietypowe, ponieważ w ogóle nie chodzi o programowanie. Jeśli są ciekawi decyzji podejmowanych przez zespół GHC, zapytaj ich na swojej liście mailingowej. –

+3

lub zapytaj [/r/haskell] (http: //reddit.com/r/haskell) lub [listę adresową Haskell-Cafe] (https://groups.google.com/forum/#!forum/haskell- kawiarnia) – ErikR

+6

Myślę, że byłoby rozsądniej przenieść to pytanie do programistów.SE niż po prostu je zamknąć. Jest to uzasadnione pytanie dotyczące inżynierii oprogramowania, ale tylko poza zakresem SO. –

Odpowiedz

4

commit wiadomość wprowadzenie Python tłumaczy go dużo.

zreorganizować ramy, zestawu testowego. Poprzedni framework był eksperymentem , który nieco stracił kontrolę - zupełnie nowy język z tłumaczem napisanym w Haskell był raczej ciężki i pozostawił nam problem konserwacyjny.

Nowy testowy sterownik został napisany w języku Python. Wadą jest to, że potrzebujesz Pythona do uruchomienia testsuite, ale nie uważamy, że jest to zbyt duży problem, ponieważ dotyczy on tylko programistów, a Python instaluje ładne łatwo na wszystkie te dni.

Highlights:

  • 790 linii Python vs. 5300 linie Haskell + 720 linii < obcym konfekcjonowanego języku >.

  • framework umożliwia uruchamianie testów na różne "sposoby", które powinny złapać więcej błędów. Domyślnie każdy test jest uruchamiany na trzy sposoby: normalny, -O i -O -kasm. Dodatkowo, jeśli zostały utworzone biblioteki profilowania , dodano inny sposób (-O -prof -auto-all). Planuję , aby również dodać sposób "GHCi".

    Przeprowadzenie testów na wiele sposobów pokazało już kilka nowych błędów!

  • Dokumentacja znajduje się w pliku README i jest nieco ulepszona.

  • Ramy są raczej mniej specyficzne dla GHC i mogą być bez trudu przenoszone na inne kompilatory. Większość specyficzności GHC znajduje się w osobnym pliku konfiguracyjnym (config/ghc).

Może zaistnieć potrzeba czasu na osiedlenie się. Oczekuj nieoczekiwanych niepowodzeń .

Powiązane problemy