search

Feldspar / feldspar-compiler

This is the compiler for the Feldspar Language.
Other
22 stars 5 forks source link

Add decodeType. #143

Closed pjonsson closed 10 years ago

pjonsson commented 10 years ago

We are working on an "External Program" parser that will allow us to inject test cases directly into feldspar-compiler without having to go through the machinery of feldspar-language. We need to do some type reconstruction for the parser, so having decodeType available would be jolly convenient.

Please review and merge unless there are objections. The parser itself is not yet ready for merge.

emwap commented 10 years ago

Interesting. Could you elaborate on the test case injection?

Btw, have you seen the feldspar-compiler/plugins branch? There it is possible to write test cases (and QuickCheck properties) in Haskell/Feldspar and run the tests using the generated and compiled C code.

pjonsson commented 10 years ago

The scope for plugins sounds complementary to our scope/approach.

We are tackling the possibility to increase test-coverage of feldspar-compiler. There are a lot of legal (and sane, or even good) Program programs that feldspar-language does not currently generate regardless of Feldspar-input. Corner cases of transformations in feldspar-compiler are hard to test because we need to coerce feldspar-language into generating the right program, and future optimizations in feldspar-language can "break" those test cases because they change the code generated. We can save time by writing "Program programs" as our test cases for getting the coverage of feldspar-compiler, and at the same time be more coverage-resistant despite future improvements in feldspar-language. Think "External Core" in GHC, but at a lower level intermediate format and going into the compiler instead of coming out of it.

The current status of external program is that we can parse the gold files and get identical output from feldspar-compiler on all the current gold-files except for test cases that contain futures. The current code needs to be cleaned up before merging though, but it does work.

The code for decodeType is self contained, cleaned up, and low-risk since there are no in-tree consumers yet, so I figured I would pull that out and merge separately since there is a clear specification of what it should (try to) do.

emwap commented 10 years ago

Nice! That will be handy. Thanks.