On Mon, 25 Dec 2006 09:52:47 -0800, you wrote:
To my eye, your example code below looks less like an imperative
program than like an intermediate form that a compiler would generate
from an expression built up from nested function applications and a
few lets.
That's very true, but the same could
I like monadic reformulations when they remove repetitious patterns from
code, such as reading/updating a single threaded state. I'm not yet seeing
such a pattern in your case. As you mentioned:
The shape of the
state isn't constant throughout the process. At any given step, new
information
I know people just had a discussion about not answering simple questions with
unsafe! or arrows! or OOHaskell! or oleg! But here is an answer that uses
Control.Arrow just for the function combinators:
Steve Schafer wrote:
In my text/graphics formatting work, I find myself doing a lot of
Having just done a major refactor of the HAppS HTTP API to make it
much much easier to use, I am now thinking about simplifying the
current boilerplate associated with XML serialization and state
deserialization.
In the case of XML, Currently the developer must manually write
ToElement for
== Deserialization ==
HAppS periodically checkpoints application state to disk.
Developers may want to add or remove fields from their state types
for from data types used by their state types. The current
solution is to have the developer assign a version number to
state. If state
Hi folks,
I'm working on a program that I've been dabbling with for years. For the
first time, I tried to compile it with GHC 6.6, and got an error,
explaining that I was violating the Coverage Condition in my instance
declaration. The instance declaration looks like this:
instance MonadReader r
On Tue, Dec 26, 2006 at 07:01:52PM -0500, [EMAIL PROTECTED] wrote:
I'm working on a program that I've been dabbling with for years. For the
first time, I tried to compile it with GHC 6.6, and got an error,
explaining that I was violating the Coverage Condition in my instance
declaration. The
On Tue, 26 Dec 2006 10:28:22 -0800, you wrote:
So I'm still doubtful that a monadic approach is going to simplify your
code. Would you give a real example of some code you'd like to make more
manageable? If you have real examples of State, Reader, and/or Writer
monads that strike you as
On Tue, 26 Dec 2006 18:29:43 +, you wrote:
-- process :: a - b - c - d - e
process x1 x2 x3 x4 =
let y01 = f01 x1 x2 x3
in ($ x1) (f02 f03 f04 f05 x1 y01 f06 x2 f07 y01
first f08 uncurry (f09 x2 x4)
first (f10 f11 f12 x1 x2 x3
Steve,
How would this example look if you named only multiply-used expressions?
I'd like to see it in a more conventional pointful style with nested
expressions. I'm still wondering whether the awkwardness results from your
writing style or is more inherent. Showing the real variable names may
All of this code, including the original, looks like compiler output to me.
If we're talking about easy to understand reformulations, how about we start
with some compiler input instead?
On 12/26/06, Chris Kuklewicz [EMAIL PROTECTED] wrote:
I know people just had a discussion about not
11 matches
Mail list logo
