2009/12/4 Roman Salmin
_So my strong opinion that solution is only DSL not EDSL_
Why do you think they will learn your DSL, if they don't learn any other language? I didn't said that they didn't learn any language. They learn languages, but only part that is necessary to do particular task. f.e. ROOT CINT(C++ interpreter) didn't distinguish object from pointer to object, i.e. statement h.ls(); works as well as h->ls(); independently of either h has type TH1F or TH1F*, so beginning ROOT user didn't need know what is pointer, memory management helps him. But early or latter one need to write more complicated code,
On Fri, Dec 04, 2009 at 01:43:42PM +0000, Matthias Görgens wrote: then one need to spend months to reading big C++ books, and struggling with compilers errors, segfaults etc..^(1) (instead of doing assigned task!) or, what is more usually, trying Ad hoc methods for writing software. So people will learn DSL because: 1. DSL is simpler than general purpose language 2. DSL describe already known domain for user, (one probably don't need monads, continuations, virtual methods, template instantiation etc...etc...) so learning is easy, and didn't consume much time.
And if your DSL includes general purpose stuff, like functions, control structures, data structures, you'll re-invent the wheel. Probably porly. You didn't need to reinvent the wheel, because you DSL compiler can produce Haskell code: DSL -> General Purpose Language -> Executable And ever if you do, it saves allot of time of experts.
Roman.
(1) In Haskell this probably will sound like: reading allot of small tutorials and articles, grokking monads, struggling with type-check errors, infinite loops, laziness, etc...
There is other side. As Matthias Görgens mentioned earlier 1. One have to reinvent control structures. Multiple times. Lets assume that compiler would translate DSL to haskell code. But DSL's expressions which convert into haskell control structures are DSL's control structures. 2. There would be more than one DSL. If they are all EDSL there is no real problems with combining them in one program if necessity arises. Probably there would be ways to combine them if they are DSL but they will require expertise and most likely dirty hacks. 2.1 And all of them will have different conrol structures, abstraction mechanisms. 3. Turing tarpit. Users will constantly require more power and features in DSL. Most likely DSL designers wouldn't be great language designers so DSL will turn into utter mess. 4. One have all power (and libraries of host languages). Of course if he is able to utilize it. This is tradeoff between power and simplicity. If one have too much simplicity he is not able to solve difficult problems. If one have too much power at expense of simplicity he has to struggle with tool to have thing done. And it's possible to sacrifice simplicity and don't gain any power.