Comments on: Building Grammars (and Parsers) on the Fly http://blog.johanneslink.net/2009/08/09/building-grammars-and-parsers-on-the-fly/ Johannes Link's Travels through Software Devlopment Space Mon, 22 Mar 2010 08:38:12 +0000 hourly 1 http://wordpress.com/ By: Bernd Schiffer http://blog.johanneslink.net/2009/08/09/building-grammars-and-parsers-on-the-fly/#comment-202 Bernd Schiffer Thu, 13 Aug 2009 22:41:29 +0000 http://blog.johanneslink.net/?p=200#comment-202 I often hear the point you mentioned, that internal DSLs would restricts the syntax and that non-techs won't be able to handle them. I agree with that. So I came up with a mix of both. My example is not a DSL. "10 km" is not a internal Groovy DSL. But "10.km" (see the dot) is. All I have to do to convert the external "10 km"-DSL into an internal "10.km" one is to delete the dot. I've done that by a simple regular expression. So, my point is: Isn't it totally enough to build an internal DSL and to do some cosmetic surgery with simple tools like regular expressions? Do you really need extra tools for that? I'm eager to see your example. I've set an reminder on that to December 31th, 2009 :) I often hear the point you mentioned, that internal DSLs would restricts the syntax and that non-techs won’t be able to handle them.

I agree with that. So I came up with a mix of both. My example is not a DSL. “10 km” is not a internal Groovy DSL. But “10.km” (see the dot) is. All I have to do to convert the external “10 km”-DSL into an internal “10.km” one is to delete the dot. I’ve done that by a simple regular expression.

So, my point is: Isn’t it totally enough to build an internal DSL and to do some cosmetic surgery with simple tools like regular expressions? Do you really need extra tools for that?

I’m eager to see your example. I’ve set an reminder on that to December 31th, 2009 :)

]]> By: johanneslink http://blog.johanneslink.net/2009/08/09/building-grammars-and-parsers-on-the-fly/#comment-201 johanneslink Thu, 13 Aug 2009 19:02:36 +0000 http://blog.johanneslink.net/?p=200#comment-201 My example has been badly chosen as for the WHY of using an on-the-fly parser. Sometimes internal DSL restrict the syntax too much to be usable for non-tech analysts, testers or customers. Imagine you want to use (parts of) prose texts to be used as executable scenarios. Maybe I'll blog such an example later... this year ;-). My example has been badly chosen as for the WHY of using an on-the-fly parser. Sometimes internal DSL restrict the syntax too much to be usable for non-tech analysts, testers or customers. Imagine you want to use (parts of) prose texts to be used as executable scenarios. Maybe I’ll blog such an example later… this year ;-) .

]]> By: Bernd Schiffer http://blog.johanneslink.net/2009/08/09/building-grammars-and-parsers-on-the-fly/#comment-200 Bernd Schiffer Thu, 13 Aug 2009 18:56:29 +0000 http://blog.johanneslink.net/?p=200#comment-200 This parser might be powerful. However, it's hart for me to see why, for this purpose, an external DSL would be better than an internal one. The Cucumber example of yours is an internal DSL. You want "[s]light variations, like using “put in” instead of “entered into...”. But I can't see how you've done that with Pars4SJM. However, you solved another example with Parse4SJM: adding numbers. Well, even the Groovy Parse4SJM solution here is still much too heavy weight. That's because you chose an external DSL. An internal DSL would do much better here, e.g. a Groovy one. I think a internal Groovy DSL could deal with the adding numbers thing in one line of code, maybe two, but that'd be all. (Might want to have a look at this. Blog: http://berndschiffer.blogspot.com/2007/02/kilometerfresser.html Code: http://www.bytemycode.com/snippets/snippet/593/ Skip the GUI and the formatting parts and you'll end up with a one or two liner.) There could be limits in the use of an internal DSL here, but I don't see why you could not fix your main problem with an internal DSL, too. The benefit would be a light weight kind of tool: your programming language of choice. So, what power are you looking for in external DSLs that you could not find in an internal DSL? This parser might be powerful. However, it’s hart for me to see why, for this purpose, an external DSL would be better than an internal one.

The Cucumber example of yours is an internal DSL. You want “[s]light variations, like using “put in” instead of “entered into…”. But I can’t see how you’ve done that with Pars4SJM. However, you solved another example with Parse4SJM: adding numbers.

Well, even the Groovy Parse4SJM solution here is still much too heavy weight. That’s because you chose an external DSL. An internal DSL would do much better here, e.g. a Groovy one. I think a internal Groovy DSL could deal with the adding numbers thing in one line of code, maybe two, but that’d be all.

(Might want to have a look at this.
Blog: http://berndschiffer.blogspot.com/2007/02/kilometerfresser.html
Code: http://www.bytemycode.com/snippets/snippet/593/
Skip the GUI and the formatting parts and you’ll end up with a one or two liner.)

There could be limits in the use of an internal DSL here, but I don’t see why you could not fix your main problem with an internal DSL, too. The benefit would be a light weight kind of tool: your programming language of choice.

So, what power are you looking for in external DSLs that you could not find in an internal DSL?

]]>