Skip to content

Conversation

@mdm508
Copy link

@mdm508 mdm508 commented Apr 7, 2023

No description provided.

@yugaego
Copy link
Member

yugaego commented Apr 8, 2023

Hi. I tend to think this change is not needed, due to the reasons listed below.

In Exercise 352, we are asked to design subst for the first time. The requirement states, that

The function consumes a BSL-var-expr ex, a Symbol x, and a Number v.

In the following exercises --up to Exercise 362-- it has a constant role: this is a helper function called only according to the signature given above.
Namely, in Exercise 357 we see that value passed to subst is a Number by definition (of eval-definition1).

  ((define value (eval-definition1 (fun-arg ex) f x b))
   (define plugd (subst b x value)))

And this is the same in the rest of the exercises with the subst function.

Also note that check-expect aren't failing, which confirms this is a design choice.

With this in mind, if you find a stronger argument for changing the signature, this would also require adding more check-expect expressions and most probably updating the rest of the subst function usages (see Exercises 354, 359, 361, 362).

Another approach that could probably be chosen here is to use a checked variant of the subst (type-checking the passed parameters). But only if that would improve the function's exemplary usage in the context of the chapter and wouldn't bloat the code too much.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

2 participants