tag:blogger.com,1999:blog-22587889.post3129592502760208377..comments2024-02-11T13:21:47.930+05:30Comments on Ruminations of a Programmer: External DSLs made easy with Scala Parser CombinatorsAnonymoushttp://www.blogger.com/profile/01613713587074301135noreply@blogger.comBlogger16125tag:blogger.com,1999:blog-22587889.post-71036245776808667602010-06-08T09:09:00.834+05:302010-06-08T09:09:00.834+05:30Do you have a download with the source, sometimes ...Do you have a download with the source, sometimes it hard to read through the blog and cherry pick the code.Berlin Brown Discussionshttps://www.blogger.com/profile/14524539202704556506noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-3725580572048906772009-08-28T20:02:33.038+05:302009-08-28T20:02:33.038+05:30@Robert_Fischer: Yeah, there is support for positi...@Robert_Fischer: Yeah, there is support for position-tracking. You need to ensure that your output AST nodes (the output of the parser; the T in Parser[T]) incorporates the trait "scala.util.parsing.input.Positional".<br /><br />That (only) gives your parser output the CAPABILITY to store a line/column (via a member called 'pos'). In order to populate 'pos', there is a method in Parsers called 'positioned'.<br /><br />If you wrap your parse combinator in 'positioned', it will assign the 'pos' property for you.<br /><br />e.g., expr = positioned(term~rep('+'~term))<br /><br />The 'pos' variable can spit out a nice "your error is here" string, but doesn't include the filename, unfortunately. To include filename, you'd need to recreate a similar mechanism for yourself.Andrew Fhttp://dysphoria.netnoreply@blogger.comtag:blogger.com,1999:blog-22587889.post-19869877737059545402009-01-18T23:59:00.000+05:302009-01-18T23:59:00.000+05:30Is there any support for position tracking? Speci...Is there any support for position tracking? Specifically, I'd like to know that this particular token came from line 13, column 23 of file "fooBar.suffix".Robert Fischerhttps://www.blogger.com/profile/15576124960718643532noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-80689750728465495912008-04-25T10:04:00.000+05:302008-04-25T10:04:00.000+05:30This post has been picked up by Artima forum .. en...This post has been picked up by Artima forum .. enjoy the <A HREF="http://www.artima.com/forums/flat.jsp?forum=276&thread=229061" REL="nofollow">discussion</A> ..Anonymoushttps://www.blogger.com/profile/01613713587074301135noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-72729479748473621182008-04-24T14:17:00.000+05:302008-04-24T14:17:00.000+05:30This comment has been removed by the author.tawekhttps://www.blogger.com/profile/09338082072981742469noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-9370413410828560912008-04-21T05:08:00.000+05:302008-04-21T05:08:00.000+05:30Is it possible to refactor out all the repeated ma...Is it possible to refactor out all the repeated magic strings?Antony Stubbshttps://www.blogger.com/profile/11776027112330595831noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-58233786786313949962008-04-19T01:42:00.000+05:302008-04-19T01:42:00.000+05:30@anonymous:I agree completely. You make a good poi...@anonymous:<BR/><BR/>I agree completely. You make a good point. I was assuming that the people writing in the DSL are the domain experts. It's probably often useful enough as a tool for programmers to be able to write in the DSL and have the domain experts be able to read/understand/verify the content.<BR/><BR/>I'm still curious about the ability to provide domain specific error messages using this technique. No matter who is actually writing in the language, it would make sense to have any error messages speak the same high level language.Brian Reillyhttps://www.blogger.com/profile/07056473468154339200noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-10955878537670886532008-04-18T21:31:00.000+05:302008-04-18T21:31:00.000+05:30@Brian:There is no requirement anywhere that says ...@Brian:<BR/><BR/>There is no requirement anywhere that says that a DSL has to look like written English. There's also no requirement that says a DSL must be so simple that a non-techie can write it (although they should probably be able to read it). If there's some syntax in there, that's ok. The important thing is that it looks natural for the domain in question and the language it's coded in. Also, Groovy and Ruby are not restricted to just using fluent interfaces (although they don't allow you to be quite as free-form as Scala either).<BR/><BR/>Some people have gone as far as to say that DSLs are really just about writing readable code. I would say it's taking that idea and putting it on steroids.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-22587889.post-86205856763606831772008-04-18T20:17:00.000+05:302008-04-18T20:17:00.000+05:30One thought that I've been having about DSLs is th...One thought that I've been having about DSLs is that users will make errors when writing in the language. I think that having domain specific error messages is an important part of a DSL.<BR/><BR/>I hear people talking about writing DSLs on top of Groovy or Ruby and wonder if that really works. If someone makes an error, the feedback will make sense to someone who knows Groovy/Ruby, but maybe not to someone who is only trained in the DSL. Still, I think people use Groovy/Ruby because it's easier than creating their own parser. What you end up with seems more like a fluent interface than a DSL to me, since the actual language is still Groovy or Ruby.<BR/><BR/>It looks like using Scala the way you describe makes it as easy to create a true DSL as it would be to create a fluent interface in Groovy/Ruby. Would this technique also also allow you to report domain specific error messages so that users don't have to worry that it's actually implemented with Scala? Or do you think that the work necessary to provide domain specific error messages is roughly the same no matter how the DSL is implemented?Brian Reillyhttps://www.blogger.com/profile/07056473468154339200noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-18101536272305910852008-04-16T07:47:00.000+05:302008-04-16T07:47:00.000+05:30Anonymous - as an exercise take the parser defined...Anonymous - as an exercise take the parser defined here and replace all the "operators" with words. You might rethink your position on operator overloading when you see the results.James Iryhttps://www.blogger.com/profile/02835376424060382389noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-20843337585749021242008-04-15T04:33:00.000+05:302008-04-15T04:33:00.000+05:30Ah, i generally dislike scala, since it seems to m...Ah, i generally dislike scala, since it seems to me that they are falling into the trap of being too powerful (like C++) with conflicting and incompatible worldviews in the same code base, but then i come across something sexy like the Parser Combinators library.<BR/><BR/>Still can't stand operator overloading.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-22587889.post-11858970203805692382008-04-14T21:32:00.000+05:302008-04-14T21:32:00.000+05:30very interesting indeedby the way: you mention tha...very interesting indeed<BR/><BR/>by the way: you mention that Scala parsers are implemented as monads, but the combinators you use do not need the full power of monads. Parsers can be implemented as applicative functors (or, equivalently, monoidal functors). They are more general than monads [ and, as a consequence, cover more practical cases (e.g. error correcting parsers) ]<BR/><BR/>by the way the combinators in the wiki you refer to (I, K and S) are also applicative<BR/><BR/>I enjoyed every bit of this post<BR/><BR/>LucLuc Duponcheelhttps://www.blogger.com/profile/09285501928970939466noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-44620828236100440142008-04-14T18:50:00.000+05:302008-04-14T18:50:00.000+05:30@German: Yes, it can be improved that way. Actuall...<I>@German:</I> <BR/>Yes, it can be improved that way. Actually I had taken this example from a much larger DSL and shortened it for brevity. In the original DSL, I had to deal with shares(equities) and fixed incomes (fi) and other types of securities. Hence I could not treat that part as don't care. But in this context, it makes perfect sense to do what u suggested. Thanks.Anonymoushttps://www.blogger.com/profile/01613713587074301135noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-72405659473480987582008-04-14T18:44:00.000+05:302008-04-14T18:44:00.000+05:30For this:numericLit ~ ident ~ "shares" ^^ { case n...For this:<BR/><BR/>numericLit ~ ident ~ "shares" ^^ { case n ~ a ~ "shares" => (n.toInt, a) }<BR/><BR/>I think it could be improved like this (though I haven't tested it):<BR/><BR/>numericLit ~ ident ~ "shares" ^^ { case n ~ a ~ _ => (n.toInt, a) }<BR/><BR/>...to avoid repeating a literal which can't be any other thing, or even:<BR/><BR/>(numericLit ~ ident) <~ "shares" ^^ { case n ~ a => (n.toInt, a) }<BR/><BR/>...to forget about it once you know you have the right construct. <BR/>I've been playing around with this stuff and it's really cool.Germánhttps://www.blogger.com/profile/07765922715981210093noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-43269851893658908292008-04-14T18:36:00.000+05:302008-04-14T18:36:00.000+05:30oops! sure it is "match" .. Fixed it ..oops! sure it is "match" .. Fixed it ..Anonymoushttps://www.blogger.com/profile/01613713587074301135noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-48283387831649462112008-04-14T18:31:00.000+05:302008-04-14T18:31:00.000+05:30Isn't the do in the last code snippet supposed to ...Isn't the <B>do</B> in the last code snippet supposed to be a <B>match</B>, or I missed something in the Scala language?<BR/>Anyway, excellent post, expecting more great stuff from this blog. <BR/><BR/>And, not really related with the post, I still like the Haskell parser combinators a bit more, they seem to me a just a bit more 'elegant' :-).SaskoMhttps://www.blogger.com/profile/17285432385743575017noreply@blogger.com