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 signature and all functions using it have to be modified. Also, I expect that the explicit passing causes a small performance penalty.

Can't this be mostly solved by putting all these configuration parameters in a struct and then using implicit parameters:

http://www.haskell.org/ghc/docs/latest/html/users_guide/other-type-extension...

The nice thig about this approach is that is not a single unsafe operation needed.

that would work sufficiently if we had support partial type signatures, e.g. could specify the types of functions “up to” implicit parameters. Then, using a parameter somewhere where it was not used before does not require propagating code changes. Also, implicit parameters have the feature that they can be changed locally. Note that using unsafe operations is not a problem if the compiler can verify that they are not unsafe after all, which is what I am hoping for. Let me motivate my approach by an analogue. All our existing Haskell programs would be fine without the type systems, just writing new ones would be more difficult. This is because the type systems (basically) only limits the set of valid programs, while enforcing some correctness condition (here: type safety). This is analogous to using a regular expression to define some language of valid words, e.g. well-formed e-mail-addresses. Now assume we want to add an additional check, e.g. that the address contains one of a list of keywords, anywhere. We could create a second regular expression of the form ".*(word1|word2|...).*" and make sure both regular expressions match. Alternatively, using our CS education, we know we could construct a single regular expression that accepts the intersection of the two languages. But we would not do that, because the expression would become horribly convoluted. Back to my proposal, I see a similar pattern here. We have a good type system to enforce type safety. Now I come along and want to enforce a different, additional constraint (correct use of run-time constants). I could try hard to enforce it in the type systems, making it more complicated and maybe interfering with other uses of it. Or I could add a second checker that, orthogonal to and maybe using results of the type checker, enforces this condition. I’d even go a step further and say that having an accessible, extensible interface in ghc to add additional checks, that also allows to export “type” signatures in the module interfaces, would open a door to many more possible improvements. For example, the recently added notion of Safe modules falls into this category. Now imagine that you’d not have to hack on ghc itself but just build a Haskell library and specify some flag during compilation to add a new property verifying layer to the language, like bounding rounding errors in floating point calculations, or even an interface to a full theorem proof checker... but I digress. :-) Greetings, Joachim -- Joachim "nomeata" Breitner mail@joachim-breitner.de | nomeata@debian.org | GPG: 0x4743206C xmpp: nomeata@joachim-breitner.de | http://www.joachim-breitner.de/

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 you are already building on a transformer stack, adding yet another layer is not a problem. I’m having mainly pure code in mind.

...

Also, I expect that the explicit passing causes a small performance penalty.

We're been processing gigabytes of data - doing non-trivial operations including a kind of image recognition and more - so far with nearly imperceptible delay. The bottleneck, if there is one, will certainly not be the configuration subsystem.

Hmm, maybe I am underestimating ghc, but I’d expect that while it could create very good code for some tight recursion loop in the IO monad, I’m not so confident that it could do that for a recursion in (ReaderT IO) or an even more complex monad stack. But you are right, other than this special case, the performance issues are surely not in setting parameters.

What case are you thinking about? A system several orders of magnitude more complex? Some special case that creates difficulty?

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 indeed less of a problem. Greetings, Joachim -- Joachim Breitner e-Mail: mail@joachim-breitner.de Homepage: http://www.joachim-breitner.de Jabber-ID: nomeata@joachim-breitner.de

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 same parameters". Here, "always" really means "always", and does not depend on the run-time context of the program. So obviously, a really pure function can't use side-effect run-time constants. IIUC, what you want is "run-time qualified" functions, or functions that "In the scope of a run, always produce the same result when given the same parameters". Is that right ? -- Paul