Yoann, Thanks for your comments. Yoann wrote: I don't think XML is a good idea for files that are managed/edited by humans. I think the users prefer simpler files with a custom syntax, and the user is the king. I don't mind, but when you say "user" do you mean "application configuration admin" or "plain application user". The former may know/like/dislike PL syntax, the latter may not like *anything* but very simple and foolproof formats or GUI-based configuration. There is no reason to believe that the latter wants to feel like programming in Haskell, Java, ... at least not in the universe I live in or that I observe. Yoann wrote: Of course the job of the programmer is easier when the file is coded in XML, ... This is unrelated to what I said. Perhaps my wording wasn't clear enough. I was trying to refer to the software life cycle and tool support as a whole. Doing software re-engineering for configurations that are formulated in a Turing-complete language is no fun. This is quite similar to the known issues with macros, when used for configuration; you may want to read about software asbestos here: http://homepages.cwi.nl/~ralf/am/ Yoann wrote: I am a programmer and personally I don't want to code my Haskell code in XML I didn't propose *that*. Anyway, picking up the new subject that you introduced accidentally, let me reply: you are not alone: most programmers don't like to code their PL code in XML. (As an aside, XML is used even for coding these days, just in case you don't know: check out some widely used AOP language extensions for Java. I am not saying whether I like this or not.) Yoann wrote: so I presume it is the same for the user with configuration files. So you presume that a user of application XYZ prefers to configure his/her application in the syntax of the underlying implementation language, supposing there is just one? That's a very interesting presumption. Have you any data to substantiate your presumption, or is that a prediction for the future? Yoann wrote: if your programming langage is lisp in which case parsing the configuration file is just a call to read. Sure! Sounds a bit like comparing apples and oranges. I can also parse my configuration file to "Data.Tree String" in Haskell, or something similarly weakly typed. Then parsing is just a call to read, too. (Lisp really doesn't score here.) So what's the point? I guess we won't be happy with that Haskell solution, or at least we would like to see whether we can score with Haskell in some way. Ralf