MORPH
SIGN IN SIGN UP
kanaka / mal UNCLAIMED

mal - Make a Lisp

0 0 1 Assembly
Normal View History Raw
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
#include "MAL.h"
#include "Environment.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");
static malBuiltIn::ApplyFunc
Revert { X } -> ( hash-map X ) reader macro The macro breaks the step 2 tests.
2015-03-28 15:08:25 +11:00
builtIn_add, builtIn_sub, builtIn_mul, builtIn_div;
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
int main(int argc, char* argv[])
{
String prompt = "user> ";
String input;
c++11: step 3
2015-03-27 11:03:28 +11:00
malEnvPtr replEnv(new malEnv);
replEnv->set("+", mal::builtin("+", &builtIn_add));
replEnv->set("-", mal::builtin("-", &builtIn_sub));
replEnv->set("*", mal::builtin("+", &builtIn_mul));
replEnv->set("/", mal::builtin("/", &builtIn_div));
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
while (s_readLine.get(prompt, input)) {
String out;
try {
out = rep(input, replEnv);
}
catch (malEmptyInputException&) {
continue; // no output
}
catch (String& s) {
out = s;
};
std::cout << out << "\n";
}
return 0;
}
c++11: step 3
2015-03-27 11:03:28 +11:00
String rep(const String& input, malEnvPtr env)
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 PRINT(EVAL(READ(input), env));
}
malValuePtr READ(const String& input)
{
return readStr(input);
}
c++11: step 3
2015-03-27 11:03:28 +11:00
malValuePtr EVAL(malValuePtr ast, malEnvPtr env)
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
{
Merge eval-ast and macro expansion into EVAL, add DEBUG-EVAL See issue #587. * Merge eval-ast and eval into a single conditional. * Expand macros during the apply phase, removing lots of duplicate tests, and increasing the overall consistency by allowing the macro to be computed instead of referenced by name (`((defmacro! cond (...)))` is currently illegal for example). * Print "EVAL: $ast" at the top of EVAL if DEBUG-EVAL exists in the MAL environment. * Remove macroexpand and quasiquoteexpand special forms. * Use pattern-matching style in process/step*.txt. Unresolved issues: c.2: unable to reproduce with gcc 11.12.0. elm: the directory is unchanged. groovy: sometimes fail, but not on each rebuild. nasm: fails some new soft tests, but the issue is unreproducible when running the interpreter manually. objpascal: unreproducible with fpc 3.2.2. ocaml: unreproducible with 4.11.1. perl6: unreproducible with rakudo 2021.09. Unrelated changes: Reduce diff betweens steps. Prevent defmacro! from mutating functions: c forth logo miniMAL vb. dart: fix recent errors and warnings ocaml: remove metadata from symbols. Improve the logo implementation. Encapsulate all representation in types.lg and env.lg, unwrap numbers. Replace some manual iterations with logo control structures. Reduce the diff between steps. Use native iteration in env_get and env_map Rewrite the reader with less temporary strings. Reduce the number of temporary lists (for example, reverse iteration with butlast requires O(n^2) allocations). It seems possible to remove a few exceptions: GC settings (Dockerfile), NO_SELF_HOSTING (IMPLS.yml) and step5_EXCLUDES (Makefile.impls) .
2022-01-10 00:15:40 +01:00
// std::cout << "EVAL: " << PRINT(ast) << "\n";
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->eval(env);
}
String PRINT(malValuePtr ast)
{
return ast->print(true);
}
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 op, malValueIter argsBegin, malValueIter argsEnd)
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
{
const malApplicable* handler = DYNAMIC_CAST(malApplicable, op);
Split ASSERT into ASSERT and MAL_CHECK/MAL_FAIL * ASSERT is to check for internal errors * MAL_CHECK / MAL_FAIL is to check mal code errors
2015-03-28 22:54:26 +11:00
MAL_CHECK(handler != NULL,
"\"%s\" is not applicable", op->print(true).c_str());
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
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
return handler->apply(argsBegin, argsEnd);
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
}
#define ARG(type, name) type* name = VALUE_CAST(type, *argsBegin++)
#define CHECK_ARGS_IS(expected) \
checkArgsIs(name.c_str(), expected, std::distance(argsBegin, argsEnd))
#define CHECK_ARGS_BETWEEN(min, max) \
checkArgsBetween(name.c_str(), min, max, std::distance(argsBegin, argsEnd))
static malValuePtr builtIn_add(const String& name,
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
malValueIter argsBegin, malValueIter argsEnd)
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
{
CHECK_ARGS_IS(2);
ARG(malInteger, lhs);
ARG(malInteger, rhs);
return mal::integer(lhs->value() + rhs->value());
}
static malValuePtr builtIn_sub(const String& name,
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
malValueIter argsBegin, malValueIter argsEnd)
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
{
int argCount = CHECK_ARGS_BETWEEN(1, 2);
ARG(malInteger, lhs);
if (argCount == 1) {
return mal::integer(- lhs->value());
}
ARG(malInteger, rhs);
return mal::integer(lhs->value() - rhs->value());
}
static malValuePtr builtIn_mul(const String& name,
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
malValueIter argsBegin, malValueIter argsEnd)
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
{
CHECK_ARGS_IS(2);
ARG(malInteger, lhs);
ARG(malInteger, rhs);
return mal::integer(lhs->value() * rhs->value());
}
static malValuePtr builtIn_div(const String& name,
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
malValueIter argsBegin, malValueIter argsEnd)
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
{
CHECK_ARGS_IS(2);
ARG(malInteger, lhs);
ARG(malInteger, rhs);
Split ASSERT into ASSERT and MAL_CHECK/MAL_FAIL * ASSERT is to check for internal errors * MAL_CHECK / MAL_FAIL is to check mal code errors
2015-03-28 22:54:26 +11:00
MAL_CHECK(rhs->value() != 0, "Division by zero"); \
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 mal::integer(lhs->value() / rhs->value());
}
Reference in New Issue Copy Permalink