[Haskell-cafe] Re: Proposal: register a packageasprovidingseveralAPI versions
Ketil Malde wrote: Claus Reinke [EMAIL PROTECTED] writes: Incedentally, this reminds me that GHC should have a warning for not using explicit import lists (perhaps only for external package imports). for package-level imports/exports, that sounds useful. Isn't there a secret key combination in haskell-mode for Emacs that populates the import lists automatically? No emacs command that I know of, but GHC has the -ddump-minimal-imports flag. Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Proposal: register a packageasprovidingseveralAPI versions
These two cases could be solved by re-exports, no extra mechanism is required. yes, good support for re-export would be nice to have. the reason it has so many applications is that it is a way to explain connections between providers, apis, and clients to the package manager. - consider adding a new monad transformer to a monad transformer library, or a new regex variant to a regex library - surely the new package version can still provide for clients of the old version This case doesn't work - if you add *anything* to a library, I can write a module that can tell the difference. So whether your new version is compatible in practice depends on the client. of course you can. but then you're writing new code. my concern was with old code that was written to the old api and that would still work with an extended api. i was suggesting a warning if code was compiled against an older api in any case. you're right, if you can design new code that will notice the additions, then there's a chance that old code might stumble over them. if that breaks compilation, the programmer would see the error message preceded by an old-api warning, so it should be obvious what to do - either adapt the package to the new api, or make sure that it cannot see anything but the old api. unfortunately, packages are specified entirely at the level of module names. as far as the package manager is concerned, anything that exposes the same modules is compatible, the breakage comes when the package manager calls the compiler. so we can't say that the old package should import only specific items from the old api, because that api is specified only in the haddock comments, not in any package spec. and then there are the nasty cases, where adding instances might change compilation results without breaking compilation. - consider various packages providing different implementations of an api, say edison's - surely any of the implementations will do for clients who depend only on the api, not on specifics Yes, and in this case we should have another package that just re-exports one of the underlying packages. what you're suggesting is to make an intermediate package act as an api spec: instead of clients depending directly on providers, they depend on the api spec package, and the api spec package knows which providers can implement it. You seem to want to add another layer of granularity in addition to packages, and I think that would be unnecessary complexity. well, what is ever necessary?-) but i thought the discussion had already made clear that cabal specs do not provide sufficient information to - guarantee package compatibility - delimit usage of apis in clients - find providers implementing apis - keep old packages working with new providers, instead of preserving/packaging all packages forever which means that there's more need to update cabal specs and to use other means (central repo at hackage with autobuild reports, etc) to ensure that everything keeps working. that means more work than necessary, more breakage and less safety than desirable (for a formal take on package safety, refer to Standard ML's system, with structures, functors, and interfaces as a statically typed functional package and module composition language; just add an rcs for package versions). claus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Proposal: register a packageasprovidingseveralAPI versions
Incedentally, this reminds me that GHC should have a warning for not using explicit import lists (perhaps only for external package imports). for package-level imports/exports, that sounds useful. claus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Proposal: register a packageasprovidingseveralAPI versions
Claus Reinke [EMAIL PROTECTED] writes: Incedentally, this reminds me that GHC should have a warning for not using explicit import lists (perhaps only for external package imports). for package-level imports/exports, that sounds useful. Isn't there a secret key combination in haskell-mode for Emacs that populates the import lists automatically? -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Proposal: register a packageasprovidingseveralAPI versions
if that is your definition of compatible, you can never throw any
packages away
Is this a problem?
apparently, yes. no two versions of base with ghc, only the
newest set of core packages with each ghc release. and how
much time do you want to spend on finding, re-building, and
re-installing old packages everytime you move to a new machine?
it isn't (just) about space on a disk, it is about downloads
and management, not to mention sanity of mind;-)
a simpler way of putting the responsibility issue:
- every package writer is responsible for not reducing
the usability of his/her package at every update;
as with a function type, that works both ways:
use the simplest/newest dependencies available,
and keep your package useable by existing clients
so we're not just talking about packages at certain
points in their lifetime, we're talking about the lifetime
of packages in the context of their usage contexts/
package databases.
perhaps we should treat package databases as
distributed revision control system repos with
interlinked dependencies? then, just as darcs did,
we could focus on collections of patches that
create consistent new repos.
instead of this is package P-2.11, deal with it,
it would be something like add package P-2.11;
replace uses of P-2.{0-10} with uses of P-2.11;
remove any packages in that range; rebuild all
packages that used P-2.{0-7} as internal types
have changed; keep all packages P-1.* as this
is not a drop-in replacement for them.
claus
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
