MORPH
SIGN IN SIGN UP
kanaka / mal UNCLAIMED

mal - Make a Lisp

0 0 0 Assembly
Normal View History Raw
c++11: step 1
2015-03-26 22:25:50 +11:00
#include "MAL.h"
#include "ReadLine.h"
#include "Types.h"
#include <iostream>
#include <memory>
malValuePtr READ(const String& input);
String PRINT(malValuePtr ast);
static ReadLine s_readLine("~/.mal-history");
c++11: step 2 Note that the optional tests for step 1 now fail because I no longer create a hash directly in the reader, rather handle this as a reader macro: { LIST } -> ( hash-map LIST ) This way, once the constructor has built the hash-map, the hash is now evaluated, and its evaluation procedure is a no-op. I'd like to do the same with vectors, but this isn't so easy, as we use vectors as parameter lists in fn* later on. ie. we'd have this situation, which is incorrect (and I don't see an obvious workaround) (fn* [params] body) -> (fn* (vector params) body)
2015-03-27 09:04:35 +11:00
static String rep(const String& input);
static malValuePtr EVAL(malValuePtr ast);
c++11: step 1
2015-03-26 22:25:50 +11:00
int main(int argc, char* argv[])
{
String prompt = "user> ";
String input;
while (s_readLine.get(prompt, input)) {
String out;
try {
out = rep(input);
}
catch (malEmptyInputException&) {
continue; // no output
}
catch (String& s) {
out = s;
};
std::cout << out << "\n";
}
return 0;
}
c++11: step 2 Note that the optional tests for step 1 now fail because I no longer create a hash directly in the reader, rather handle this as a reader macro: { LIST } -> ( hash-map LIST ) This way, once the constructor has built the hash-map, the hash is now evaluated, and its evaluation procedure is a no-op. I'd like to do the same with vectors, but this isn't so easy, as we use vectors as parameter lists in fn* later on. ie. we'd have this situation, which is incorrect (and I don't see an obvious workaround) (fn* [params] body) -> (fn* (vector params) body)
2015-03-27 09:04:35 +11:00
static String rep(const String& input)
c++11: step 1
2015-03-26 22:25:50 +11:00
{
return PRINT(EVAL(READ(input)));
}
malValuePtr READ(const String& input)
{
return readStr(input);
}
c++11: step 2 Note that the optional tests for step 1 now fail because I no longer create a hash directly in the reader, rather handle this as a reader macro: { LIST } -> ( hash-map LIST ) This way, once the constructor has built the hash-map, the hash is now evaluated, and its evaluation procedure is a no-op. I'd like to do the same with vectors, but this isn't so easy, as we use vectors as parameter lists in fn* later on. ie. we'd have this situation, which is incorrect (and I don't see an obvious workaround) (fn* [params] body) -> (fn* (vector params) body)
2015-03-27 09:04:35 +11:00
static malValuePtr EVAL(malValuePtr ast)
c++11: step 1
2015-03-26 22:25:50 +11:00
{
return ast;
}
String PRINT(malValuePtr ast)
{
return ast->print(true);
}
c++11: step 2 Note that the optional tests for step 1 now fail because I no longer create a hash directly in the reader, rather handle this as a reader macro: { LIST } -> ( hash-map LIST ) This way, once the constructor has built the hash-map, the hash is now evaluated, and its evaluation procedure is a no-op. I'd like to do the same with vectors, but this isn't so easy, as we use vectors as parameter lists in fn* later on. ie. we'd have this situation, which is incorrect (and I don't see an obvious workaround) (fn* [params] body) -> (fn* (vector params) body)
2015-03-27 09:04:35 +11:00
// These have been added after step 1 to keep the linker happy.
c++11: step 3
2015-03-27 11:03:28 +11:00
malValuePtr EVAL(malValuePtr ast, malEnvPtr)
c++11: step 2 Note that the optional tests for step 1 now fail because I no longer create a hash directly in the reader, rather handle this as a reader macro: { LIST } -> ( hash-map LIST ) This way, once the constructor has built the hash-map, the hash is now evaluated, and its evaluation procedure is a no-op. I'd like to do the same with vectors, but this isn't so easy, as we use vectors as parameter lists in fn* later on. ie. we'd have this situation, which is incorrect (and I don't see an obvious workaround) (fn* [params] body) -> (fn* (vector params) body)
2015-03-27 09:04:35 +11:00
{
return ast;
}
Don't pass an env to apply Due to some initial confusion about which env to pass to the eval builtin, I'd been needlessly passing an env to apply all along. No need.
2015-12-14 18:06:50 +11:00
malValuePtr APPLY(malValuePtr ast, malValueIter, malValueIter)
c++11: step 2 Note that the optional tests for step 1 now fail because I no longer create a hash directly in the reader, rather handle this as a reader macro: { LIST } -> ( hash-map LIST ) This way, once the constructor has built the hash-map, the hash is now evaluated, and its evaluation procedure is a no-op. I'd like to do the same with vectors, but this isn't so easy, as we use vectors as parameter lists in fn* later on. ie. we'd have this situation, which is incorrect (and I don't see an obvious workaround) (fn* [params] body) -> (fn* (vector params) body)
2015-03-27 09:04:35 +11:00
{
return ast;
}
Reference in New Issue Copy Permalink