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/