Switch out underlying storage for DEFSTRUCT to something distinct using the storage vector methods

The current value happens to match SBCL's (#x110000) but this may not interoperate nicely with JavaScript

General mop-up of package system edge cases for redefinitions

At a guess, something like (Function { x | x ∈ builtin-primitive } ) ⇒ error?
See tests/seq.lisp

https://mikemcl.github.io/bignumber.js/ provides bignum maths for JS.

JS integers are really floats with no exponent, there is a limited range

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Number/MAX_SAFE_INTEGER
defined as (1- (expt 2 53))
and MIN_SAFE_INTEGER is the reverse

FIXNUMP / TYPECASE / ETYPECASE should honor these limits

http://www.lispworks.com/documentation/HyperSpec/Body/22_cfb.htm

A partial implementation is embedded in defgeneric.lisp already

Also ensure tests for PACKAGEP, HASH-TABLE-P, TYPECASE/ETYPECASE using those.

SBCL signals an error in this case, which “feels” right, have not checked the CLHS to see what the proper behavior is — it may be implementation-defined and thus OK.

This is moved into types.lisp now.

Follow-up to #23

Implement DEFCLASS and use a variant on DEFSTRUCT storage for class objects.

eg via http://mathjs.org/index.html

The form THE is not actually supported, only discarded with a warning.

src/compiler/compiler.lisp: (warn "discarding THE ~a" value-type) ; XXX perhaps one day

Define whitespace (or (char= #\Space char) (not (graphic-char-p char)))

https://github.com/infusion/Fraction.js/

Implementation of file I/O using XHR. Should probably be packaged up in some way to avoid harming Node.JS builds / allow Node.JS users to implement some alternative form.

Suggests that maybe a features flag for browser v. node builds might be useful?

This may involve extending the stream-handling code in some ways, as I suspect JSCL is not really running full-on Gray Streams yet.

At the very least. print-radix support so #\U+xxxx escapes can be created in the new character code.

For now, “punting” to wiser souls on recursive {} () [] code though.

Probably: ~4,'0x ~36r ~5d ~5a ~va … as a baseline.

failing in types.lisp, seemingly not getting defined properly in defstruct.lisp?

Calling this “CLOSE” for now, does not seem to be any major obstacle to (long-term) on-boarding SB-PCL and using metaclass auto-wrappers for the prototype-based Javascript classes, but in the immediate future, this will make conditions and streams (at least) bearable.

Allow as an extension the form

(defun (oget some-object some-property) (λ-list) body … )

… for creating a Lisp function which is “directly” reachable as eg a callback from a JavaScript property. (eg: onevent properties, &c)

Generated code frequently contains sequences like:

var x = 'foo';
var y = x;

… which then never again references x. It seems that there is an opportunity to reduce some of this copying within the code-generation process.

Some kind of macroexpansion error or other

• Implement Conditions properly as classes
• Hunt down internal errors/warnings and set correct types

Attempt to provide more “useful” names than the gensym-like “v123” names.

In general, it would probably be wisest to escape all control chars in \uXXXX form, but also currently \r, \f, and \b are not escaped.

The CONSTANTP function is almost certainly deficient and might cause issues.

Symbols' function-values return the “special value” unboundFunction or unboundSetFFunction, so the tests in compiler.lisp will probably never work because they won't return undefined.

Either these tests need to be lowered to JavaScript in the prelude, or the unbound values can be lifted up to be accessible from compiler and we can rewrite the fdefinition and symbol-function in pseudo-Lisp right there, as well.