3 ms·
`tokenize` function looks weird. Why use replace and then split? How would you extend this to stirngs (which might contain "()" chars)? It might be OK in a toy
by kovrik 7y ago
`tokenize` function looks weird. Why use replace and then split? How would you extend this to stirngs (which might contain "()" chars)?
It might be OK in a toy example, but it would have been better if the author wrote an actual Reader (not familiar with Rust, but I guess it should have some readers that allow peeking 1 char ahead OR something like Java's PushbackReader).
Then `parse_list_of_floats`, if I am reading it right, this function is fail-safe, not fail-fast, right? It won't panic upon the very first reading error?
Why eval makes environment lookups? Shouldn't environment itself know how to perform a lookup?
- stevekemp 7y agoIt's basically a clone of the tokenizer from this python implementation https://norvig.com/lispy.html https://norvig.com/lispy.html which was referenced in the introduction. The same code has been seen in a bunch of simple/similar lisp interpreters in different languages. To be honest I'm not sure if that was the first documented tokenizer using this simple approach, but it is definitely a common pattern for such things - and as you say it is naive at best, and buggy at worst. That said it is easy to get it working, and later fix it properly.