Build representer

[ErikSchierboom]

In Exercism v3, we're introducing a new (optional) tool: the representer. The goal of the representer is to take a solution and returning a representation, which is an extraction of a solution to its essence with normalized names, comments, spacing, etc. but still uniquely identifying the approach taken. Two different ways of solving the same exercise must not have the same representation.

Each representer is track-specific. When a new solution is submitted, we run the track's representer, which outputs two JSON files that describe the representation.

Once we have a normalized representation for a solution, a team of vetted mentors will look at the solution and comment on it (if needed). These comments will then automatically be submitted to each new solution with the same representation. A notification will be sent for old solutions with a matching representation.

The representer is an optional tool though, which means that if a track does not have a representer, it will still function normally.

Goal

Build a representer for your track according to the spec. Check this page to help you get started with building a representer.

Note that the simplest representer is one that merely returns the solution's source code.

It can be very useful to check how other tracks have implemented their representer.

If your track already has a working representer, please close this issue and ensure that the .status.representer key in the track config.json file is set to true.

Choosing between representer and analyzer

There is some overlap between the goals of the representer and the analyzer. If you want to build both, we recommend starting by building the representer for the following reasons:

• Representers are usually (far) easier to implement
• Representers can have a far bigger impact on the mentoring load than analyzers by empowering mentors
• Representers apply to all exercises, whereas analyzers usually target specific exercises or a subset

Tracking

exercism/v3-launch#52

[guygastineau]

Oh, neat idea. We often get some wild a** formatting from student who aren't familiar with scheme. Luckily for scheme it is really easy to do this kind of thing, so I think we can get a representer working pretty easily. I do think it is good for the students to get feedback about their formatting. Scheme/Lisp formatting conventions are usually enforced by the editor, because no one actually wants to manage all the parentheses anyway; that said, we have for any lisp situations where indention should be 1 space, 2 spaces, and aligned with the other siblings. This makes for a somewhat unusual formatting ideal in the contemporary climate. It is still easy to format things this way no matter how the student has formatted their code, because S-Expressions are so normalized already, but I hope the students don't miss out on some important lessons about formatting. Many students who aren't already using emacs don't get the formatting right. Will there be a way for the student to see the normalized representation, so they might learn how well-formatted scheme looks?

[ErikSchierboom]

Representations created by the representer are never shown to the student, they're just there to help determine whether two solutions are to be considered equivalent. If so, we can add comments to the representation and have them apply to all solutions that end up with that exact representation.