Heretofore, the mal implementation has linked each environment to its
outer environment by defining a special symbol, '--outer--' in that
environment. This causes that symbol to be unusable by programs running
under that implementation. For instance:
(def! foo 123)
(def! f (fn* (--outer--) foo))
(f)
gives an error because overwriting '--outer--' breaks the environment
chain.
Happily, mal provides a way around this. Keywords are guaranteed to
work as hashmap keys, so by using a keyword instead of a string as the
key for the outer environment, it can be hidden from user code. This
also provides a motivation for keywords, which aren't otherwise used by
the mal implementation.
Rather than checking for a trailing '"' to detect unterminated string
tokens, use a regexp (derived from the tokenizing regexp) to do so.
This correctly handles cases where a token ending with '"' isn't a
valid string.
Having found the perfect mal heap size to get self-hosting to work in
64-bit Brandy, I tried the performance tests, and they failed. I've
therefore accepted that I need to increase Brandy's heap size, so I'm
doubling it to a megabyte. That doesn't seem especially generous on
modern hardware.
Making the mal heap very slightly smaller allows the self-hosting test
to complete on a 64-bit host.
This is really not the right approach, though. I should really just
give in and specify "-size 1024k" to Brandy, or have the GC somehow
detect that we're wasting a lot of memory on strings and it should run
early. At the moment, there's a tiny range of heap sizes that
actually work.
I split the string-recognizing part of the read_atom regexp in two, one
part for recognising valid strings (using a fragment of the tokenising
regexp) and another to recognize invalid strings. This follows the
practice of other implementations with a single read_atom regexp.
- clojure (cljs): self-host arity fix. Apparently ClojureScript
functions that have metadata attached only support arity of 20. This
is problem during self-host because the main EVAL cond macro is 22
items so it blows up when applied in macroexpand. So we preserve the
origin unadorned function through to macroexpand and use it there
instead of the adorned function/macro.
- basic: fix build when in self-host qbasic mode.
- coffee, cs, dart, elisp, hy, rexx, vb: fix self-host reader errs. Preserve
or extract the correct error message in try*/catch* loops so that it
works for self-host error message printing as well.
- mal: pathing issue in ./run script that affected the wasm
implementation path permissions
- miniMAL: remove extraneous command line printing of "nil".
- ps: inc function was not actually defined.
- rust: write warning about missing .mal-history to stderr to fix
self-host failure in step6.
- wasm: the map function was stopping on nil values; fix the list end
check. Double the macroexpand stack so that sumdown test in stepA
tests passes without mac stack overflow.
- yorick: read from /dev/stdin in readline builtin function.
- If the branch name is "self-host-test" then do self-hosted test.
- Fix pass through of *_MODE values during self-hosting.
- Add capability to skip of build/test/perf during self-host.
- Skip self-host for basic, io, logo, make.
- Reformat travis.yml list for better alignment
The code for constructing long strings in FNstring_concat and 'slurp'
was accidentally quadratic in the size of output. This meant that it
consumed BASIC heap space in inordinate quantities for storing strings.
Mal doesn't monitor the usage of the BASIC heap, so it didn't run the
garbage collector and instead suffered a fatal error. Making these
functions use sane amounts of memory avoids that problem.
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'.
When I first implemented support for strings over 255 characters long, I
did so quite crudely, and the procedures to construct long strings
modified the mal objects passed into them. This was unfortunate: no
other routine (apart from PROCatom_reset, of course) modified an object
in the mal heap after it had escaped from the "types" library. It also
led to quite a few annoying bugs.
This is now fixed: all routines that modify long strings now return a
new object as necessary, and leave the arguments unchanged. This is
probably rather slower than the old code, but it's also much cleaner.
Rather than having a separately indexed array of strings, S$(), with
its own free-list in S%(), we now keep string values in an array,
Z$(), whose indices parallel those in Z%(), so Z$(x) is the string
value of the object at Z%(x,y). This saves a fair amount of
complexity at the expense of slightly more memory usage.
When testing `foo.mal`, it makes sense to report parsing errors in
`foo.mal`.
Move tests of `->` and `->>` from `tests/step8_macros.mal` to
`tests/lib/theading.mal`.
Add `lib/trivial.mal`.
I split the string-recognizing part of the read_atom regexp in two, one part for
recognising valid strings (using a fragment of the tokenising regexp) and
another to recognize invalid strings. This follows the practice of other
implementations with a single read_atom regexp.
Rather than treating anything beginning and ending with '"' as a valid
string, we now use a regexp to detect a valid string and treat any other
token starting with '"' as an error.
This does not fix all of the bugs found by #359, though: there remains a
problem with long strings of backslashes in the input getting expanded
into too many backslashes in the resulting string.
Rather than treating anything beginning and ending with '"' as a valid
string, we now use a regexp to detect a valid string and treat any other
token starting with '"' as an error.
