Comments on: Parsing Text with Scala

By: Jan Vermeir

Jan Vermeir — Wed, 12 May 2010 07:17:41 +0000

Hi Gaurav, I didn’t make any further progress. This is mainly because I do my shopping at Albert Heijn, the largest retailer in the Netherlands (www.ah.nl). They are quite ambitious and plan to offer an Iphone app that allows you to navigate through the store based on a shopping list you can create on their website. This may actually lead to me buying one of those iphone thingies.
On the other hand, what is to stop us from doing a similar thing? The shopping list business case has enabled me to learn new stuff in the past. Would you like to work on the Scala code? Should we create an open source project and a backlog and stuff?

By: Gaurav

Gaurav — Tue, 11 May 2010 09:01:45 +0000

Hi Jan,

I’m trying to tackle the same problem(parse text and turn it into a list of groceries). Only I’m using Python instead of Scala.
I was wondering if you made any progress on this code.

By: Patrick

Patrick — Fri, 23 Oct 2009 18:58:49 +0000

Great! Thanks for posting the code.

By: Jan Vermeir

Jan Vermeir — Fri, 23 Oct 2009 18:13:08 +0000

Hi Patrick, you can download the sources here:

http://blog.xebia.com/wp-content/uploads/2009/10/dsl.zip

By: Patrick

Patrick — Fri, 23 Oct 2009 15:06:44 +0000

This was a nice read–would you care to post the complete sample code somewhere so I can see the whole thing? Would like to have a complete parser combinator example (that’s not another basic-arithmetic-expression-language) to look at. Thanks!

By: Jan Vermeir

Jan Vermeir — Fri, 23 Oct 2009 06:18:29 +0000

Thanks Jesper, I didn’t know expressions could be abbreviated like that. Your shorter version does eliminate a lot of redundancy (so in a way I could have thought of that myself, of course given Scala’s focus on conciseness).
Case classes have me a bit a confused still, but I’ll try out your suggestion.

@Andrew: the only version that ever worked for me is this Scala version. I lost the Drools code and I wrote it like ages ago so I don’t remember the details. It did work in a limited way however.
Needless to say the 6510 assembly language version failed miserably. What did work though was writing an addition to Commodore64 Basic. It worked by extending a symbol table in the Basic interpreter. This allowed me to add custom statements to a program, much like an internal DSL.
Another version that sort of worked was the Groovy one. I used the MethodMIssing thingy to add new methods to
existing classes. This allowed me to chain together arbitrary words and handle their meaning in a method. This wasn’t very elegant but it was fast and easy to develop. It would allow you to easily implement a internal DSL like the one Camel uses to configure routes. I guess you could do something similar in Scala, but I haven’t tried.

By: Jesper Nordenberg

Jesper Nordenberg — Thu, 22 Oct 2009 11:25:13 +0000

Whenever you define an immutable data type, like your Amount type, you should consider making it a case class. That way you will get benefits like equals, hashCode, toString (which you of course can override) and pattern matching for free.

Also, expressions like:

“name” ~ ident ^^ { case “name” ~ name => name }

can be more concisely written:

“name” ~> ident

By: Andrew Phillips

Andrew Phillips — Thu, 22 Oct 2009 08:34:09 +0000

I shouldn’t have read this nice post in the morning – now I’m hungry A small point: if I’m not mistaken the mkString methods are defined on the Iterable trait, so you can’t call them on everything. See the Iterable documentation.

I’d also be curious to hear how Scala shapes up in comparison to the other languages you’ve tried this in. You know, advantages, pains-in-the-a**, that kind of thing…