From olf at aatal-apotheke.de  Sat Feb  6 20:37:55 2021
From: olf at aatal-apotheke.de (Olaf Klinke)
Date: Sat, 06 Feb 2021 21:37:55 +0100
Subject: [Haskell & FP in Education] [Haskell-cafe] Haskell exercises for
	beginners
Message-ID: <68be7a82718a31003a0f00af1550549119e371e8.camel@aatal-apotheke.de>

> Hello Haskell Café,
> 
> I have been working on a website aimed at teaching programming and Computer
> Science through quick examples.  It is called "Computer Science by Example
> <https://cscx.org/>;": https://cscx.org/
> 
> The exercises start very simple (e.g. read two numbers and print their sum
> <https://cscx.org/add>;) then increase in difficulty and complexity
> gradually (e.g. solving the change-making problem <https://cscx.org/cash>;).
> The website has an "online judge" functionality where students can submit
> their solutions which are tested and graded automatically without human
> intervention.  It currently supports solutions in *Haskell* and
> additionally: Python, C, C++, C#, Java, JavaScript, Lua and Ruby.
> 
> The exercises are useful not only to first time programmers, but also to
> experienced programmers trying to learn a new language such as Haskell.
> 
> Check it out at cscx.org.  The exercises are freely available for anyone to
> try.
> 
> Best Regards,
> Rudy

Dear Rudy, 

thanks for sharing all these excercises. Automated grading has many
advantages. The kind of automated grading cscx uses lets the program
use stdin and stdout. However, for Haskell (and all other programming
languages too) this means that students are, from the very beginning,
forced to write parsers for the data the grading system gives on stdin.
This means that either 
* You limit input data to stuff with built-in parsers (which you don't)
* You teach proper parsing early, which is non-trivial, or
* You permit the students develop an ad-hoc and potentially messy style
of coping with unstructured input. 

In all the excercises I looked at, the grading specification does not
say what the program should do with invalid input. Therefore messy ad-
hoc parsing is what you should expect to see in, and in some cases
comprise the largest part of, submitted solutions. Others may disagree
whether this is to be prevented or not. I have limited experience in
teaching. 

In some other CS courses the excercises give a program fragment which
is to be completed by the student. In Haskell you could use property-
based testing [1] like QuickCheck or doctests to do the heavy lifting
for you, while at the same time presenting the students with an
infinity of test cases. 
Another way might be to provide a random generator of structured test
data, and the student's task is to write a program that echoes the
random data together with the computed result. That way, you could
still use the stdout-based automated grading. 

Example of QuickCheck-based grading:

module Triple1 where
--  Your task: Complete this function 
-- so that for example
--
-- >>> triple 2
-- 6
-- >>> triple 123
-- 369
triple :: Integer -> Integer
triple = undefined
-- Automated grading appends the following and runs
-- quickCheck prop_triple
prop_triple :: Integer -> Bool
prop_triple = triple n == 3*n

Example of Random-based grading:

module Triple1 where
-- Your task: complete this function
-- so that for example
-- 
-- >>> pure 2 >>= triple
-- 2
-- 6
triple :: Integer -> IO ()
triple n = do
  print n
  undefined
-- Automated grading compiles
-- main = (yourIntegerGenerator :: IO Integer) >>= triple
-- and executes repeatedly. 


Kind regards
Olaf

[1] 
https://www.cs.tufts.edu/~nr/cs257/archive/john-hughes/automatic-grading.pdf