New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Made Evaluator a trait #14
Made Evaluator a trait #14
Conversation
Looks reasonable to me! Comments:
|
Also, do you want to talk about what "other evaluators" means for you? It would be helpful to know so we don't work cross purposes. I have my own ideas for what "other evaluators" means =P |
I made some bigger changes (abstracting My goal would be to plug kernels from my project Jove, https://github.com/jove-sh/jove (it underwent major refactoring and modularization since last public commit, although it should work as is - I'll push these changes and make a first public announcement about it very soon). Hopefully, the spark interpreter from it should work straight away. |
Cool. I'm probably going to have to put off reviewing until tonight when I get back from work. |
Quick question: Why do you put the |
FWIW Splitting out the compiler, preprocessor and evaluator traits are uncontroversial and I can merge that separately if you want |
I think I know why you wanted to stuff everything into |
Thanks, I'll have a closer look at the last changes, and will actually try to plug in my own interpreters one way or another, later today. Let's put this PR on hold. The new |
Closing this for now |
Hi,
I'm thinking about plugging some other evaluators on your repl. For that, this PR tries to abstract away the
Evaluator
API. Would you be ok with keeping a distinctEvaluator
trait like this? Ideally, with no too low level methods on it, likeevalClass
and the like.