<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Formal Language Processing in Scala, Part 4</title>
	<atom:link href="http://szeiger.de/blog/2008/09/20/formal-language-processing-in-scala-part-4/feed/" rel="self" type="application/rss+xml" />
	<link>http://szeiger.de/blog/2008/09/20/formal-language-processing-in-scala-part-4/</link>
	<description>Stefan Zeiger's Software Development Weblog</description>
	<lastBuildDate>Wed, 17 Mar 2010 13:24:26 +0100</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.4</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Todd Cook</title>
		<link>http://szeiger.de/blog/2008/09/20/formal-language-processing-in-scala-part-4/comment-page-1/#comment-45</link>
		<dc:creator>Todd Cook</dc:creator>
		<pubDate>Fri, 12 Jun 2009 19:27:34 +0000</pubDate>
		<guid isPermaLink="false">http://szeiger.de/?p=22#comment-45</guid>
		<description>Your articles are excellent and well paced. You&#039;ve taken a difficult topic and explained the many twists and turns admirably.

JavaCC will probably still have it&#039;s place, but Scala allows for a lightweight approach that probably be good enough for many applications. Thank you for contributing some real world usages of Scala&#039;s advanced libraries.</description>
		<content:encoded><![CDATA[<p>Your articles are excellent and well paced. You&#8217;ve taken a difficult topic and explained the many twists and turns admirably.</p>
<p>JavaCC will probably still have it&#8217;s place, but Scala allows for a lightweight approach that probably be good enough for many applications. Thank you for contributing some real world usages of Scala&#8217;s advanced libraries.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Stefan Zeiger</title>
		<link>http://szeiger.de/blog/2008/09/20/formal-language-processing-in-scala-part-4/comment-page-1/#comment-29</link>
		<dc:creator>Stefan Zeiger</dc:creator>
		<pubDate>Mon, 20 Oct 2008 10:53:07 +0000</pubDate>
		<guid isPermaLink="false">http://szeiger.de/?p=22#comment-29</guid>
		<description>Joakim, thanks for the encouragement. If you&#039;re using Eclipse, have a look at the JavaCC plugin which provides an editor with syntax-highlighting and a builder for JavaCC and JJTree sources. I&#039;m using it on a big project with a JavaCC/JJTree parser and it works really well.

I have to admit that I haven&#039;t done any performance tests with Scala parser combinators or parser generators yet. So far, parsers have always been &quot;fast enough&quot; for my needs. This is probably true for most programming language parsers (where the performance or the interpreter or the quality of the optimizer and code generator will be much more important) but there are certainly cases where parser performance would be very important (e.g. IP header parsing).</description>
		<content:encoded><![CDATA[<p>Joakim, thanks for the encouragement. If you&#8217;re using Eclipse, have a look at the JavaCC plugin which provides an editor with syntax-highlighting and a builder for JavaCC and JJTree sources. I&#8217;m using it on a big project with a JavaCC/JJTree parser and it works really well.</p>
<p>I have to admit that I haven&#8217;t done any performance tests with Scala parser combinators or parser generators yet. So far, parsers have always been &#8220;fast enough&#8221; for my needs. This is probably true for most programming language parsers (where the performance or the interpreter or the quality of the optimizer and code generator will be much more important) but there are certainly cases where parser performance would be very important (e.g. IP header parsing).</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Joakim Ohlrogge</title>
		<link>http://szeiger.de/blog/2008/09/20/formal-language-processing-in-scala-part-4/comment-page-1/#comment-28</link>
		<dc:creator>Joakim Ohlrogge</dc:creator>
		<pubDate>Thu, 16 Oct 2008 18:03:59 +0000</pubDate>
		<guid isPermaLink="false">http://szeiger.de/?p=22#comment-28</guid>
		<description>I just wanted to let you know that I am following your series with great interest. I really like how you go to the bottom of explaining the technique behind the fansy DSL and I find that your series drives me to pick up new tricks in scala that is a very new language for me.

I have toyed with parsers in JavaCC before and it is fascinating how readable the scala DSL becomes. I am really looking forward to see how parser combinators can go beyond EBNF. It also seems very convenient that everything is scala. JavaCC is always a little tedious when it comes to organizing your builds etc. Do you have any input on the performance of the parsers created with Scala? How do they compare to JavaCC ones in that area?

Keep up the good work!</description>
		<content:encoded><![CDATA[<p>I just wanted to let you know that I am following your series with great interest. I really like how you go to the bottom of explaining the technique behind the fansy DSL and I find that your series drives me to pick up new tricks in scala that is a very new language for me.</p>
<p>I have toyed with parsers in JavaCC before and it is fascinating how readable the scala DSL becomes. I am really looking forward to see how parser combinators can go beyond EBNF. It also seems very convenient that everything is scala. JavaCC is always a little tedious when it comes to organizing your builds etc. Do you have any input on the performance of the parsers created with Scala? How do they compare to JavaCC ones in that area?</p>
<p>Keep up the good work!</p>
]]></content:encoded>
	</item>
</channel>
</rss>
