[Haskell-cafe] expanded standard lib

[Vladimir Zlatanov]

<snip>
> Many other programming languages have packaging strategies that sound
> very similar.  Several of them have managed to have a negative impact on
> platforms that already have good packaging technologies (i.e. almost
> every platform apart from Windows ;-).  I'd hate to see Haskell go in a
> direction where packaging for e.g. Debian is made more difficult than it
> is at the moment.
:)
That would be very bad indeed. With careful implementation that
shouldn't be a problem.

Му reference to planet was regarding the ease of use and download of
packages not installed in the system. That is integrated into the
compiler via scheme macros or their equivalent in "non-scheme"
languages:
- just consider the following:
    (require (planet "eval.ss" ("dherman" "javascript.plt" 5 4)))

if a package javascript verssion 5 4 by dherman is not present in your
system or your user planet cache -> download, and compile it, then
proceed doing your normal compiler duties....

With distribution provided packages they will be present if installed by
root. With user downloaded they go somewhere in home or whatever else
sensible place is pointed in the environment. I simply don't see a
conflict. It is the normal unix way. Being lazy is good after all.
Having the tools infer all dependencies and provide them to you when you
need them is a good thing as well. Just compare it with the:
sudo apt-get xyz; echo "I don't have root, I'll call dad, 'cause I want
to compile"

I'm not sure if it is currently possible to implement that via template
haskell. From the snippets I've glimpsed it implements a simple defmacro
like mechanism. But does it allow executing actions at compile time? If
yes, it can be done in a library and then tested for usability,
packaging and destruction. 

I do think it is wrong to have it in the prelude, at least for quite a
while, but having the option to do it is a plus.

I think I went oveboard with this. Sorry for the longish post.