[Haskell-cafe] Solving the configuration problem with parametrized modules

[Joachim Breitner]

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-extensions.html#implicit-parameters
> 
> 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 at joachim-breitner.de  |  nomeata at debian.org  |  GPG: 0x4743206C
  xmpp: nomeata at joachim-breitner.de | http://www.joachim-breitner.de/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20110906/66acc263/attachment-0001.pgp>