PLAI is almost completely subsumed into PAPL. With each revision, though, the PLAI material gets reorganized and distributed across PAPL, so at some point it will no longer be an identifiable subset. The idea is that programming inspires new programming languages, while programming languages help us make sense of programs. Therefore, the two should be tightly intertwined. The first edition of PLAI tried one way to achieve this synthesis (but didn't really succeed as much as I'd have liked); PAPL is a fresh attempt at getting there.
Shriram, thank you for the PLAI and I'm looking forward to take a look on PAPL as well. But one thing I don't like - types (static typing) for the implementation language is an afterthought in your books. This happened to PLAI, and later it switched to "plai-typed" language (which was a good move). Now we have PAPL, but again using a dynamic language. Although, as I can see, static typing is a planned feature for Pyret. So I suppose PAPL will switch to static typing in the future, but I think it would be better (for readers/learners, novice programmers) to start with (static) types in the first place.
EDIT: just skimmed through the text, you seem to be using "type-like annotations" mentioned in Pyret docs.
Another thing to note - Pyret is much more readable/enjoyable (and I guess writable :)) than the previous lisp languages you've used. Thanks!
Thanks for your comments; criticism is always welcome! And for your kind words about Pyret, though I actually find parenthetical syntax a bit easier to write. It's still taking me some effort to get used to the irregularities of non-parenthetical syntax.
I don't know why you say types are an afterthought. HtDP teaches a profoundly _typed_ discipline of programming. The datatype mechanism in PLAI continues this with more enforcement. And plai-typed is anything _but_ an "afterthought", right?
PAPL is written as if types work. We have an internal type-checker that I've been using off-and-on this semester (but it's still in development). As soon as it's ready, all programs in the book will pass through it and the book will be almost completely typed.
I'm not going to get into an argument here about whether it is better to start with static types. Though I somewhat share @noelwelsh's viewpoint, I think the full situation is far more complex and demands actual research — HCI research — as opposed to just matters of opinion (including mine).
> And plai-typed is anything _but_ an "afterthought", right?
No, no, plai-typed is great. I meant that PLAI book initially used a dynamically typed language (and I guess it is preserved in the printed edition), but you switched to plai-typed afterwards, and I believe you'll switch to full static typed Pyret for this book as well, when it becomes ready :)
("shameless plug": Actually, it was me who notified you about the plai-typed effort and you further developed it, during your online PLAI class at Brown ;))
Agree about a typed discipline, but I meant specifically static typing for the implementation (host) language.
As for preferences, yes, actually Noel has a point - learning debugging type errors in a dynamic languages is a skill useful in a "real world" (unfortunately :))
My understanding is that it is useful for beginners to run their programs, complete with type errors, so they can see where they fail. Debugging type errors if difficult without a strong model of evaluation and type inference. Since beginners are learning these very things, type errors can be very confusing to them and hinder learning.
No, it doesn't. There is a _lot_ of detail to the design recipe of HtDP. Right now the recipe isn't written down at all, just assumed, in PAPL. Over time PAPL will provide a light introduction to the recipe, but it will never reproduce the full level of detail of HtDP. PAPL's intended audience is people who have a little bit of programming experience already — ideally through HtDP — and are ready to take their programming up to the next level.
