[Haskell-cafe] Re: [Haskell] Re: Trying to install binary-0.4

[Claus Reinke]

> However, I'd like to separate it from Cabal.  Cabal provides mechanism not 
> policy, regarding version numbers.

but the examples in the cabal docs should reflect the standard 
interpretation of version numbers.
 
>> of course, i have absolutely no idea how to write stable packages under
>> this interpretation. and the examples in the cabal docs do not explain 
>> this, either (neither "bar" nor "foo > 1.2" are any good under this 
>> interpretation).
> 
> base >= 2.0 && < 3.0

that only works if older versions of base are kept side by side
with base >= 3.0. otherwise, any package with that range will
refuse to build (which may be better than failing to build), even
though nothing in that package has changed, and all the features
it depends on are still available.

> Omitted only because it isn't implemented.  Well, it is implemented, 
> on my laptop, but I'm not happy with the design yet.

i look forward to hearing more. here, you say you are working
on an implementation; earlier, you said that re-exporting modules
via several packages was not the way forward.

>> cabal is fairly new and still under development, so there is no need to
>> build in assumptions that are sure to cause grief later (and indeed are
>> doing so already).
> 
> what assumptions does Cabal build in?

its documentation is not very precise about what version numbers
mean. going by the examples, i thought that 'base' was an acceptable
dependency, but it isn't. i also assumed that lower bounds (foo > 1.2)
could be relied on, but they can't. perhaps i'm the only one reading the
cabal docs this way, but i feel mislead!-) and even if i translate your
versioning scheme into cabal dependencies, i end up with explicit
version ranges as the only valid option, so the assumption becomes
that every package *will* break as its dependencies move on.
 
>> how about using a provides/expects system instead of betting on
>> version numbers? if a package X expects the functionality of base-1.0,
>> cabal would go looking not for packages that happen to share the name,
>> but for packages that provide the functionality. 
> 
> Using the version number convention mentioned earlier, "base-1.0" 
> funcionality is provided by base-1.0.* only.  A package can already specify 
> that explicitly.

not entirely correct. you said that major versions implied api changes.
that does not imply that the api is no longer backwards compatible, 
only that there are sufficiently substantial new features that a version
naming them seems called for. while base breaks backwards 
compatibility, other packages might not do so. 

and cabal does not allow me to specify anything but a name and a 
range of numbers as dependencies (there is exposed-modules:, but
no imported-modules:), so i can't say which parts of base-1.0 my 
package depends on, and cabal can't decide which versions of 
base might be compatible with those more specific dependencies.
 
> I think what you're asking for is more than that: you want us to provide 
> base-1.0, base-2.0 and base-3.0 at the same time, so that old packages 
> continue to work without needing to be updated.  That is possible, but much 
> more work for the maintainer.  Ultimately when things settle down it might 
> make sense to do this kind of thing, but right now I think an easier 
> approach is to just fix packages when dependencies change, and to identify 
> sets of mutually-compatible packages (we've talked about doing this on 
> Hackage before).

yes. it's called automatic memory management!-) as long as there's
a package X depending on package Y-a.b, package Y-a.b should
not disappear. not having to waste time on such issues is one reason
why programmers are supposed to prefer haskell over non-functional
languages, right?-)

claus