Each contexts keep a link to the heap which it is a part
of (when using the native GC), as well as a vector of
special globals that it needs quick access to (e.g. the
`quote' and `quasiquote', etc. symbols. You can use this
to manage multiple completely unrelated VMs in the same
application, and everything will be thread-safe.
The old behavior is still available by editing config.h,
which now includes somewhat better descriptions of all
the settings.
all native types, present and future, now supported.
allows for distinguishing which slots should be used
for comparison (e.g. source info of pairs isn't compared).
Replacing sexp_make_integer, sexp_integerp, etc. with sexp_make_fixnum,
sexp_fixnump, etc. Defining the old names as variants handling either
fixnums or bignums, or just as aliases for the new terms when compiled
without bignum support. sexp_make_integer needs to take a context now
in case it generates a bignum.
Using <u.h> and <libc.h> for plan9, no need for separate .i file
construction. Also mkfile now simplified and using /sys/src/cmd/mkone
(thanks to Charles Forsyth).
Notably no longer converting from function pointers <-> void*.
Remaining --pedantic warnings:
* ISO C90 does not support 'long long'
* ISO C90 does not support the 'z' printf length modifier
* ISO C90 does not support flexible array members
* ISO C90 forbids mixed declarations and code
* ISO C90 forbids specifying subobject to initialize
* anonymous variadic macros were introduced in C99
* invalid use of structure with flexible array member
The first one is only used when optional bignums are enabled,
and I have no intention of supporting bignums on systems w/o
long long (although it's not guaranteed two words fit in a
long long - I need to fix this).
The 'z' modifier is necessary for long types (you'd get
warnings the other way without it).
The next 4 are intentional - they make the code cleaner,
and all of these extensions are supported by Plan 9.
The last one is tricky. I think it refers to the fact
that not only am I using flexible array members, but I'm
using them as non-final alternates in a union. I'll have
to double check the semantics of this.
can disable with USE_BIGNUMS=0 - the interactions between this and
USE_FLONUMS are messy, so they will likely be merged into a single
option in the near future (i.e. you either have only fixnums, or a
full range of numeric types).
adding rationals based on this would be easy and is a likely future
feature. adding native support for complex numbers is unlikely.
