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. Usua
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
On 6 September 2011 15:33, Joachim Breitner 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
> transformation layer is indee
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,
Hi Jon,
Am Dienstag, den 06.09.2011, 14:01 +0100 schrieb Jon Fairbairn:
> Joachim Breitner 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 “blog post” over “pa
Joachim Breitner 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 Haskell often face th
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 suc
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 functi
On Mon, Sep 5, 2011 at 3:15 PM, Erik de Castro Lopo wrote:
> 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) => ...
isn't any more
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
Hi,
Am Montag, den 05.09.2011, 14:35 -0400 schrieb Gwern Branwen:
> On Mon, Sep 5, 2011 at 1:43 PM, Joachim Breitner
> 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?
On Mon, Sep 5, 2011 at 1:43 PM, Joachim Breitner
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
--
gwern
http://www.gwern.net
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. v
13 matches
Mail list logo