noting places where I have difficulty in first two modules

141 views
Skip to first unread message

John Owens

unread,
Sep 15, 2014, 4:39:55 PM9/15/14
to haskell-...@googlegroups.com
Thanks to those who wrote these series of exercises; they're very different than other exercises I've tried; as I note the exercises are still being updated, thought I'd note the places where I got stuck, in hopes that a little more guidance in the source file might help others from being stuck.

1) By far (for me) the hardest exercise in List was seqOptional. A hint to look at foldRight would have been germane.

2) In Functor, the "reader" functor problem ("Maps a function on the reader ((->) t) functor.") is quite confusing, since I don't know what "reader" is or does. The example makes sense, but doesn't use the "(->) t" syntax, so that's still opaque. Any other code in the whole distribution that uses this syntax appears to be in later modules.

In hopes that this will help future students (and me),

Thanks!

JDO

Tony Morris

unread,
Oct 15, 2014, 12:07:15 AM10/15/14
to haskell-...@googlegroups.com
1) I think using foldRight is not worth a hint. A lot of exercises are possible by using foldRight (or foldLeft), however, to suggest it is a correct or hint-worthy aspect has the potential to take away some value from others who might have otherwise solved it more independently. This is to say, hints are not free. This can be understood with an exaggeration, whereby a hint is given that is simply the answer -- yes, it makes arriving at the answer much easier, but that is not the goal -- the goal is to form new ideas and skills by which to arrive at solutions. I think foldRight is not an economical mechanism here, precisely because of the theoretical nature of foldRight (that it is essentially, the list structure catamorphism). Providing hints must be carefully analysed for value.

2) Typically, as part of the course application, we perform an introduction to syntax. This usually goes for 3 or so hours. In that time, we learn the syntax of infix and prefix notation for operators. Once it is established that (t -> a) is simply syntax for ((->) t a) and then it is also established that All Haskell Functions Take One Argument[1], it becomes a simple matter of reinforcing these rules. "All Haskell functions" in this context includes type constructor functions.

For example, "all type constructors take one argument." Given this and the fact that (->) is a type constructor, we can conclude that it takes one argument. We can then ask, what does it return? The answer is, a type constructor. What do type constructors do? They take one argument. Given that argument, what does it return? A type.

Establishing and reinforcing these rules is typically part of the course, which is difficult to express in the code itself. I know of no good way to alleviate that, except perhaps "online videos" or similar. In the meantime, I will just keep saying the rules.

1. All Haskell functions take one argument.
2. Haskell has some basic syntax rules with respect to infix and prefix functions.

From these two rules, the answer follows.

[1] http://tonymorris.github.io/blog/posts/haskell-functions-take-one-argument/index.html

John Owens

unread,
Oct 15, 2014, 12:13:46 AM10/15/14
to haskell-...@googlegroups.com
I appreciate the thoughtful reply, and will ponder it when I return to these exercises. I fully understand that it takes way longer to write such a reply than to give a hint or check one into the repo. So thanks.

JDO
Reply all
Reply to author
Forward
0 new messages