stubs: Add explicit arguments to functions (good for git practice)

[rbasso]

As discussed in #459, it seems to be a good idea to add explicit arguments to all the stub solutions, because...

• It complements the type signature, documenting what the arguments are.
• It is easier for beginners that are not yet used to pointfree style programming.

For example, in the following code,

sayHello :: String -> String
sayHello = error "You need to implement this function."

... it is not immediately clear what the argument for the function is. Adding an explicit argument solves the problem:

sayHello :: String -> String
sayHello name = "You need to implement this function."

Sometimes, the meaning is obvious and generic argument names can be used:

concatenate :: [a] -> [a] -> [a]
concatenate xs ys = "You need to implement this function."

Considering that this is a great opportunity to expose students to good argument naming practices, we should be extremely careful when choosing the argument names. This is how I usually try to name the arguments:

• First I try to choose a name that help documenting the functions.
• If a more descriptive name is not possible or for some reason undesirable, I use generic argument names, trying to follow what I usually see in the Prelude:
  • x, y and z for arguments of the same type.
  • xs, ys and zs for lists and strings.
  • xss, yss, zss for lists of lists.
  • f, g and h for functions.
  • p for functions that return a Bool.

Below there is a list of exercises that do not have yet explicit arguments in the stubs. The changes are kind of trivial, so this is a good opportunity for anyone trying to get used to git:

• accumulate
• allergies
• anagram
• atbash-cipher
• bank-account
• binary-search-tree
• binary (deprecated)
• bob
• bowling
• clock
• connect
• crypto-square
• custom-set
• difference-of-squares
• etl
• forth
• gigasecond (deprecated)
• go-counting
• grade-school
• grains
• hamming
• hexadecimal (deprecated)
• kindergarten-garden
• largest-series-product
• lens-person
• linked-list
• list-ops
• luhn
• matrix
• minesweeper
• nth-prime
• nucleotide-count
• ocr-numbers
• octal (deprecated)
• pascals-triangle
• phone-number
• pig-latin
• pov
• prime-factors
• pythagorean-triplet
• queen-attack
• raindrops
• rna-transcription
• robot-name
• robot-simulator
• roman-numerals
• run-length-encoding
• saddle-points
• say
• scrabble-score
• secret-handshake
• sgf-parsing
• sieve
• simple-cipher
• simple-linked-list
• strain
• sublist
• sum-of-multiples
• triangle
• trinary (deprecated)
• wordy
• zebra-puzzle
• zipper

Feel free to open a pull requests to fix any exercise in this list, but please use an informative title, like this:

exercise-name: Add explicit arguments to the stub functions

[lpalma]

would you prefer to leave this issue to be gradually solved by newcomers, or would it be ok solve many in a single PR?

[rbasso]

At first the idea was to leave it for newcomers but, besides some people I personally asked and oriented, it seems there is no demand for that.

Feel free to solve as many as you want! 👍

The only thing I think may be a good idea is to make a commit per exercise. What do you think?

[lpalma]

yeah a commit per exercise seems the way to go 👍

[rbasso]

@petertseng wrote:

Do we want to cover deprecated exercises too as part of #473?

Sorry for that. Sometimes I forget that we have deprecated exercises, because it seems that we cannot remove them from the repository. Feel free to skip or change them, @lpalma!

The list of deprecated exercises is in the config.json:

• binary
• gigasecond
• hexadecimal
• octal
• trinary

[petertseng]

I have appended "(deprecated)" to those five in the list.