47 lines
1.6 KiB
Plaintext
47 lines
1.6 KiB
Plaintext
|
|
Need to check for multiple (effectively) identical closures.
|
|
node-equal?
|
|
|
|
Flatten needs to do something about shared strings and byte-vectors.
|
|
|
|
Do SET! globals need to be treated differently? Will C allow the following?
|
|
int f( int x ) { ... }
|
|
main() { f = ... }
|
|
|
|
Check what happens if a name->enumerand or enumerand->name survives loading.
|
|
|
|
CALL-WITH-VALUES needs to simplify to two calls (so that the known-call
|
|
stuff works) even when it doesn't know what the type is (because of
|
|
polymorphism; we don't resimplify when types change).
|
|
(call-with-values cont a b)
|
|
=>
|
|
(unknown-call (lambda (res:tuple)
|
|
(unknown-call cont 'tuple-args b res))
|
|
'tuple-result
|
|
a)
|
|
Need tuple-args-goto as well. The protocol stuff has to do the right thing.
|
|
When the tuple type is determined RES has to change in both places.
|
|
Actually, it can just expand into this. The type stuff will work out.
|
|
For now I am not going to allow polymorphic use of call-with-values.
|
|
All of this is much like Scheme.
|
|
|
|
Non-tail-recursive named-LETS appear to break things.
|
|
|
|
CALL-WITH-VALUES and VALUES are only allowed in call position, and the
|
|
second argument to CALL-WITH-VALUES must be a lambda form.
|
|
|
|
STOB->NODE in form.scm needs to look for substobs.
|
|
Or does flatten flatten non-shared structures?
|
|
|
|
Pointer comparisons need to be done using unsigned longs.
|
|
=> Pre-Scheme needs unsigned comparisons u=, u<, etc.
|
|
|
|
Primitives do not appear to check the argument count!
|
|
|
|
Channel library may be doable as externals, including decoding
|
|
the events.
|
|
|
|
Tail-called forms that return multiple values?
|
|
|
|
MAX and other primitives need to check number-of-args when type checking.
|