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

On Fri, Oct 3, 2008 at 4:36 AM, minh thu wrote:

2008/10/3 Mitchell, Neil :

...

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. Dave

Thanks, Thu _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe