Previously we've falled through all cases and if none matched, we've used the
heap. That said our documentation clearly states, that the type for the heap is
EXT:HEAP-SIZE.
Previously object-type first called (TYPE-OF THING) and then matched it with
exact type names. This fails when we have a more precise type, i.e
(type-of 3) -> (integer 3 3)
(eq 'fixnum '(integer 3 3)) -> nil
=>
(object-type 3) -> T
and that left us with subpar optimizations down the road.
Previously we've tried first to add-static-constnat, although that led to a
situation where we've created static constant even if we had that value in the
core. Right now a static constant is the last thing to try when we attempt to
optimize the object. The order is quite arbitrary - the comment before the
function explains that we could avoid coercion with some additional work.
Both variants have distinct and mutually exclusive (based on the code) usages.
Moreover, when dealing with a function name, always use FDEFINITION location.
This is a speculation, but only basic cases were handled with FDEFINITION
because WT-FDEFINITION could only handle symbols in CL package and otherwise a
slower method was used. WT-FDEFINITION can handle now all valid function names
including (SETF FOO) and function names not contained in core packages.
T and NIL are expected to be wrapped in an intermediate structure representing
the value. This improves the separation between the host and the target language.
We cannot compare with (equal) here because subtype relations can
differ for member and eql types even if the type specifiers are the
same under equal.
Introduce ecl_cmp_symbol_value and ecl_cmp_setq which do the minimal
amount of work needed to implement symbol-value and setq for dynamic
variables which we have checked to be non-null and of type symbol in
the compiler.
Also introduce a type check in ecl_symbol_value to be consistent with
ecl_setq which also checks the type. These two functions are mainly
used for the embedding interface now, so for that reason it is also
useful to have a type check in there.
This is inconsistently implemented in that only very few places
actually check for proper lists. Moreover, it slows down code that
uses those functions a lot.
A previous commit unconditionally configures Boehm GC to support fork.
This breaks the Windows MSVC build, producing an error dialog with the
message "Fatal error in GC: fork() handling unsupported".
This commit restricts the call to GC_set_handle_fork to non-Windows
hosts.
