The _error function was returning an empty string which meant that in
the try*/catch* implementation, the lack of result was preventing
foreach from being used as a "let" form and because of that it was
skipping the catch* handling path.
The `_map?` function was introduced when transitioning the macro
property being stored in metadata to uinsg a regular map with
a special key. The `_map?` function causes issues in a few places but
the biggest issue is that it breaks the `_macro?` function for the
second order self-hosted mal instance. The `_macro?` function contains
a `(map? x)` call that returns false resulting in the `_macro?` call
returning false. I'll push something later that fixes this and also
that activates second order self-hosted tests so we can catch this
sort of issue in the future.
Let `load-file` append a new line in case last line contains a
comment.
Also append `nil` so that the return value is predictible. Remove the
existing explicit `nil` from existing sources.
Adapt documentation and tests.
Add a regression run to Travis that enables hard deferrables but
omits optionals so that we can test to make sure that all the
requirements are met for self-hosting in stepA.
Cleanup up some of the soft/deferrable/optional markings.
Deferrables are what will be needed eventually to self host but aren't
needed for the immediate next steps. Optional aren't even needed for
self-hosting but are nice things to have.
Also:
- Sync dart step9 and stepA with step8. Do not eval macroexpanded
forms in macroexpand form.
- Fix stepA of factor which was missing some fixes from step9.
- Increase test timeouts in top-level Makefile for guile and io.
Instead of using Io's `asJson` method which escapes forward slashes,
implement our own string escaping code so it fits the Mal requirements.
The relevant step1 test was modified from soft to hard.
Make: remove part of EVAL breaking # and $
step0: no MAL character must break the interpreter
(soft) no printable ASCII character either
step1: no MAL character must break strings
(soft) no printable ASCII character should break strings
(soft) no character should break comments
step6: redo step1 tests for comments inside read-string, as new
problem may occur with line breaks and escape characters of the host
language.
Output of macros will probably be more readable.
Inline _macro_wrap and _unwrap for efficiency (there are less
primitive operations for maps than for vectors).
Basic check of `map?` and `macro?`. Swap them in order to simplify the
diff with cb9b0654.
Let `with-meta f m` create a function even if f is a macro, instead of
setting an "ismacro" metadata that is never used again (and breaks
self-hosting).
Also move the test for fn? from Optional to Deferrable, the function
is used for self-hosting.
* Move `gensym` and `inc` from step files to `lib/trivial.mal`.
* Move `or` from step files to `lib/test_cascade.mal`.
Shorten it because `(first ())` returns `nil`
* Update process and tests accordingly (not the figures yet).
Specifically, test that when "1" is used as a hash-map key, it is
represented as a string when printed (step 1) and when returned by
'keys' (step 9). PHP used to get both of these wrong.
It seems that the PHP implementation converts integer-like strings as
hash-map keys into integers, so {"1" 1} becomes {1 1}. I don't know if
that's a bug, but it's certainly not the bug I was trying to test for.
Use different keys to avoid this problem.
All the existing tests in step 1 use empty or single-element hash-maps.
That avoids any dependency on the ordering of printed hash-maps, but it
does mean that some code paths (e.g. printing the space between hash-map
elements) aren't tested. Add a test that creates a three-element
hash-map and uses some regexp trickery to check that all the right keys
and values come out.
These tests are intended to catch the cases where the routine for
reading a list, vector, or hashmap fails to consume the trailing token
(')', ']', or '}' as the case may be) from the input. None of the
existing step 1 tests detected this, and I only found it by playing
around in the REPL.
I just introduced a bug in the BBC BASIC implementation meaning that
'load-file' was broken on files over 255 bytes long, and it was only
caught by the optional test of 'time-ms' in step A. This change brings
forward the relevant part of that test so the failure can be detected
earlier and more obviously, at the same time as the other tests of
'load-file'.