Donn Cave <[EMAIL PROTECTED]> wrote: ... > | making a really modular system work with static typing and inferencing > | is probably impossible; in practice, the type inferencer must examine > | all code, or a rather copious summary of it... it can't really work > | module by module in a nice, fully encapsulated way...). > > Well, I would assume that a modules in a static system would present > a typed external interface, and inference would apply only within the > module being compiled. ... > There might be tricky spots, but I imagine the Objective CAML > folks would object to an assertion like "making a really modular > system work with static typing and inferencing is probably > impossible"!
It seems to me that you just restated in the first part I quoted what you say in the second part OCAML folks would object to. If you give up on type inferencing across modules, and only have type inferencing inside each module, then you're getting little mileage out of the inferencing if your modules are many and small. But let me quote Van Roy and Haridi, rather than paraphrasing them, lest I fail to do them justice -- I think quoting 8 lines out of a book of over 800 pages is "fair use" (anecdote: my Xmas gift is said book, my wife's a real-bargain Powerbook 15" Titanium laptop -- yesterday we weighed them against each other and determined the book's heavier;-)... """ Dynamic typing makes it a trivial matter to do separate compilation, i.e. modules can be compiled without knowing anything about each other. This allows truly open programming, in which independently written modules can come together at runtime and interact with each other. It also makes program development scalable, i.e., extremely large programs can be divided into modules that can be recompiled individually without recompiling other modules. This is harder to do with static typing because the type discipline must be enforced across module boundaries. """ I see that by paraphrasing and summarizing by heart I was changing their argument a bit, from 'enforcing the type discipline' (which is what they're discussing, and is obviously mandatory if you want to talk about static typing) to 'type inferencing' (which they don't discuss in this specific paragraph). Nor do they claim 'probably impossible', since they're only discussing enforcement, not inferencing -- just 'harder'. Essentially, to compile a module under static typing you need full type information for other modules -- the "without knowing anything about each other" condition of fully separate compilation can't hold, and thus neither can the "truly open programming" and "scalable development" consequences. Mind you, I personally _like_ the concept of describing an interface separately, even in a different language (Corba's IDL, say) that's specialized for the task. But it doesn't seem to be all that popular... without such separation, modularity plus static checking appears to imply bottom->up coding: you need to compile modules in some topologically sorted order compatible with the "X uses Y" relation. Alex -- http://mail.python.org/mailman/listinfo/python-list
