[GHC] #7870: Compilatio​n errors break the complexity encapsulat​ion on DSLs, impairs success in industry

[GHC]

#7870: Compilatio​n errors break the complexity encapsulat​ion on DSLs, impairs
success in industry
-----------------------------+----------------------------------------------
Reporter:  agocorona         |          Owner:                         
    Type:  feature request   |         Status:  new                    
Priority:  normal            |      Component:  Compiler (Type checker)
 Version:  7.7               |       Keywords:  DSL, Error,            
      Os:  Unknown/Multiple  |   Architecture:  Unknown/Multiple       
 Failure:  None/Unknown      |      Blockedby:                         
Blocking:                    |        Related:                         
-----------------------------+----------------------------------------------
 From the paper "Scripting the Type Inference Process" -Bastiaan Heeren
 Jurriaan Hage S. Doaitse Swierstra:


 ... Combinator languages are a means of defining domain specific languages
 embedded within an existing programming language, using the abstraction
 facilities present in the latter. However, since the domain specific
 extensions are mapped to constructs present in the underlying language,
 all type errors are reported in terms of the host language, and not in
 terms of concepts from the combinator library. In addition, the developer
 of a combinator library may be aware of various mistakes which users of
 the library can make, something which he can explain in the documentation
 for the library, but which he cannot make part of the library itself.

 ...As a result, the beginning programmer is likely to be discouraged from
 pro-gramming in a functional language, and may see the rejection of
 programs as a nuisance instead of a blessing. The experienced user might
 not look at the messages at all.

 Definitively this is probably the biggest barrier for the acceptance of
 Haskell on Industry. We need to start with something not as sophisticated
 as  the Helium paper "Scripting the Type Inference Process", but maybe a
 partial implementation of the techniques mentioned, so that the
 development can be enhanced in the future.

 Maybe some kind of  library that permits postprocessing of GHC errors
 and/or the identification of points in the current type checker where some
 kind of rules can be defined by the programmer can be the first step.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7870>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler