The Monad.Reader - http://www.haskell.org/tmrwiki/IssueTwo
For issue two, the subjects are Template Haskell, better module compatibility, exploring dark corners of GHC, domain specific languages, and the Foreign Function Interface. We've also switched to an experimental wikipublishing format, in hopes of removing the bottlenecks that showed up in the first issue, and encouraging more peer review. We'd like to hear your feedback! http://www.haskell.org/tmrwiki/IssueTwo -- It seems I've been living two lives. One life is a self-employed web developer In the other life, I'm shapr, functional programmer. | www.ScannedInAvian.com One of these lives has futures (and subcontinuations!)| --Shae Matijs Erisson
On Mon, May 02, 2005 at 08:16:12AM +0200, Shae Matijs Erisson wrote:
Dear Haskellers, Even though it's a plug, I'd like to seperately announce my article for this issue, because it grew out of discussion on this list. I'd posted some thoughts on the versioning of module interfaces a few months back, in reply to a post by Alexander Jacobson. Subsequent discussion and re-thinking have lead to the idea that, basically by appending version numbers to module names, the compatibility problem can be solved without any language extensions, in perfect synergy with Cabal and Hackage, and with very little effort on part of the programmer. It's not a ground-breaking discovery. It's a trivial idea, really; but strangely, it seems that nobody does it. So I tried to think the scenario through, to find problems and clarify my idea. The result is the article Eternal Compatibility in Theory http://www.haskell.org/tmrwiki/EternalCompatibilityInTheory In short, I didn't find any problems and adopted the scheme for one of my own modules. I think it would be great if we could solve the problem of "creeping incompatibility", whether by my idea or otherwise. So if you're interested, please have a look at the article and let me know of your experience should you try it out! Best regards, Sven Moritz Hallberg PS: Last but not least, everyone should of course check out the other great articles, too!
Eternal Compatibility in Theory http://www.haskell.org/tmrwiki/EternalCompatibilityInTheory
Some thoughts: Is there a way to reliably and automatically check if two versions of a haskell module are interface compatible? This would greatly aid the process of deciding when to create a new numbered version of the module. It would be interesting to see if this process could be (semi)automated using the darcs "trackdown" command with such a test.
robert dockins <robdockins@fastmail.fm> writes:
Is there a way to reliably and automatically check if two versions of a haskell module are interface compatible?
No, because it would have to check whether the semantics of functions is the same, even if they are written differently. -- __("< Marcin Kowalczyk \__/ qrczak@knm.org.pl ^^ http://qrnik.knm.org.pl/~qrczak/
Is there a way to reliably and automatically check if two versions of a haskell module are interface compatible?
No, because it would have to check whether the semantics of functions is the same, even if they are written differently.
Of course, we cannot expect the computer to examine the semantics. We must rely on people to know when semantics change. Suppose I want to ask the easier question "do these two text files implement haskell modules which are _type_ compatable?", how would I do it? Ie, I want the test to fail if I change the type of some function foo, or if I add a method to a class declaration etc.
On Mon, 2 May 2005, robert dockins wrote:
Suppose I want to ask the easier question "do these two text files implement haskell modules which are _type_ compatable?", how would I do it? Ie, I want the test to fail if I change the type of some function foo, or if I add a method to a class declaration etc.
A test module containing code that uses every function and has an instance of every class would do that much. You can extend that to check various other properties you expect to hold. -- flippa@flippac.org "My religion says so" explains your beliefs. But it doesn't explain why I should hold them as well, let alone be restricted by them.
On Mon, 2005-05-02 at 15:57 -0400, robert dockins wrote:
Is there a way to reliably and automatically check if two versions of a haskell module are interface compatible?
No, because it would have to check whether the semantics of functions is the same, even if they are written differently.
Of course, we cannot expect the computer to examine the semantics. We must rely on people to know when semantics change.
Suppose I want to ask the easier question "do these two text files implement haskell modules which are _type_ compatable?", how would I do it? Ie, I want the test to fail if I change the type of some function foo, or if I add a method to a class declaration etc.
You can extract this information from ghc's .hi files. You'd need to filter and munge the info a bit but take a look at the output from $ ghc --show-iface Blah.hi It would be useful to have a tool that emits the 'signature' of a module so you can compare between versions for API changes. Duncan
robert dockins wrote:
Is there a way to reliably and automatically check if two versions of a haskell module are interface compatible?
No, because it would have to check whether the semantics of functions is the same, even if they are written differently.
Of course, we cannot expect the computer to examine the semantics. We must rely on people to know when semantics change.
Suppose I want to ask the easier question "do these two text files implement haskell modules which are _type_ compatable?", how would I do it? Ie, I want the test to fail if I change the type of some function foo, or if I add a method to a class declaration etc.
_______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Is this true? Can't you use an IDL to specify the interface more exactly. I would have thought a definition of the protocol was enough. If you define a protocol definition language then it should be possible to check both ends of the connection to see if the conform to the protocol. Keean.
participants (7)
-
Duncan Coutts -
Keean Schupke -
Marcin 'Qrczak' Kowalczyk -
Philippa Cowderoy -
robert dockins -
Shae Matijs Erisson -
Sven Moritz Hallberg