[Haskell-cafe] Re: DSL question -- was: New slogan for haskell.org

[Bjorn Buckwalter]

Steve Lihn <stevelihn <at> gmail.com> writes:

> I do come aross a question while reading the DSL page on Wikipedia.
> 
> http://en.wikipedia.org/wiki/Domain-specific_programming_language
> 
> In the Disadvantage section (near the end), there is an item -- hard
> or impossible to debug. Can anybody explain why or what it means? And
> how does it apply to Haskell?


I think I can give a good example of how this can apply to EMBEDDED DSLs. My
library Dimensional (http://dimensional.googlecode.com) defines what someone
referred to as a EDSL for working with physical units. The library leverages the
Haskell type checker to provide static checking of physical dimensions. Without
 doing this I don't know how I could make such checking static.

The downside of this is that while you will be informed at compile time if you
physical calculations are incorrect the error message itself is rarely useful.
Here is an example with lines numbered:

  1 import Numeric.Units.Dimensional.Prelude
  2 import qualified Prelude
  3
  4 -- The angular velocity of Earth's rotation (Soop p. 7).
  5 phi = 360.985647 *~ (degree / day)
  6
  7 -- The gravitational parameter of Earth.
  8 mu = 3.986004400008003e14 *~ (meter ^ pos3 / second ^ pos2)
  9
 10 -- The ideal geostationary radius and velocity.
 11 r_GEO = cbrt (mu / phi ^ pos2)
 12 v_GEO = phi * r_GEO
 13
 14 -- Something obviously wrong.
 15 dont_try_this_at_home = v_GEO + mu

Obviously we shouldn't be adding a velocity to a gravitational parameter on line
15 and the compiler will catch this. However, this is the error message from
GHCi (6.6.1):

DSLTest.hs:1:0:
    Couldn't match expected type `Numeric.NumType.Neg n'
           against inferred type `Numeric.NumType.Zero'
    When using functional dependencies to combine
      Numeric.NumType.Sub a Numeric.NumType.Zero a,
        arising from the instance declaration at Defined in Numeric.NumType
      Numeric.NumType.Sub Numeric.NumType.Zero
                          Numeric.NumType.Zero
                          (Numeric.NumType.Neg n),
        arising from use of `/' at DSLTest.hs:11:14-28

I think you will agree that this isn't very helpful in pin-pointing the problem.
The compiler is pointing at the definition of 'r_GEO' which is twice removed
from the actual offender. Stuff like this can make EDSLs difficult to debug.

(In this particular example adding type signatures to all definitions will allow
the compiler to pin-point the error to line 15, although the error message
remains cryptic.)

Hope that helps,
Bjorn