Optional Static Typing - Haskell?

[Mike Meyer]

aleaxit at yahoo.com (Alex Martelli) writes:

> Mike Meyer <mwm at mired.org> wrote:
>> aleaxit at yahoo.com (Alex Martelli) writes:
>> > 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.
>> Personally, I hate declaring the interface separately, whether in the
>> same language or another language. 
> Yeah, so do many people -- as I mentioned, it's not all that popular.
> Personally, I don't see _why_

Because it violates the principle of "Once and only once". If the
interface is described in two places, that means it's possible to
update one and forget to update the other. That's not possible if the
interface is defined once and only once. I've forgotten to update my
IDL more than once.

> But then, the above criticism applies: if interface and implementation
> of a module are tightly coupled, you can't really do fully modular
> programming AND static typing (forget type inferencing...).

I beg to differ. Eiffel manages to do this quite well. Then again,
every Eiffel environment comes with tools to extract the interface
information from the code. With SmartEiffel, it's a command called
"short". Doing "short CLASSNAME" is like doing "pydoc modulename",
except that it pulls routine headers and DbC expression from the code,
and not just from comments.

>> On the other hand, generating the
>> interface information from the code for type checking (and
>> documentation) purposes makes an incredible amount of sense. A type
>> inferencing engine to generate that information from Python code -
>> with possible a bit of human assistance - would make it possible to
>> use pychecker to catch duck typing errors without having to import an
>> entire module.
> And why should it be a problem to "import an entire module", pray?

It isn't. I was just thinking out loud. If you had a type inferencing
engine that created the type signatures of everything in a module,
that would let you do type checking without importing the module. It's
actually more interesting for compiled languages than for interpreted
ones.

        <mike
-- 
Mike Meyer <mwm at mired.org>			http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.