Quantcast

formal treatment of module dependencies

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

formal treatment of module dependencies

Dimitri DeFigueiredo
It seems to me that specifying and solving module dependencies is a
ubiquitous problem in software development.
All the languages that I know try to make the problem go away by using
version numbers and maximizing backward compatibility.

Does anyone know of references that formalize this problem for Haskell?

Thanks,

Dimitri

--
2E45 D376 A744 C671 5100 A261 210B 8461 0FB0 CA1F


_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: formal treatment of module dependencies

Johannes Waldmann-2
> specifying and solving module dependencies

related: http://www.mancoosi.org/papers/
(not for Haskell modules, but for Debian-like package specs)

PS: keep in mind that even the most elaborated versioned
dependency mechanism is just a work-around - as long as
we don't have *all* software  properties in the types.
Only then could we have a formal proof
that a module A can use module B2 instead of module B1, etc.
And, we do not "just" want correctness w.r.t. a specification,
but also resource consumption.

- J.W.
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Loading...