Packages and modules

[Malcolm Wallace]

Ketil Malde <ketil+haskell at ii.uib.no> wrote:

> This brings up an interesting point: if I need a bugfix from version
> X, later packages will probably also be okay.  So it should be
> possible to do:
> 
>          import A.B.C from "foo >= X"

Yes, I agree, some notion of version ranges might be desirable
    "1.3.2 <= foo <= 1.3.9"
That is one good reason to leave the package name as a quoted string, so
such questions can be resolved later in the design exercise, and even
changed in the future, without impacting the basic syntax.

> How about minor/major revisions?

Yes, you might want "foo-2" to indicate that any of "foo-2.0" up to
"foo-2.99.9" are acceptable.  If every library author sticks to the rule
of no API changes in minor versions, then this might even cover the same
territory as the version range idea.

> > With the Simons' proposal, and with Brian's, you would need to edit
> > the source code at all usage positions of "import A.B.C". 
> 
> I thought Simons' (and perhaps also Brian's) still allowed package
> juggling from the command line - is that incorrect?  I.e. is "import
> from.." intended to be the *only* way of specifying packages?

Hmm.  I am all in favour of removing the ability to name packages on the
commandline, making the source code the definitive specification.  (But
I have the impression that the other proposals do in fact want to allow
both ways of naming packages - source and environment.)

> And another issue: presumably the source code is prioritized, so if
> the cabal file (or command line) specifies -package foo > v2, but the
> sources specify "foo-2.0", the compilation will fail if only foo-2.1
> is installed?

Just one example of why it is better to have only one way of naming the
package dependencies.  The whole question of conflicts between source and
command-line is nasty.

> Cabal lets you specify package dependencies, at least for the program
> as a whole - doesn't that mean it would have to rewrite the source
> before compilation?

If the packages are named in the source, then an automated tool can
gather all the dependencies and write the Cabal file for you.  The Cabal
file is descriptive, not prescriptive.  I see it essentially as a cache
of information (packages needed, source file names, language extensions)
that is otherwise already available directly from the source in a
scattered fashion.

> > With my proposal, you could organise
> > your source code such that only a single file might need to be
> > edited, replacing say
> >     module Foo (namespace F) where
> >     import namespace "foo" as F
> > with
> >     module Foo (namespace F) where
> >     import namespace "myfoo" as F
> 
> I think you can do this, as long as symbols are annotated with package
> names.  Even if only command line options are available, you can do
> something like: 
> 
>   {-# OPTIONS -package foo #-} -- or replace with myfoo
>   module F where
>   import Foo

No, I think you missed the point.  Let's say there are 30 files that
import modules from the package "foo".  At the moment, and with the
current proposal, when you decide to replace "foo" with "myfoo", you
must edit all 30 files to change the OPTIONS line (or the "import from"
specs).

The key new concept in my proposal, by contrast, is that you can manage
the visibility of namespaces separately from the particular usages of
the namespace (i.e. module imports).  This makes it possible to locate
the specification of package "foo" in a single file, and when you change
to "myfoo", only the one file needs to be edited.

> PS: Is it correct that -- except for the new functionality in
> symbols being annotated with package as well as module name -- all of
> this is just a matter of convenience/syntactic sugar?  (Which would
> explain the volume of the discussion :-)

For the current proposal, yes.  For my extended proposal, no, it
introduces a new language concept that was not previously expressible.

Regards,
    Malcolm