views:

64

answers:

2

I have never written a DSL, but I am considering it as a feature for a new project (hypothetical). It would be for end users to be able to express in natural language concepts such as weekdays between 10 and 11 except on the first monday of the month.

Dutch users might write weekdagen tussen 10 en 11 behalve op de eerste maandag van de maand. In this case the position of the words seems to match, but there may be expressions where the position of verbs/nouns etc. could be different between languages.

I realise the obvious answer (it depends). I am a .NET developer and I consider using Boo but I'm open to suggestions. I need to understand wether each translation requires rewriting a part of the implementation (which part) or if there is a way to do actual translations, maybe in some sort of preprocessor.

Thanks!

+2  A: 

Your not going to find a translator that is capable of doing this for more than a few languages (say between one or two languages and English), especially considering English which itself could have at least 3 ways to write it.

If you want to write a DSL, you need to come up with the production rules first (what can you write) and then work it into a way to express it in english/dutch/martian/etc.

For instance: Schedule := Frame Inclusion [Exception]

which would be:

  • Frame: Month, Year, Week, WeekDays, WeekEnds, Days of the Month, Holidays, etc
  • Inclusion: Between, Not In, Around, Containing, etc
  • Exception: Except [Schedule], But Not [Schedule], Unless [Schedule]

You can then worry about a lexer/parser which corrects a specific grammar and puts it into that form of productions.

These are off the top of my head and not even close, but should be enough to get started.

GrayWizardx
Ok, so the lexer would be the language specific part of the implementation (together with the rules).
michielvoo
@Michielvoo, actually the "parser". the lexer would be what provided the lexical analysis of the parsed tokens. You can think of it kind of like IL and C#/VB C# and VB provide parsers that convert their respective languages into a language that can be interpreted (IL). Its not a perfect example (obviously there is much more to it than that) but it illustrates that you write the lexer to process your rules into your final constructions (program), and then can layer parsers on top of it for your specific grammar dialects. Traditionally we write the parser and lexer together, but its not required
GrayWizardx
@GrayWizardx: this is something that a graphical DSL avoids. One designs the domain model, which I suppose implies the grammar to an extent. The difference is that an instance of the domain model is created graphically, not textually, so the structure of the DSL does not depend on text that needs translation.
John Saunders
@John Saunders, in this case I am not sure it would help much as @michielvoo is trying to actually have a single underlying domain that is context sensitive to the language semantics of the writer. This is different from a formal grammar which does not change from the point of view of the writer, the same productions are used. My understanding of his request for more than one rule to reduce to the same production, similar to being able to write **private int foo(int, int)** as **secret foo taking int, int and returning int**. There are some overlaps in each grammar, but not completely
GrayWizardx
We can map secret to private, and maybe figure out that "taking" replaces (int, int) and returning is the type, but the extra language words (and, etc) will be confusing and very specific to a single implementation. It is of course doable on some level.
GrayWizardx
@GrayWizardx: If he has decided on a textual DSL and I didn't notice, then I apologize for my answer. Obviously if the requirement is to process text, then a graphical DSL won't help.
John Saunders
@John Saunders, no need for apologies. :) Is all good.
GrayWizardx
+1  A: 

A DSL created with the Domain-Specific Language Tools can be localized. They place all strings into .resx files.

John Saunders
Why the downvote. You've decided that DSLs created with that toolkit are not DSLs? The OP hasn't started his project yet, specified .NET, and hasn't yet chosen a DSL platform.
John Saunders
Graphic DSLs are something I have been checking out, thanks for mentioning them.
GrayWizardx