stubs: Default implementations for functions

[rbasso]

Currently, most, if not all, the exercises have stub solutions that have the form:

foo :: ...
foo = undefined

This is great, but the are two minor probems:

• A beginner student may not see immediately that it needs to implement that function.
• The error message returned from the test suite may be a little confusing:

leap
  isLeapYear
    1996 - leap year FAILED [1]

Failures:

  test/Tests.hs:18: 
  1) leap.isLeapYear 1996 - leap year
       uncaught exception: ErrorCall (Prelude.undefined
       CallStack (from HasCallStack):
         error, called at libraries/base/GHC/Err.hs:79:14 in base:GHC.Err
         undefined, called at src/LeapYear.hs:4:19 in leap-0.0.0-4uYVmwBGJQhBRFIbJzqiyG:LeapYear)

An alternative would be to use error with a custom message...

foo = error "You need to implement this function."

... which is clearer in the source code and gives a slightly better error message:

leap
  isLeapYear
    1996 - leap year FAILED [1]

Failures:

  test/Tests.hs:18: 
  1) leap.isLeapYear 1996 - leap year
       uncaught exception: ErrorCall (You need to implement this function.
       CallStack (from HasCallStack):
         error, called at src/LeapYear.hs:4:19 in leap-0.0.0-4uYVmwBGJQhBRFIbJzqiyG:LeapYear)

Another options would be to use...

foo = errorWithoutStackTrace "You need to implement this function."

... which is not so beautiful in the source code, but gives the best error message:

leap
  isLeapYear
    1996 - leap year FAILED [1]

Failures:

  test/Tests.hs:18: 
  1) leap.isLeapYear 1996 - leap year
       uncaught exception: ErrorCall (You need to implement this function.)

So, which of the three solutions is better? What would be the best message to use?

[petertseng]

Well the stack trace is still somewhat useful, right? Since the line number shows which function we need to implement. I wouldn't mind keeping it. So my leading option is error "You need to implement this function.".

[rbasso]

Another related question!

Should we also provide variable names in the stub implementations?

For example, instead of ...

isLeapYear = error "You need to implement this function."

...we could write...

isLeapYear year = error "You need to implement this function."

[petertseng]

I looked for past discussions of "eta" and got:

• I expressed naming the arg explicitly, and you agree at parallel-letter-frequency: Rewrite tests to use hspec with fail fast. #299 (comment)
• You suggest always eta-abstracting in leap: Add variable to stub solution's signature. #404.

I'm basically going to agree with what we thought in the past. I support explicitly naming the variables.

• It makes it clear what each argument is.
• A student who wishes to eta-reduce is still free to do so.
  • We don't explicitly say "you're free to eta-reduce", but we also don't say "you can't change the signatures", so there's no explicit permission nor restriction.
  • Hopefully students do figure out it's allowed.
  • If they're not, maybe we have to add a note explaining the possibility. I have a hard time figuring out where the note would go...

[petertseng]

With #471, this is now complete, right?

[petertseng]

Oh, I suppose explicitly naming the variables?

[rbasso]

Oh, I suppose explicitly naming the variables?

Yeah!