Backpack: Retrofitting Haskell with Interfaces
Scott Kilpatrick, Derek Dreyer, Simon Peyton Jones, Simon Marlow
Module systems like that of Haskell permit only a weak form of modularity in which module implementations directly depend on other implementations and must be processed in dependency order. Module systems like that of ML, on the other hand, permit a stronger form of modularity in which explicit interfaces express assumptions about dependencies, and each module can be typechecked and reasoned about independently.
In this paper, we present Backpack, a new language for building separately-typecheckable packages on top of a weak module system like Haskell's. The design of Backpack is inspired by the MixML module calculus of Rossberg and Dreyer, but differs significantly in detail. Like MixML, Backpack supports explicit interfaces and recursive linking. Unlike MixML, Backpack supports a more flexible applicative semantics of instantiation. Moreover, its design is motivated less by foundational concerns and more by the practical concern of integration into Haskell, which has led us to advocate simplicity—in both the syntax and semantics of Backpack—over raw expressive power. The semantics of Backpack packages is defined by elaboration to sets of Haskell modules and binary interface files, thus showing how Backpack maintains interoperability with Haskell while extending it with separate typechecking. Lastly, although Backpack is geared toward integration into Haskell, its design and semantics are largely agnostic with respect to the details of the underlying core language.
The scotty-hastache library has been updating, following the introduction of the custom exception types in Scotty. Custom exception types (as opposed to plain-text exception mechanism that was previously employed in Scotty) is a more powerful way of handling exceptional situation; an example usage can be found here. Below are the appropriate release notes for scotty-hastache0.2
Keeping up with the Scotty 0.6 updating. The introduction of the custom exception types is reflected in the scotty-hastache package as well. The main types are now polymorphic over an exception typetype ScottyH e = ScottyT e HState type ActionH e = ActionT e HState
In addition, the specialized (to Text) types and runners are introducedtype ScottyH' = ScottyH Text type ActionH' = ActionH Text scottyH' :: Port -> ScottyH' () -> IO () scottyHOpts' :: Options -> ScottyH' () -> IO ()
Thanks to Kirill Zaborsky for pointing out the incompatibility with 0.6.
Tagged: haskell, scotty, web
I've written the back-end for a simple Bridge (card game) bidding helper in Haskell as my first non-trivial project.
The idea is to expand this into a more useful general Bridge playing system. Before I go further, I'd really appreciate any feedback on the code: idiomatic use of Haskell; libraries I could have used; code formatting; anything!submitted by derek-mcloughlin
[link] [27 comments]
Leap day every 4 years.
Omit leap day every 33*4=132 years.
Keep leap day every 100*33*4=13200 years.
This sequence of multipliers [4,33,100] were found by the greedy method. The entire cycle has the same average year length as the Gregorian calendar = 365 + 97/400 days, which uses multipliers [4,25,4]. We alternate between keeping and omitting leap days at each larger multiplier.
countDays accum (h:t) offset = countDays (accum*h+offset) t (negate offset);
countDays accum  _ = accum;
averageYear :: [Integer] -> Rational;
averageYear leapPattern = (countDays 365 leapPattern 1) % (product leapPattern)
What is going on such that averageYear [4,33,100] == averageYear [4,25,4]? Find a set of multipliers which minimizes the product, i.e., cycle length. I suspect this is related to Egyptian fractions or continued fractions. I suspect that the greedy method yields a sequence which monotonically increases.
Update: these are Pierce expansions, a variant of Engel expansions.
Applying the greedy algorithm to 365 + 71/293 days (as proposed by the Symmetry454 calendar) yields multipliers [4,32,58,97,146,293] for a cycle of 11251521835008 days in 30805635584 years. (This is far less efficient than the 293 year cycle.)
When applied to adding "leap weeks" to the Gregorian calendar, we find the sequence [5,8,10] as reported in calendar based on 7. If we apply leap weeks to the 365+71/293 year-length, we get the sequence [5,8,10,97,146,293].