[Haskell-beginners] Module import problem

[Casey Rodarmor]

On Sun, Sep 28, 2008 at 9:09 PM, Chaddaï Fouché
<chaddai.fouche at gmail.com> wrote:
> 2008/9/28 Casey Rodarmor <caseyrodarmor at gmail.com>:
>> The comparison I was thinking of was with python, where a module can
>> be placed in an arbitrary directory, and then accessed using a
>> relative path. If I have 'stuff.py' that contains class 'Foo', I can
>> move it to 'hello/module/stuff.py', and then import it is
>> hello.module.stuff.
>
> And if you have something in hello/ it must refer to the same module
> by module.stuff instead. I'm not sure it's clearer...

Yeah, I can see where you're coming from.

> Anyway the hierarchical modules in Haskell means that every code must
> import the same module with the same name which I find saner (though I
> could wish the import/export syntax would be more advanced to allow
> for shorter imports when I have a lot of imports in the same hierarchy
> part).
>
>> A python module doesn't need to know where it
>> lives.
>
> Well, it doesn't need to, but everyone else needs to, in Haskell, the
> module need to know where it lives, but everyone else don't care.
>
>>
>> I often find myself working on computers where I don't have
>> administrative privileges, which means I might not be able to install
>> libraries in the 'right' places. This approach also makes it simple to
>> create self-contained projects that can easily be moved from machine
>> to machine, where only the local directory structure is important.
>> Would there be any downside to this in haskell?
>
> Note that if the modules are in the same project, they're all in the
> same hierarchy (at least that's how I see a project) and so their
> names are coherent with each other and with the relative directory
> hierarchy, there is no problem there.
> Now, I think your preoccupation has more to do with packaging several
> libraries you're not sure will be available on the final machine with
> your project, and reasonably, you don't want to put them all in the
> same base directory (yeah, it would be a mess). I would argue that
> Haskell being a compiled language, its distribution problematics
> aren't exactly the same as Python... If you're just distributing an
> application you presumably would just compile it on your development
> setup and then distribute the executable.

Very true, but I still really like source distributions, even for
compiled languages. Even though it can mean headaches, a source
distribution is sometimes more portable than a binary distribution.
(Usually because a clever end user can fiddle a little bit and get it
working, whereas an incompatible binary is a useless blob.)

> But if you really want to distribute the code source in a self
> sufficient package (assuming GHC on the final machine I guess ?), you
> should use Cabal : it automates dependency checking, compilation and
> installation with several source directory and configurable target
> installation directory. It's pretty easy to use too (mainly I suggest
> you do copy/paste of a good project file on Hackage).

I'll definitely check out Cabal.

I'm a student, and so I'm always developing on personal and school
computers, as well coding with random project partners (who always
seem to be running equally random OSs). And then, to top it off, I've
got to turn in assignments without being exactly sure where the grader
is going to run them. I'm *always* wanting to use some library in a
project, and (apt-get|port|emerge) my_sweet_library is never an option
:-(

Thus my concern with portable source packages. :-)

These days I usually write crazy makefiles that try to do their best
to compile and link in all the libraries needed, wherever they might
find themselves.

>
> --
> Jedaï
>