RE: [Haskell-cafe] Language Workbenches - the Haskell solution?
Hi Yoel, This looks like fun. Just some general comments: - One should try to *also* provide a simple solution. Here I would pick a solution that doesn't need a lot of explanation (of Haskell and the solution) and a lot of defense to score with it. - As a second step, one should identify a sweet spot upfront. The sweet spot could indeed be to get some extra static typing; some extra DSL checks; some increased declarativeness. (Or all of it.) To this end, I would study the DSL problem at hand, and not so much yet think of Haskell encoding. You can only score with Haskell, if there is something to be scored with in the problem at hand. - Now one can explore the identified sweet spot by trying to put strong Haskell features such as hs-plugins or Data.Generics or Data.Dynamic or phantoms or all of them or something else to work. - I haven't looked at the discussion, but a sophisticated Java solution could also try to score with dynamic class loading, reflection, perhaps even with compile-time reflection a la OpenJava. One would need to be prepared to cope with that ;-) - XML wasn't mentioned in your message. I wonder whether they discuss it in the actual thread. (Yes, you might be saying XML is not the same language as you are programming in, but it so easy to process XML in many languages, and one uses XSD for the DSL syntax). In fact, in Haskell I would strongly consider using HaXML or similar technology for non-trivial configuration problems. XML makes configuration also more portable. In reality, I don't see much value in using the programming language syntax for representing the configuration information. This makes it only harder to process those configurations with other tools. Ralf
-----Original Message----- From: haskell-cafe-bounces@haskell.org [mailto:haskell-cafe- bounces@haskell.org] On Behalf Of Yoel Jacobsen Sent: Thursday, September 08, 2005 11:41 AM To: haskell-cafe@haskell.org Subject: [Haskell-cafe] Language Workbenches - the Haskell solution?
I'm trying to create an _elegant_ solution in Haskell. ... Further, what is the type of the parser?
On 12 sept. 05, at 00:50, Ralf Lammel wrote:
- XML wasn't mentioned in your message. I wonder whether they discuss it in the actual thread. (Yes, you might be saying XML is not the same
Yes, fowler mentionned XML: "XML has its uses, but isn't exactly easy to read. We could make it easier to see what's going on by using a custom syntax. Perhaps like this:" I dont think XML is a good idea for files that are managed/edited by humans. Of course the job of the programmer is easier when the file is coded in XML, but I think the user prefer simpler files with a custom syntax, and the user is the king. I am a programmer and personnaly I dont want to code my haskell code in XML, so I presume it is the same for the user with configuration files.
language as you are programming in, but it so easy to process XML in many languages, and one uses XSD for the DSL syntax). In fact, in Haskell I would strongly consider using HaXML or similar technology for non-trivial configuration problems. XML makes configuration also more portable. In reality, I don't see much value in using the programming language syntax for representing the configuration information. This makes it only harder to process those configurations with other tools.
Well except if your programming langage is lisp in which case parsing the configuration file is just a call to read.
Ralf
Ralf Lammel wrote:
XML... I wonder whether they discuss it...
yoann padioleau wrote:
Yes, fowler mentionned XML: "XML has its uses, but isn't exactly easy to read..." I dont think XML is a good idea for files that are managed/edited by humans.
It can be very human readable if set up properly. I once set up a configurations system like that for a large C++ app. The config files are very readable, and easy to edit using widely available free XML editors. For example, in the configuration file you have things like: <Age>25</Age> <Gender>F</Gender> <Location> <City>Cleveland</City> <State>Ohio</State> </Location> etc. With the source code, there is a master XML document that sets up the fields: <data name="Age" type="Int"/> <data name="Gender" type="enum"> <choice>F</choice> <choice>M</choice> </data> <category name="Location"> <data name="City" type="String"/>
Correction - I wrote:
If you want a GUI for configuration, you could, for example, write a fairly simple transformation of the master XML into a .NET dialog, or glade file for GTK, or whatever. We never did that, though.
Actually, Yael Weinbach wrote a beautiful GUI for this configuration scheme. I apologize to Yael for the omission. Regards, Yitz
participants (3)
-
Ralf Lammel -
Yitzchak Gale -
yoann padioleau