Add warning about implementing challenges in mainline code

Problem: if you are an overachiever and implement a bunch of the "challenges", it often makes it very hard to follow along with the rest of the book, especially if you don't know what's coming and what to watch out for.

I've followed through the book twice now (and I have a Java, Kotlin, Python, C++, and C version of something Lox-ish, all kind of modified monstrosities).

Each time I've implemented almost all of the challenges every time (usually a different way each time -- because its fun and I like to learn and practice) and every time I've kind of regretted it.

That is to say, I've regretted keeping the challenge modifications in my version when moving on to the next chapter. I stuck with it, and powered through, but oh my ... it was so exhausting ... so filled with regret ... why do I keep doing this to myself ...

I didn't do this, but I now WISH I'd have implemented the challenges on a branch just to learn something, and then reverted back to the mainline for actual working through the book.

I could give lots of examples of various things I added in various versions (ULEB128 encoded opcode constants, additional functional application syntax, argument spread operators, indent-only syntax, ...) but let me just say, I think a disclaimer like this in the challenge section(s) would be appreciated:

"Note that if you implement challenges that change the language syntax or its behavior, you may have a more difficult time following along with the book. You may want to implement these challenges in a branch or copy, and follow along with a boring "vanilla" version." -- Obviously if you add something like this you'll actually write it some other way fun or humorous way in your amazing writing style. =)

munificent / craftinginterpreters

Add warning about implementing challenges in mainline code #701