6 ms·
I should have read the InfoQ article more carefully. If you had a Frege -> Haskell translator, which shouldn't be hard to do, except in edge cases, you could
by mafribe 11y ago
I should have read the InfoQ article more carefully.
If you had a Frege -> Haskell translator, which shouldn't be hard to do, except in edge cases,
you could use GHC as a testing oracle for the Frege compiler.
- voxfrege 11y agoYes, I have often considered how I could employ GHC, for example. But it turns out, as always, that the devil is in the details. Ideally, one would think you could get away with just writing another backend and implementing another FFI calling convention for the JVM. Yet, projects like LambdaVM that pursue this approach are stalled or given up completly. The difficulties are clearly stated in the Hasell wiki here https://wiki.haskell.org/GHC:FAQ#Why_isn.27t_GHC_available_for_.NET_or_on_the_JVM.3F https://wiki.haskell.org/GHC:FAQ#Why_isn.27t_GHC_available_f...
- mafribe 11y agoI mean something simpler, and doesn't involve retargetting GHC. Write a Frege-to-Haskell compiler F2H, and then for each test T you simply compare the output of running Frege( T ) with the output of running GHC( F2H( T ) ). Maybe you have to transform the outputs into a universal format such as ASCII strings, but that should be straightforward. Now you have an oracle for random Frege programs.