Joachim point taken, if you are already building on a transformer
Joachim stack, adding yet another layer is not a problem. I’m having
Joachim mainly pure code in mind.
I think we need an other word than pure here. Usually, we understand
pure as always producing the same result when given the
Hi,
Am Donnerstag, den 08.09.2011, 09:21 +0200 schrieb Paul R:
Joachim point taken, if you are already building on a transformer
Joachim stack, adding yet another layer is not a problem. I’m having
Joachim mainly pure code in mind.
I think we need an other word than pure here. Usually, we
Hi,
Am Dienstag, den 06.09.2011, 08:15 +1000 schrieb Erik de Castro Lopo:
Joachim Breitner wrote:
The big downside is the verbosity of the approach: A lot of parameters
need to be passed, and if one such value is suddenly required in a
function where it was not before, this function’s
Joachim Breitner wrote:
...Usually in Haskell, you’d determine them in the main function and then
pass them in an argument to all functions needing them, or you wrap that
in a monad...
The big downside is the verbosity of the approach: A lot of parameters
need to be passed, and if one such
Joachim Breitner m...@joachim-breitner.de writes:
Hi Cafe,
this is an idea that has been floating in my head for a while, and I’m
wondering about its feasibility and, if feasible, complexity (in the
range from „trivial“ over “blog post” over “paper” to “thesis”).
Application authors in
Hi Jon,
Am Dienstag, den 06.09.2011, 14:01 +0100 schrieb Jon Fairbairn:
Joachim Breitner m...@joachim-breitner.de writes:
this is an idea that has been floating in my head for a while, and I’m
wondering about its feasibility and, if feasible, complexity (in the
range from „trivial“ over
Hello,
Am Dienstag, den 06.09.2011, 15:17 +0300 schrieb Yitzchak Gale:
We're talking about passing a single parameter - a record type,
or a shallow tree, or something else extremely simple.
In the monadic case, we're adding a single Reader component
to the transformer stack.
point taken, if
On 6 September 2011 15:33, Joachim Breitner m...@joachim-breitner.de wrote:
I think the benefit you get from being able to treat runtime constants
as plain values manifests mostly when writing pure code. If your code
has already been written or re-written in monadic style, adding a
Hi Cafe,
this is an idea that has been floating in my head for a while, and I’m
wondering about its feasibility and, if feasible, complexity (in the
range from „trivial“ over “blog post” over “paper” to “thesis”).
Application authors in Haskell often face the problem of run-time
constants, e.g.
On Mon, Sep 5, 2011 at 1:43 PM, Joachim Breitner
m...@joachim-breitner.de wrote:
Do you think this could be useful (from a user point of view)? Has this
idea maybe already been proposed?
How does it compare with Oleg's typeclass approach?
http://okmij.org/ftp/Haskell/types.html#Prepose
--
Hi,
Am Montag, den 05.09.2011, 14:35 -0400 schrieb Gwern Branwen:
On Mon, Sep 5, 2011 at 1:43 PM, Joachim Breitner
m...@joachim-breitner.de wrote:
Do you think this could be useful (from a user point of view)? Has this
idea maybe already been proposed?
How does it compare with Oleg's
Joachim Breitner wrote:
The big downside is the verbosity of the approach: A lot of parameters
need to be passed, and if one such value is suddenly required in a
function where it was not before, this function’s signature and all
functions using it have to be modified. Also, I expect that the
On Mon, Sep 5, 2011 at 3:15 PM, Erik de Castro Lopo mle...@mega-nerd.comwrote:
Can't this be mostly solved by putting all these configuration parameters
in a struct and then using implicit parameters:
Implicit parameters seem like a fair option. And propagating:
(?fooConf :: FooConf) =
13 matches
Mail list logo
