[erlang-questions] Why do we need modules at all?

[Tim Watson]

On 24 May 2011 16:56, Parnell Springmeyer <ixmatus@REDACTED> wrote:
> I really like the idea of packages - I'm not quite sure why everyone is
> against them... Even Racket has extended the syntax of Scheme to the
> point where they support packages and modules now; it's a very natural
> abstraction for the human mind IMHO.

I've tried using them, but the lack of support makes it difficult. The
bugs in the cover tool you can get around by doing -import(ets) in
every module that needs to be cover compiled and as a work-around that
fixes it. But reltool doesn't work so beam files in package
sub-directories beneath ebin do not get copied into the release. There
are probably other bugs too.
> I don't like the idea loading everything when the VM starts. I much
> prefer (and wish Erlang did it this way) the concept of calling an
> import statement. I like being able to see what packages, modules, and
> functions another module is referencing.

You can already (today) choose whether everything loads on startup or
on demand (i.e., when you call Mod:Func(Args)) by choosing to run the
VM as an embedded system or not. To see what packages, modules and
functions your modules are referencing, you can use the xref tool
which comes with the standard distribution and is supported by tools
like rebar.

> I am intrigued, however, by the idea of type signatures and finding
> functions based on their metadata - cool idea.

Yes, this works particularly well for haskell (e.g., hoogle) and
combined with cabal/hackage makes it easy to find what you need based
mainly on type signatures. Sadly type signatures are often *all* the
documentation you get of a Haskell library/application, which unless
you're a type guru can be just as frustrating as
write-yourself/cut+paste and often more so than
google=>github=>rebar-deps.

>
> In practice though, I would really hate maintaining the metadata for
> every function I've wrote! I much rather group common functions into a
> module and then annotate the module with metadata.
>

If extra metadata were to be attached to functions, this should/would
be generated by the compiler anyway.

Personally, I think a step in the right direction would be to preserve
type signatures at runtime - something that has been discussed
elsewhere on this list not that long ago IIRC.