The public interface is exposed in CommonMain#Kw

>>> :set -XDataKinds -XFlexibleInstances -XMultiParamTypeClasses
>>> :set -XScopedTypeVariables -XOverlappingInstances -XTypeFamilies
>>> :set -fcontext-stack=100

We will be using an example inspired by a graphics toolkit -- the area which really benefits from keyword arguments. We first define our labels and useful datatypes

>>> data Color = Color
>>> data Size  = Size
>>> data Origin  = Origin
>>> data RaisedBorder = RaisedBorder

The number of arguments each keyword must be specified by an IsKeyFN instance.

>>> instance IsKeyFN (Color->a->b)  True
>>> instance IsKeyFN (Size->a->b)   True
>>> instance (a ~ (Int,Int)) => IsKeyFN (Origin->a->b) True
>>> instance IsKeyFN (RaisedBorder->a->b) True

Note that if a keyword is always followed by a certain type, that can be specified above using an instance like the one for Origin.

>>> data CommonColor = Red | Green | Blue deriving Show
>>> data RGBColor = RGBColor Int Int Int deriving Show

and two functions:

>>> :{
let make_square Size n Origin (x0,y0) Color (color::CommonColor) =
       unwords ["Square:", show (n :: Int), "at", show (x0,y0), show color] ++ "\n"
:}

>>> :{
let make_rect Size (nx,ny) Origin (x0,y0) Color (color::RGBColor)
        RaisedBorder border =
       unwords ["Rectangle:", show (nx,ny), "at", show (x0,y0),
            show color, if border then "raised border" else ""] ++ "\n"
:}

We are not interested in really drawing squares and rectangles here. Therefore, make_square and make_rect return a String, which we can regard as a `command' to be passed to a low-level graphics library. The functions make_square and make_rect are genuine functions and can be used as such. They are not keyword argument functions, yet, but they set the stage. These functions can be considered an interface for the keyword argument functions. We should note that the functions are polymorphic: for example, Size can be any showable. We must also emphasize the re-use of the labels: The Color of a square is the value of the enumerated type CommonColor. OTH, the color of the rectangle is given as an RGB triple. The sizes of the square and of the rectangle are specified differently too, the same label notwithstanding.

Once the user wrote the functions such as make_square and make_rect, he can _automatically_ convert them to their keyword alternatives. This transformation is done by a function kw. The user should pass the positional-argument function (labeled as above), and an HList of default values for some of the labels. The latter may be HNil if all keyword arguments are required.

The first example (no defaults)

>>> kw (make_square .*. HNil) Size (1::Int) Origin (0,10) Color Red   :: String
"Square: 1 at (0,10) Red\n"

we can permute the arguments at wish

>>> kw (make_square .*. HNil) Color Red Size (1::Int) Origin (0,10)   :: String
"Square: 1 at (0,10) Red\n"

we can also assign a name to a keyword function, or partially apply it:

>>> :{
case kw (make_square .*. HNil) Color Red of
   f -> "here: " ++ f Origin (0,10) Size (1::Int)
:}
"here: Square: 1 at (0,10) Red\n"

Note that it is necessary to use a monomorphic pattern binding here (lambda or case). One way to get around this is to pass f instead of kw f around:

>>> :{
 let f = hEnd $ hBuild make_square Color Red
 in "here: " ++ kw f Origin (0,10) Size (1::Int)
:}
"here: Square: 1 at (0,10) Red\n"

The following is a more interesting example, with the defaults:

>>> :{
let addDef f = f .*. Origin .*. (0,10) .*.
            RaisedBorder .*. True .*.
            HNil
   in kw (addDef make_square) Size (1::Int) Color Red ++
      kw (addDef make_rect)   Color (RGBColor 0 10 255)
                              Size (1.0::Float, 2.0::Float)
:}
"Square: 1 at (0,10) Red\nRectangle: (1.0,2.0) at (0,10) RGBColor 0 10 255 raised border\n"

The argument RaisedBorder is not given, and so the default value is used. Of course, we can override the default:

>>> :{
let addDef f =  f .*. Origin .*. (0,10) .*.
                   RaisedBorder .*. True .*.
                   HNil
in case kw (addDef make_square) Color of
    sq -> case kw (addDef make_rect)  of
     re ->
        sq Red Size (1::Int) ++
        re Color (RGBColor 0 10 255)
            RaisedBorder False
            Size (1.0::Float, 2.0::Float)
:}
"Square: 1 at (0,10) Red\nRectangle: (1.0,2.0) at (0,10) RGBColor 0 10 255 \n"

We have reshuffled a few arguments, just for fun. As you can see, the function `kw make_rect defaults' is polyvariadic indeed. We chose to partially apply Color to the function `kw make_square defaults' -- so that the function sq is positional in its first argument, and keyword in the rest.

