The problem is an if expression within one of these functions may cause the same continuation to be expanded twice, introducing duplicate lambda defintions and identifiers. For now we are not going to beta expand such functions during the contraction phase.
1) Disable beta expansion (causes exponential growth problems on compiler benchmark, needs more fine-tuning)
2) Do not inline assoc/member functions since they loop (needs performance analysis)
We don't know if the functions they call will mutate or not, so err on the side of caution. Not sure this is really necessary since they receive a cont and therefore cannot be inlined anyway.
We know prims are only symbols, so instead of checking for primitives in the top-level cond (which is expensive) we check for it as a sub-condition off of the (ref?) condition. This lets us avoid a call to memq unless we already are inspecting a symbol.
Having problems getting macros to work in a safe way with Cyc-seq. Since these functions were never a big win anyway, we are going to disable them for now.
Want to ensure cons can be used safely as part of a Cyc-seq. This cannot happen if the cons used the previous make_pair macro as that can only be called at the top of a function as part of a declaration.
This avoids ordering issues. But I think we still have trouble with other primtives. Is there ever a legitimate need to declare a c var for a prim??? I am not seeing it, especially with our changes now for Cyc-seq.