Optional Static Typing - Haskell?

Mike Meyer mwm at mired.org
Mon Dec 27 11:13:08 EST 2004


"Donn Cave" <donn at drizzle.com> writes:

> Quoth Mike Meyer <mwm at mired.org>:
> | aleaxit at yahoo.com (Alex Martelli) writes:
> ...
> |> 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.
>
> And you probably think Eiffel supports fully modular programming, as
> I thought Objective CAML did.  But Alex seems not to agree.
>
> The way I understand it, his criteria go beyond language level semantics
> to implementation details, like whether a change to a module may require
> dependent modules to be recompiled when they don't need to be rewritten.
> I don't know whether it's a reasonable standard, but at any rate hopefully
> he will explain it better than I did and you can decide for oneself whether
> it's an important one.

I read through his explanation. And the answer for Eiffel is, of
course, "it depends".

There's an optimization that embeds a class data directly in the
cilent class - the expanded keyword. If you have an expanded variable
or type in your client class, then changing the implementation of the
provider may require recompilation of the client. On the other hand,
that's pretty much an optimization, and so you shouldn't run into it
during development.

SmartEiffel, on the other hand, always does full-source analysis. It
drops class features that aren't used by any client, so changing the
client can cause the provider to be recompiled.

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



More information about the Python-list mailing list