[Haskell-cafe] Hmm, what license to use?

[Jonathan Cast]

On Fri, 2008-10-03 at 10:08 -0700, David Leimbach wrote:
> 
> 
> On Fri, Oct 3, 2008 at 4:36 AM, minh thu <noteed at gmail.com> wrote:
>         2008/10/3 Mitchell, Neil <neil.mitchell.2 at credit-suisse.com>:
>         
>         >
>         > Hi
>         >
>         >
>         >> > > You mean shared libraries without the opportunity to
>         >> inline library code?
>         >> > > This would result in a huge performance loss, I think.
>         >> >
>         >> > Usually _mild_ performance loss, in exchange for major
>         code-size
>         >> > savings, I would think. C obviously has worked quite fine
>         under
>         >> > exactly this restraint (though C implementations
>         obviously aren't
>         >> > built to take as great advantage of inlining library code
>         >> as Haskell may be).
>         >>
>         >> I think that the performance loss is much higher in the
>         case
>         >> of Haskell because of Lazy Evaluation, massive use of
>         higher
>         >> order functions and possibly more.
>         >
>         > Example 1:
>         >
>         > foo x | "test" `isPrefixOf` xs = ...
>         >        | otherwise = ...
>         >
>         > If you have cross-module inlining, you get the rather
>         obvious if like
>         > construct. If you don't, you have to evaluate otherwise and
>         test its
>         > value.
>         >
>         > Example 2:
>         >
>         > (a :: Int) + b
>         >
>         > If you have cross-module specialisation you get a primitive
>         integer
>         > arithmetic instruction (possibly with a bit of unboxing,
>         although often
>         > not). If you don't, you get a dictionary lookup, followed by
>         a higher
>         > order application.
>         >
>         > One reason cross-module inlining is essential is that many
>         Haskell
>         > functions don't do very much, think of (+), (||), (>>), not,
>         otherwise
>         > etc. In C these would be built-in's, so are always available
>         to the
>         > optimiser (and usually just one instruction), in Haskell you
>         need to get
>         > them from the Prelude.
>         
>         
>         What happens in the C++ world where good chunk of
>         functionnalities are
>         in header files (templates or inline methods);
>         is there the same LGPL problem that the one discussed here
>         w.r.t.
>         static/shared linking ?
> 
> 
> I don't know what happens on platforms that don't have shared
> libraries with LGPL.  If you build stuff statically, I'm pretty sure
> you can't claim stuff is loosely coupled.

What I've always heard is that in that case you have to distribute
object files.

This would work for Haskell, except that changing the distributed
library is still liable to invalidate the object files, due to
cross-module inlining.

jcc