Select featured exercises for Summer of Sexps

Exercism
21

Works for me :slight_smile:

1 Like
22

Okay, we’ll go with:

leap : boolean conditions, truthiness, possible lexical scoping due to nested helper function, good introduction to Lisp syntax
two-fer : optional values, handled differently across the tracks
difference-of-squares : math/prefix notation, ranges
robot-name : randomness, strings and potentially OO
matching-brackets : strings as lists of characters

1 Like
23

Are you suggesting this exercise should have the student implement map? With map? recursion? iteration?

Perhaps if you could give me an idea of what you think this exercise would look like for Common Lisp I could see the benefit.

And what level of student of Common Lisp would we need to target? Would we expect them to understand recursion or do/loop constructs?

24

This demands dealing with mutable state in Clojure. It needs atoms etc. Definitely not for beginners. Are you sure?

Edit: Maybe any of the following?

  • Run-Length Encoding (strings)
  • Binary Search Tree
  • Flatten Array (recursion, lazy-seq)
  • Perfect Numbers
  • Robot Simulator (maps, reduce)
  • Binary search

If i’m not mistaken, the last two were previously featured.

25

That’s true. The idiomatic solution doesn’t look that difficult to me, but I don’t know. @porkostomus what do you think?

26

robot-name would be fine. Atoms are really simple, and very important too :slight_smile:

1 Like
27

Great. Let’s keep robot-name then. I really like that students have to use atoms and that it shows that Lisps are not just purely functional languages.

28

Since we already decided on a different exercise it’s not important / doesn’t have urgency for Summer of Sexps now.

Are you suggesting this exercise should have the student implement map? With map? recursion? iteration?

The idea of the exercise is for students to not use the built-in list-ops. Otherwise it doesn’t matter how they implement it.

These are the benefits I see in this exercise:

  • good way for students to feel really comfortable using functions like map and fold/reduce is implementing them themselves, students develop a better mental model of what’s going on under the hood. especially fold often takes a while for new programmers / programmers new to FP to fully grasp.
  • students can learn that in languages with higher-order functions you can implement list iteration in terms of the primitives foldl and foldr
  • students can learn that you don’t have to implement foldl and foldr recursively in a non-pure language. it might even be the way to go in a language without tail-call elimination. (to that end I’ve included bonus tests in the Emacs Lisp track that lead to a stack overflow with a naive (tail-)recursive implementation, as Emacs Lisp doesn’t have automatic TCE, eg. the example implementation would fail those bonus tests)

For better or worse the instructions also don’t push students in the direction of using foldl and foldr as the base layers to implement all other operations, so students in theory can implement each operation with a hand-crafted loop. So they can solve it as long as they grasp higher-order functions. If they want to engage deeper they can request mentoring and/or check the community solutions. Although I also think that the exercise is a prime candidate for approaches / a dig deeper tab.

Hope this helps. Let me know if you have more questions. :)

29

You make a good case for it. Not sure when I’ll be getting back to adding exercises to the Common Lisp track though - but I’ll keep this one on the list.

30

For some reason robot-name is missing from the Scheme track on the website.
I see that it’s present in the github repo (but it’s marked “deprecated” in the config.json )
@ErikSchierboom I assume it got deprecated by mistake, could you please re-enable it when you get the time?
I’m surprised that there’s no canonical-data.json for robot-name in the problem-specification repo. How does that happen?

31

The problem specs usually provide tests with specific inputs and expected outputs. The robot name problem generates random outputs, which are hard to list as expected values.

32

Why would you assume this was a mistake? Does anyone have any information on why it might have been deprecated?

It’s not required for an exercise to have canonical data. As Isaac said, it is much harder to define properties that deal with randomness.

33

Only because it was listed as present in the track at the start of this discussion; I thought it was just an oversight. I have no additional information as to why it might have been deprecated.
I managed to track the change to these: PR-115 ad PR-127

but there’s no reasoning as to why it was marked deprecated.

34

Yeah, that was my mistake :D

Thanks for tracking that down. If you look at the exercise, does there seem to be anything wrong with it?

35

This doc comes to mind: Chesterton's Fence | Exercism's Docs

36

I don’t know Scheme enough to say (yet). I’ll take a look when I’m done with the track, if this doesn’t get resolved by then.

38

I did some commit log digging. Scheme: Robot Name was deprecated in this PR. It looks like iHiD beat me to this and pinged the PR for an explanation on the deprecation :D

1 Like