Description

On case xx of, enumerate changes for the returned value

Example

In the case of

head $ case list of
  [a] -> a
  _ -> list

We would be suggested to do

head $ case list of
  [a] -> [a]
  _ -> list

Description

On application, one (wildcard) argument should be added

Example

In the case of

const 1

We would be suggested to do

const 1 undefined
const undefined 1

Currently, we use a silencer to hide the error message during the GHC Session.

However, Some dynamic flags allow hiding them directly. (See doc.)

Moreover, this would make debugging easier.

Description

In let x = .., replace right-hand side with undefined.

Example

In the case of

let (a:b) = [] in ...

We would be suggested to do

let (a:b) = undefined in ...

Description

See example

Example

In the case of

a = 1 + [2, 3]

We would be suggested to do

a = 1 : [2, 3]

Some Changes come with custom messages (e.g. for if ... then ... else ... expressions).

These messages should be handled, formatted and presented to the user

Description

The do expressions need to be traversed

Example

In the case of

main :: IO ()
main = do
  return 1

We would be suggested to do

main :: IO ()
main = do
  return ()

Description

Go through where clauses: left-hand and right-hand sides

Example

In the case of

where
  (a, b) = length []

We would be suggested to do

where
  (a, b) = undefined

Seminal's workflow involved calling the compiler frequently.
We need to setup a subroutine (i.e. function) that allows us to

• Call GHC
• Pass the AST
• Retrieve the compilation status
  • Success
  • Syntax Error
  • Type Error
  • Other

• There should be a linter configuration
• There should be a related GitHub Action

There are two Haskell parsing libraries on hackage:

• The GHC API
• haskell-src-exts

These libraries are similar but have various level of complexity and the latter is less maintained

We need to decide which library to use to get the AST of the file to compile.

PoC for these libraries will be in the poc directory

Description

On If xx then .. else .., replace the condition with True.

This is a 'Wildcard' change

Example

In the case of

if length []
then True
else False

We would be suggested to do

if True
then True
else False

Description

The enumerator should try to call fromIntegral to

• convert an Integer into an Int
• convert an Int into an Integer
• Convert an Int into a Double
• Convert an Int into a Float
• Convert an Integer into a Double
• Convert an Integer into a Float
• Convert a Float into a Double
• Convert a Double into a Float

Example

In the case of

a = length []

b :: Integer
b = a

We would be suggested to do

a = length []

b :: Integer
b = fromIntegral a

Description

Example

In the case of

type A = Int

a :: A
a = ()

We would be suggested to do

type A = ()

a :: A
a = ()

Description

On application, arguments should be turned into a tuple

Example

In the case of

fst 1 2

We would be suggested to do

fst (1, 2)

We would need a CLI flag to count and print the number of calls to the typechecker that are done.

We need check that a change does not break the project (compilation, tests, etc.). To do so, we need to setup some Github Actions

• Compilation
• Unit Tests

We want better error messages than GHC's.
Suggestions are not enough, there should be a proper message with each one of them

Description

The enumerator should go through type signatures

• For each * kinds, change into
  • Int
  • Integer
  • Float
  • Double
  • String
  • Char
  • Bool
  • ()

• For each * -> * kinds (e.g. Maybe)
• Remove the first type argument (e.g. Maybe Char to Char)
• Change to IO
• Change to Maybe
• Call enumerator recursively (e.g. Maybe Int to Maybe Integer)

• For each * -> * -> * kinds (e.g. Either)
• Swap types (e.g. Either a b to Either b a)
• Call enumerator recursively

• Try to wrap into IO
• Try to remove brackets (e.g. [Char] to Char)
• Try to remove type (in the case of a type application)
• This should be done for each element of a signature
• Add Type (e.g. a to a -> _)
• Try to swap types (e.g. a -> b to b -> a)

Example

In the case of

a :: Float
a = fromIntegral 0.0 :: Double

We would be suggested to do

a :: Double
a = fromIntegral 0.0 :: Double

We would need a flag that would, for each change, print:

• The File name
• The Expression position
• The Source Expression
• The Changed expression
• The result of the change (Typecheck or not)

We need to define how the project will be structured.
According to Seminal's algorithm, it should have the following components:

• Ranker
• Enumerator
• Searcher
• GHC subroutine

Should the Searcher call the enumerator? Or Should there be a global orchestrator ?

Description

On case xx of, remove one match if there are multiple

Example

In the case of

case undefined of
  x -> undefined
  _ -> undefined

We would be suggested to do

case undefined of
  _ -> undefined

More GitHub actions could be setup to check the project's code quality

• Static Analysis
• Test coverage report (Done in d787f20)

Some changes on their own do not allow to check if the code typechecks.
Sometimes, multiple wildcard changes might allow the code to check, which would lead the AST to be traversed for each of these successful changes.

Instead of doing these changes parallelly, we should group these changes together

Description

On case match, replace match with wildcard

Example

In the case of

case [1, 2, 3] of
  1 -> undefined
  _ -> undefined

We would be suggested to do

case [1, 2, 3] of
  _ -> undefined
  _ -> undefined

In the case of

a = length 'A'

The enumerator suggest to replace length 'A' with undefined It might be related to the fact that length is overloaded.

As a solution, we should consider a new type of Wildcard: []

The expected change would be

a = length "A"

Score errors (for variables or type) happen when an import is missing or incomplete.

Seminal does not mention such case.

We need to know if a code with a reference to a variable/type not in scope should be processed

The basic implementation is supposed to handle one file at a time.

An evolved version should allow to compile multiple files that need each other

Description

The enumerator should go through operation expressions (OpApp)

Example

In the case of

a = 1 + [1]

We would be suggested to do

a = 1 + 1

Description

The enumerator should try to convert a literal string into a number.

This should be done for

• Literal Strings
• Explicit List of Literal Char

Example

In the case of

a :: Int
a = "20"
-- or a = ['2', '0']

We would be suggested to do

a :: Int
a = 20

The compilation of the program should be possible through multiple versions of GHC.
Moreover, the program should be platform independent

Description

On application, one argument should be deleted

Example

In the case of

const 1 2 3

We would be suggested to do

const 1 2
-- or
const 2 3
-- or
const 1 3

Description

On function application, arguments should be swapped

Example

In the case of

fmap [1] id

We would be suggested to do

fmap id [1]

Alongside with the suggested changes, we should also display GHC's compilation error