Erik sent me a log from IRC yesterday, so I'll try to answer some of the questions.
<tomberek> was reading through the thesis paper, trying to learn about DDC, the region and effects typing make perfect sense, but tossing in the closure typing just seems to complicate things a bit too far, or is there a nice way to conceptualize it? <erikde> tomberek: as i understand it, the closure typing is necessary to track the capture of mutable variables in closure. <tomberek> so it's all about partial application? That's right. If we have some function (add :: Int -> Int -> Int), and then partially apply it like (addFive = add 5), then the '5' object is captured in the closure of the resulting function. Each use of addFive shares the same '5' object, and if the object is mutable we need to track the sharing. For the most part, the programmer doesn't need to worry about closure typing, as it can be inferred. You currently need to write it when defining type class definitions, but we hope to eliminate the need for that by using some suitable defaulting rules. <tomberek> what are the big steps in the project? Big jobs to be done: 1) Finish the formalisation of the DDC core language. This will help explain the operation of the witnesses used by the core language, and put the region typing system on a better theoretical footing. There are other technical warts in the current core type system that don't make it unsound, but need to be ironed out before we can extend it further. In particular, we want to be able to mask closure types when the object in the closure is constant. 2) Fix bugs in the type inferencer. In particular, inference for some 3rd order functions and higher is broken because we're doing constraint strengthening too early. I know how to do this, but it needs a new type constraint simplifier, which is only half done. 3) Work out how to do closure trimming properly. The current closure trimmer doesn't work in all cases, and has complexity issues on large type signatures. This is related to the handling of material vs immaterial region variables. Finishing job #1 will help with this. 4) Finish the new interface file format. Current DDC compiled programs are very slow due to the total lack of cross module inlining. Not even functions like ($) are inlined. We need to put the core language versions of functions in the interface files, and then finish the inliner. 5) Reuse GC stack slots in the back-end. The way it's set up now, compiled programs are holding onto far too many intermediate objects that could really be garbage collected. 6) Finish the implementation of type classes and dictionary passing. This is blocked on jobs #1 #2 and #3. 7) Fix all the bugs. <tomberek> what's the big blue arrow? The central symbol is a square :>, "more than equal" sign, which is used in the type system. The things on left and right are lambdas on their side. DDC: more than lambdas... or at least "more than or equal to lambdas". :-P Ben. -- Disciple-Cafe mailing list http://groups.google.com/group/disciple-cafe
