4:39:50dialecticWhite_Flame: Oh? Curious. If that's the case, no wonder it was removed.
4:43:32White_Flameyeah, it's definitely an implementation artifact for constructing other compound data types, not a feature of standard arrays
4:44:08White_Flamefor instance, flavor/clos class pointers would go there
4:45:06White_Flamebut since the GC was very low-level, the memory layout of extended custom objects needed to follow a regular model that the GC could always grok
4:46:15White_Flamenowadays, since GC is at the same software level as the rest of the software runtime, it can be much smarter
4:46:36White_Flameand object types can have much more customization than relying on low-level array metadata
5:58:57asarchOne stupid question: why SBCL and not GNU Common Lisp?
5:59:58asarchIs it because GCL is Lisp-1 and SBCL Lisp-2?
6:00:20no-defun-allowedGCL isn't a conforming Common Lisp implementation, and it doesn't have a native code compiler that makes JVM weenies fear for their lives[citation needed].
6:01:10jackdanielGCL implements CLtL2 with effort to support ANSI CL (and it is Lisp-2)
6:01:11no-defun-allowedGCL, if it is supposed to be a Common Lisp implementation, has to be a Lisp-2. There should be zero difference in semantics when running portable CL programs on conforming implementations.
6:01:13dialecticDidn't GNU Common Lisp turn into Kyoto Common Lisp?
13:52:56pjbI was thinking about (defun take (n list) (loop repeat n for current := list :then (rest current) collect (first current))) but then (take 2 '(1)) #| --> (1 nil) |#