ch7ex13/

README

:chapter: 7
:exercise: 13
:url-base: https://github.com/fenegroni/TGPL-exercise-solutions
:url-workflow: {url-base}/workflows/Exercise {chapter}.{exercise}
:url-action: {url-base}/actions/workflows/ch{chapter}ex{exercise}.yml
:img-badge: image:{url-workflow}/badge.svg?branch=main[link={url-action}]

= Exercise {chapter}.{exercise}

{img-badge}

Add a `String` method to `Expr` to pretty-print the syntax tree.
Check that the results, when parsed again, yield an equivalent tree.

== Test

We have three options to validate the `String` method.

1. Check we get the same result from evaluating the string representation.

2. Check there is a one to one relationship between a syntax tree
and its string representation, by repeatedly parsing the string
obtained from a syntax tree.

3. Deep-compare the syntax trees resulting from
parsing the original expression string
and parsing the string representation of that syntax tree.

The first two options don't necesserily prove
the syntax trees are equivalent,
but do allow for some implementation flexibility.

The third option is the best one
but requires the sytax trees not just being equivalent,
but identical.
The test therefore becomes somewhat brittle.

There might be optimisations that would allow our syntax tree
to differ slightly yet deliver the same result when evaluated.

We will implement all three test strategies
so that you can make your own mind up
as to which one is best.


=== Option 1: Using `Eval`

The first test, `TestStringEval`, implements
the first `String` method validation strategy.

We could think of two expressions that give the same result
yet have completely different `string` representations and syntax trees.


=== New type args

We create the new type `args`
to implement the `fmt.Stringer` interface for `expr.call`.


== Option 2: Using `Parse`

The second test, `TestStringParse`, implements the second strategy
to validate the `String` method.

This has the advantage of
not requiring a call to `Eval` for each expression.


== Option 3: Deep-compare

The third test, `TestDeepCompare`, implements the third strategy
and requires the use of `reflect.DeepEqual`.