Steve Lihn | 19 Dec 18:59

DSL question -- was: New slogan for haskell.org

Thanks for the explanation on DSL. It helped me understand how Haskell
works compared to other popular languages out there. It is a
programming methodology change. Or what is called paradigm change on
how to design a software with Haskell.

Haskell has its general-purpose features. Yet its strength is the
ability and ease of defining DSL by utilizing the higher order
\"stuff\" (like type class, composite function, monads, and arrows),
which to say the least, can be quite abstract and challenging.

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?

-- steve

On 12/11/07, Brandon S. Allbery KF8NH <allbery <at> ece.cmu.edu> wrote:
>
> > * Domain Specific Language (who needs it? other than academics and
> > Wall Streeter?)
>
> DSELs can be thought of as a programming methodology; as such, it has
> wide applicability, but most programmers don\'t think that way.  Tcl
> was originally positioned as a \"DSEL enabler\" (write composable
> functions in C, tie them together in Tcl), but most programmers
> \"don\'t get it\" and so don\'t tend to use it as such.  More recently,
(Continue reading)

Mattias Bengtsson | 19 Dec 19:13
Favicon

Re: DSL question -- was: New slogan for haskell.org

On Wed, 2007-12-19 at 13:03 -0500, Steve Lihn wrote:
[snip]
> 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? 

I can't think of anything in the pure concept of Domain Specific
Languages that would make them hard or impossible to debug. You'd only
have to write a good debugger for the language.

> And how does it apply to Haskell?

A DSL embedded in Haskell has the advantage (and disadvantage) of being
normal Haskell code, hence the normal Haskell debuggers will work.
However, if the EDSL is presented as an entirely new language then
non-Haskellers will obviously have problems understanding the generic
Haskell debugger and error messages.

Mattias
Favicon

Re: DSL question -- was: New slogan for haskell.org


On Dec 19, 2007, at 13:03 , Steve Lihn wrote:

> 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?

In the general case, you would need to design into your DSL both  
ability to debug programs written in it, and ability to debug its  
runtime/implementation.  With experience, you can make the latter  
easier but in the case of complex DSLs even the best runtime support  
can be tricky.

But in Haskell, not only is your DSL implemented in Haskell but it is  
implemented *as* Haskell combinators, so you can use the existing  
Haskell debugging features, *and* the implementation behaves like any  
other Haskell program so you are more likely to be able to figure out  
what's going on inside it given a reasonable debugging environment.   
The problem there being that debugging support is still fairly new in  
GHC 6.8.x (and well-nigh nonexistent in other Haskell  
implementations) and evolving.

--

-- 
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery <at> kf8nh.com
system administrator [openafs,heimdal,too many hats] allbery <at> ece.cmu.edu
electrical and computer engineering, carnegie mellon university    KF8NH
Bill Wood | 19 Dec 21:12
Favicon

Re: DSL question -- was: New slogan for haskell.org

On Wed, 2007-12-19 at 13:03 -0500, Steve Lihn wrote:
   . . .
> 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?

Lisp has long been touted as a good language for developing a DSL, one
reason being it's macro system.  However, it has also long been realized
that DSLs implemented with macros can be extremely difficult to debug
because by the time bugs manifest the (macro) source is long gone and
its connection to the expansion text is difficult to determine.

 -- Bill Wood
Bjorn Buckwalter | 26 Dec 18:56
Gravatar

Re: DSL question -- was: New slogan for haskell.org

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.
(Continue reading)

Steve Lihn | 27 Dec 04:28

Re: Re: DSL question -- was: New slogan for haskell.org

>        arising from use of `/' at DSLTest.hs:11:14-28

Thanks for the example. I am particularly amazed GHC is complaining at
'/', not '+'. The type mismatch occurs (is reported) at much lower
level. It would be nice if there is a way to bump it up a couple
levels...

On Dec 26, 2007 12:56 PM, Bjorn Buckwalter <bjorn.buckwalter <at> gmail.com> wrote:
> 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
(Continue reading)

Lutz Donnerhacke | 27 Dec 05:26
Favicon

Re: Re: DSL question -- was: New slogan for haskell.org

* Steve Lihn wrote:
> Thanks for the example. I am particularly amazed GHC is complaining at
> '/', not '+'. The type mismatch occurs (is reported) at much lower
> level. It would be nice if there is a way to bump it up a couple
> levels...

Add type signatures for mu and dont_try_this.
Bjorn Buckwalter | 27 Dec 13:53
Gravatar

Re: Re: DSL question -- was: New slogan for haskell.org

On Dec 26, 2007 10:28 PM, Steve Lihn <stevelihn <at> gmail.com> wrote:
> >        arising from use of `/' at DSLTest.hs:11:14-28
>
> Thanks for the example. I am particularly amazed GHC is complaining at
> '/', not '+'. The type mismatch occurs (is reported) at much lower
> level. It would be nice if there is a way to bump it up a couple
> levels...

I suppose that is how the type inferencer works. To start with all it
really "knows" is the types of 'phi' and 'mu'. Since it knows the type
of 'mu' it can assume that 'v_GEO' has the same type, and from the
definition of 'v_GEO' (and 'phi') it can infer a type for 'r_GEO'. But
when checking that assumption against the definition of 'r_GEO' which
depends on only 'phi' and 'mu' it realizes that things are amiss. (I'm
just guessing here, the order, or way, in which the compiler does
stuff may be totally different.)

To be fair to the compiler it really has no way of knowing which
definition is wrong without explicit type signatures. As I noted in my
previous reply adding type signatures to all definitions allows the
compiler to locate the error:

  In the second argument of `(+)', namely `mu'
      In the expression: v_GEO + mu

I added this as an example to the library wiki[1]. The version of the
code with type signatures is there and the whole page can be
copy-pasted as literate haskell if you want to try it:

[1] http://code.google.com/p/dimensional/wiki/ErrorMessagesAndDebugging
(Continue reading)


Gmane