If we omit a required argument, we get a type error:

] testse1 = let f x = kw make_square HNil Color Red x
]         in "here: " ++ f Origin (0,10)

  Couldn't match `ErrReqdArgNotFound Size' against `[Char]'
      Expected type: ErrReqdArgNotFound Size
      Inferred type: [Char] ...

The error message seems reasonably clear. Likewise we get an error message if we pass to a keyword function an argument it does not expect:

] testse2 = let f x = kw make_square HNil Color Red x
]         in "here: " ++ f Origin (0,10) Size (1::Int)
]                       RaisedBorder False

  No instances for (Fail (ErrUnexpectedKW RaisedBorder),
            KWApply [Char] (HCons RaisedBorder (:*: Bool HNil)) [Char])
      arising from use of `f' at ...
    In the second argument of `(++)', namely
  `f Origin (0,10) Size (1 :: Int) RaisedBorder False'

The function kw receives the appropriately labeled function (such as make_square) and the HList with default values. The function kw is polymorphic; the overloading is resolved based on the type of the user function *and* on the type of its continuation. The continuation indicates if a keyword argument is forthcoming, or not. In the latter case, kw checks to see if the supplied defaults can provide the values of the still missing arguments. We see therefore that a function type is more than it may appear -- the type of a function is truly a heterogeneous, type level collection! The function kw traverses that collection, thus performing a limited form of reflection on Haskell functions.

One of the key tools of the implementation is kwapply, which applies a function to a polymorphic collection of that function's arguments. The order of the arguments in the collection is irrelevant. The contraption kwapply can handle polymorphic functions with arbitrary number of labeled arguments.

For example, if we define

f1 Size n = show n
f2 Size n Color m = unwords ["size:", show n, "color:", show m]
f3 Origin x Color m Size n =
    unwords ["origin:", show x, "size:", show n, "color:",show m]

then we can run

katest1  = kwapply f1 (Size .*. () .*. HNil)
katest11 = kwapply f1 (Size .*. "Large" .*. HNil)

katest2  = kwapply f2 (Size .*. (1::Int) .*. Color .*. Red .*. HNil)
katest21 = kwapply f2 (Color .*. Red .*. Size .*. (1::Int) .*.  HNil)

katest3  = kwapply f3 (Size .*. (1::Int) .*. Origin .*. (2.0::Float) .*.
                 Color .*. Red .*. HNil)

From oleg-at-okmij.org Fri Aug 13 14:58:35 2004
To: haskell@haskell.org
Subject: Keyword arguments
From: oleg-at-pobox.com
Message-ID: <20040813215834.F1FF3AB7E@Adric.metnet.navy.mil>
Date: Fri, 13 Aug 2004 14:58:34 -0700 (PDT)
Status: OR

We show the Haskell implementation of keyword arguments, which goes well beyond records (e.g., in permitting the re-use of labels). Keyword arguments indeed look just like regular, positional arguments. However, keyword arguments may appear in any order. Furthermore, one may associate defaults with some keywords; the corresponding arguments may then be omitted. It is a type error to omit a required keyword argument. The latter property is in stark contrast with the conventional way of emulating keyword arguments via records. Also in marked contrast with records, keyword labels may be reused throughout the code with no restriction; the same label may be associated with arguments of different types in different functions. Labels of Haskell records may not be re-used. Our solution is essentially equivalent to keyword arguments of DSSSL Scheme or labels of OCaml.

Keyword argument functions are naturally polyvariadic: Haskell does support varargs! Keyword argument functions may be polymorphic. As usual, functions with keyword arguments may be partially applied. On the downside, sometimes one has to specify the type of the return value of the function (if the keyword argument function has no signature -- the latter is the norm, see below) -- provided that the compiler cannot figure the return type out on its own. This is usually only the case when we use keyword functions at the top level (GHCi prompt).

Our solution requires no special extensions to Haskell and works with the existing Haskell compilers; it is tested on GHC 6.0.1. The overlapping instances extension is not necessary (albeit it is convenient).

The gist of our implementation is the realization that the type of a function is a polymorphic collection of its argument types -- a collection that we can traverse. This message thus illustrates a limited form of the reflection on a function.

Our implementation is a trivial extension of the strongly-typed polymorphic open records described in http://homepages.cwi.nl/~ralf/HList/

In fact, the implementation relies on the HList library. To run the code (which this message is), one needs to download the HList library from the above site.

The HList paper discusses the issue of labels in some detail. The paper gives three different representations. One of them needs no overlapping instances and is very portable. In this message, we chose a representation that relies on generic type equality and therefore needs overlapping instances as implemented in GHC. Again, this is merely an outcome of our non-deterministic choice. It should be emphasized that other choices are possible, which do not depend on overlapping instances at all. Please see the HList paper for details.

better instances for Symbol

There isn't a pair (K2 "Origin" (Int, Int)) (K "hi") that behaves just like Origin below. something is possible between constraintkinds. See Fun

instance (a ~ (Int,Int)) => IsKeyFN (Origin->a->b) True

wildcard/catchall

like in R. This would be a special keyword for keyword args that didn't match. They would be put in a HList/Record argument like ...

investigate first-classness of varargs

for whatever reason you can't have f = kw fn blah and then pass more arguments on to fn. This is bad. It used to work (in the ghc6.0 days and probably up to 6.12). Some convenience functions/operators should be added which do the same thing as:

fn `hAppendList` hBuild a b c d e