> Can someone recommend a source i can read that explains the type > system and hopefully the type inferencer in cmucl and sbcl.
The type system used internally in SBCL is exactly the same implementation of the ANSI CL type system available to user programs. This means that the type system per se is described in Chapter 4 of the spec. What this means for user programs is described in section 3.2 of the SBCL manual, "Handling of Types". The description of the compiler in the paper "Design of CMU Common Lisp", edited by Rob MacLachlan, is still largely relevant to SBCL. Chapters 9 and 10 describe the handling of types, although they may be less than comprehensible without reading the preceding chapters on the ICR representation.
I'm interesting in reading about how the type algebra works and and how the reasoning about types is done. How does python look at code and reach conclusions about the types? I imagine it is very complicated, but probably some parts are approachable...
> The type system used internally in SBCL is exactly the same > implementation of the ANSI CL type system available to user programs. > This means that the type system per se is described in Chapter 4 of > the spec. What this means for user programs is described in section > 3.2 of the SBCL manual, "Handling of Types". The description of the > compiler in the paper "Design of CMU Common Lisp", edited by Rob > MacLachlan, is still largely relevant to SBCL. Chapters 9 and 10 > describe the handling of types, although they may be less than > comprehensible without reading the preceding chapters on the ICR > representation.
> On 17 déc, 23:35, jimka <ji...@rdrop.com> wrote:
> > Can someone recommend a source i can read that explains the type > > system and hopefully the type inferencer in cmucl and sbcl.
> The type system used internally in SBCL is exactly the same > implementation of the ANSI CL type system available to user programs. > This means that the type system per se is described in Chapter 4 of > the spec. What this means for user programs is described in section > 3.2 of the SBCL manual, "Handling of Types". The description of the > compiler in the paper "Design of CMU Common Lisp", edited by Rob > MacLachlan, is still largely relevant to SBCL. Chapters 9 and 10 > describe the handling of types, although they may be less than > comprehensible without reading the preceding chapters on the ICR > representation.
> the paper "Design of CMU Common Lisp" is a great reference. thanks > for the pointer.
It really is, and should probably be pointed out more widely to people who want to understand the general approach taken by SBCL and CMUCL to figuring things out about their code. Some particulars have changed, but the essence of Python is explained there.
It's too bad the document was never finished, but that's the way things go. I'm glad the community focused on keeping the implementation alive and moving forward, rather than finishing the internals documentation.
The now departed encyCMUCLopedia had a number of other interesting things in it, but this (along with the Hemlock command implementor's manual) was the real gem. I guess it shows in their still being among the CMUCL documentation.
> On Dec 18, 12:14 pm, "Thomas F. Burdick" <tburd...@gmail.com> wrote:
> > On 17 déc, 23:35, jimka <ji...@rdrop.com> wrote:
> > > Can someone recommend a source i can read that explains the type > > > system and hopefully the type inferencer in cmucl and sbcl.
> > The type system used internally in SBCL is exactly the same > > implementation of the ANSI CL type system available to user programs. > > This means that the type system per se is described in Chapter 4 of > > the spec. What this means for user programs is described in section > > 3.2 of the SBCL manual, "Handling of Types". The description of the > > compiler in the paper "Design of CMU Common Lisp", edited by Rob > > MacLachlan, is still largely relevant to SBCL. Chapters 9 and 10 > > describe the handling of types, although they may be less than > > comprehensible without reading the preceding chapters on the ICR > > representation.