I added the exclusion as a hack to work around classpath
issues after importing the project into Eclipse, but this
isn't the right thing to do.
It prevents compilation on JDKs other than Graal, which was
not my intent.
GraalVM native image compilation wasn't working due to
some missing @TruffleBoundary annotations, and calls
from partially evaluated code into methods that are
black-listed for runtime compilation.
With these changes, a GraalVM native image should be
producable from every Mal step.
An uncaught exception in the self-hosting implementation causes the
interpreter to display the EVALed ast for each EVAL level until the
exception, something similare to a stack trace. This does not cost
much and may help a lot debugging the self-hosting step.
On the other hand, remove try* from step0 where it serves no useful
purpose.
Because of indentation level, this diff is better viewed with the git
-b command line option.
It should pass on existing implementations because it is a
prerequisite for an existing test, but small independent tests are
easyer to debug on new implementations.
Split user functions and macros, merge user functions and core functions.
Add a flag triggering debugging info in EVAL.
Reserve mutable environments for REPL and let*.
Move env type declaration from Types to Env.
Check let* arguments only once.
Share more code between map constructions and key type checks.
Stop copying metadata when evaluating collections.
The strict variant of Data.Map.Strict is recommended for general use.
simplify printer.
The grammar is not fully equivalent to the one in the process, but it
passes all tests.
I suggest that it becomes a formal/testable reference (are tabs
allowed as spaces? is "a~" valid? is "' a" valid?...).
As it is formuled here, it can directly be translated either to
another language with high-level parsers, or to a low-level language
as each production only switches after a look at the next input
character.
Another suggestion to simplify step1 is to make '{' a reader macro,
parsing "{a1 a2..}" into (hash-map a1 a2..).
The step1 tests should then accept both "(hash-map ..)" and "{a1..}",
but the process should in my opinion suggest the former as it moves
the complexity related to maps (language-dependent constructor,
argument count and type checking, reporting of such errors) form
reader.qx/step1 to core.qx/hash-map, where it has to be done later
anyway.
The java-truffle implementation is unique enough from the Java
implementation to be considered a unique implementation and not just
a new runtime mode.
Turns out I was missing the @ExplodeLoop annotation on the
execute methods of VectorNode and MapNode. These annotations
trigger loop unrolling. I had thought they were simply for
performance, but in fact they are necessary to ensure that
the correct specializations get selected for each of the
child nodes. Without them, we get compiler bailouts for
functions that include vector and map literals.
