3
votes

I have many files that must be processed automatically. Each file holds the response of one student to an exercise which asks the student to give definitions for some functions given a type for each function.

My idea is to have an Haskell script that loads each student file, and verifies if each function has the expected type.

A constraint is that the student files are not defined as modules.

How can I do this?

My best alternative so far is to spawn a GHCi process that will read stdin from a "test file" with GHCi commands, for example:

:load student1.hs
:t g
... and so on ...

then parse the returned output from GHCi to find the types of the functions in the student file.

Is there another clean way to load an arbitrary Haskell file and introspect its code?

Thanks

5
1) You can't. Types don't exist at runtime. — 2) that should be possible, I suppose. But in what form would you want that “variable“ to be? A TypeRep, or rather just something like type Bla = {-# TYPEOF f #-}? - leftaroundabout
@leftaroundabout See my update in the question's text. - mljrg
What do you want this for? Maybe there's some other way to achieve your goal. - MathematicalOrchid
@MathematicalOrchid See my comment to "soupi" below for the reasons I want this. - mljrg
@mljrg You should probably edit that into the question. Knowing that you're trying to grade exam submissions makes this question a lot more sensible than it otherwise appears. - MathematicalOrchid

5 Answers

9
votes

Haskell does not save type information at runtime. In Haskell, types are used for pre-runtime type checking at the static analysis phase and are later erased. You can read more about Haskell's type system here.

Is there a reason you want to know the type of a function at runtime? maybe we can help with the problem itself :)

Edit based on your 2nd edit:

I don't have a good solution for you, but here is one idea that might work:

Run a script that for each student module will:

  1. Take the name of the module and produce a file Test.hs:

    module Test where

    import [module-name]

    test :: a -> b -> [(b,a)]
    test = g
  1. run ghc -fno-code Test.hs
  2. check the output does not contain type errors
  3. write results into a log file
5
votes

I think if you have a dynamically determined number of .hs files, which you need to load, parse and introspect, you could/should use the GHC API instead.

See for example:

These might not be something you can use directly — and I haven't done anything like this myself so far either — but these should get you started.

See also:

1
votes

The closest Haskell feature to that is Data.Typeable.typeOf. Here's a GHCi session:

> import Data.Typeable
> typeOf (undefined :: Int -> Char)
Int -> Char
> typeOf (undefined :: Int -> [Char])
Int -> [Char]
> typeOf (undefined :: Int -> Maybe [Char])
Int -> Maybe [Char]
> :t typeOf
typeOf :: Typeable a => a -> TypeRep

Under the hood, the Typeable a constraint forces Haskell to retain some type tags until runtime, so that they can be retrieved by typeOf. Normally, no such tags exist at runtime. The TypeRep type above is the type for such tags.

That being said, having such information is almost never needed in Haskell. If you are using typeOf to implement something, you are likely doing it wrong.

If you are using that to defer type checks to run time, when they could have been performed at compile time, e.g. using a Dynamic-like type for everything, then you are definitely doing it wrong.

1
votes

If the function is supposed to be exported with a specific name, I think probably the easiest way would be to just write a test script that calls the functions and checks they return the right results. If the test script doesn't compile, the student's submission is incorrect.

The alternative is to use either the GHC API (kinda hard), or play with Template Haskell (simpler, but still not that simple).

1
votes

Yet another possibility is to load the student's code into GHCi and use the :browse command to dump out everything that's exported. You can then grep for the term you're interested in. That should be quite easy to automate.

There's a catch, however: foo :: x -> x and foo :: a -> a are the same type, even though textually they don't match at all. You might contemplate trying to normalise the variable names, but it's worse: foo :: Int -> Int and foo :: Num x => x -> x don't look remotely the same, yet one type is an instance of the other.

...which I guess means I'm saying that my answer is bad? :-(