This page is no longer maintained — Please continue to the home page at www.scala-lang.org

The decision why to use Scala for implementing a DSL for the Portfolio Manager

5 replies
Abdul Sami Siddiqui
Joined: 2011-07-05,
User offline. Last seen 42 years 45 weeks ago.
Hello,
I am pursuing to develop a DSL for the portfolio manager to ease him in his asset management stuff. I want to know what should I choose for its implementation? ANTLR or Scala parser combinator? 
What are the pros and cons of using a parser generater vs a language having parser combinators?
Thanks,Sam.
ichoran
Joined: 2009-08-14,
User offline. Last seen 2 years 3 weeks ago.
Re: The decision why to use Scala for implementing a DSL for th
Parser generators are higher-performance and lower memory usage.

Parser combinators are easier to use (in my hands) and to integrate with data structure manipulation.

Depending on the exact parser combinator and parser generator, one or the other may allow more powerful grammars.  In particular, parser combinators tend to make it easy to switch contexts (often hard with generators), while generators can sometimes tolerate and resolve ambiguities and recursion in ways that parser combinators may not.  (I have a particular example in mind where I could express something in YACC with warnings (but which was resolved the way I intended) which I never could get working with the packrat parser.)

Bottom line: I use parser generators only when the parsing is either a performance bottleneck (thousands or millions of lines), or when I cannot manage to get a parser combinator to handle the syntax I'm attempting (generally involving strange recursion).

  --Rex

On Tue, Jul 5, 2011 at 9:22 AM, Abdul Sami Siddiqui <abdulsami2 [at] gmail [dot] com> wrote:
Hello,
I am pursuing to develop a DSL for the portfolio manager to ease him in his asset management stuff. I want to know what should I choose for its implementation? ANTLR or Scala parser combinator? 
What are the pros and cons of using a parser generater vs a language having parser combinators?
Thanks,Sam.

phlegmaticprogrammer
Joined: 2010-07-23,
User offline. Last seen 2 years 15 weeks ago.
Re: The decision why to use Scala for implementing a DSL for th
If you are going for a quick solution, use by all means Parser Combinators.
On the other hand, ANTLR is a great tool if you have a couple of days to get familiar with it. Unlike YACC, it is a top down parser, not bottom up, so you usually resolve ambiguities by syntactic predicates. You also have to rewrite your left recursive rules to use regular expression syntax, instead. 
ANTLR has the following advantages:- ANTLRWorks, a great environment for editing and checking ANTLR Grammars- Lexer and Parser can be specified in one grammar file- superior error reporting: the resulting parser does not stop because of the first error in the input but is self-correcting and can report several errors simultaneously in your input- a nice notation to generate syntax trees in your rule actions
For an example, you can check out my programming language Babel-17, here is the grammar:
https://github.com/phlegmaticprogrammer/Babel-17/blob/master/Babel17_ANTLR_Parser/babel17.g
and here is the parser code (look for methods "parse") that uses the lexer and parser generated from the grammar:
https://github.com/phlegmaticprogrammer/Babel-17/blob/master/Babel17_Interpreter/src/com/babel17/interpreter/parser/Parser.java
- Steven Obua
On 05.07.2011, at 16:08, Rex Kerr wrote:
Parser generators are higher-performance and lower memory usage.

Parser combinators are easier to use (in my hands) and to integrate with data structure manipulation.

Depending on the exact parser combinator and parser generator, one or the other may allow more powerful grammars.  In particular, parser combinators tend to make it easy to switch contexts (often hard with generators), while generators can sometimes tolerate and resolve ambiguities and recursion in ways that parser combinators may not.  (I have a particular example in mind where I could express something in YACC with warnings (but which was resolved the way I intended) which I never could get working with the packrat parser.)

Bottom line: I use parser generators only when the parsing is either a performance bottleneck (thousands or millions of lines), or when I cannot manage to get a parser combinator to handle the syntax I'm attempting (generally involving strange recursion).

  --Rex

On Tue, Jul 5, 2011 at 9:22 AM, Abdul Sami Siddiqui <abdulsami2 [at] gmail [dot] com> wrote:
Hello,
I am pursuing to develop a DSL for the portfolio manager to ease him in his asset management stuff. I want to know what should I choose for its implementation? ANTLR or Scala parser combinator? 
What are the pros and cons of using a parser generater vs a language having parser combinators?
Thanks,Sam.


Razvan Cojocaru 3
Joined: 2010-07-28,
User offline. Last seen 42 years 45 weeks ago.
RE: The decision why to use Scala for implementing a DSL for th

If you’re after an external DSL, you could certainly look at XText – it’s an Eclipse based Java/DSL framework. It really is good! And when one says Java on this forum he or she implies scala J

 

The other way around, you should think at an internal DSL. I would not use Parser Combinators for human interaction… reason being lack of content assist, “compile time errors” and other such functions that help humans deal with coding…

 

XText gives you all that and more (UML modelling integration etc). An internal scala DSL allows you to reuse all the Scala editing capabilities of tools like Eclipse or embedded scripsters like the one running http://tryscala.org or even the embedded interpreter or SBT or the Emacs thing…

 

Cheers,

Razie

 

From: scala-debate [at] googlegroups [dot] com [mailto:scala-debate [at] googlegroups [dot] com] On Behalf Of Abdul Sami Siddiqui
Sent: July-05-11 9:22 AM
To: scala-debate [at] googlegroups [dot] com
Subject: [scala-debate] The decision why to use Scala for implementing a DSL for the Portfolio Manager

 

Hello,

 

I am pursuing to develop a DSL for the portfolio manager to ease him in his asset management stuff. I want to know what should I choose for its implementation? ANTLR or Scala parser combinator? 

 

What are the pros and cons of using a parser generater vs a language having parser combinators?

 

Thanks,

Sam.

Danielk
Joined: 2009-06-08,
User offline. Last seen 3 years 21 weeks ago.
Re: The decision why to use Scala for implementing a DSL for th
In addition to the previous suggestions, you can also check out parboiled - https://github.com/sirthias/parboiled/wiki

Cheers,
Daniel

On Tue, Jul 5, 2011 at 3:22 PM, Abdul Sami Siddiqui <abdulsami2 [at] gmail [dot] com> wrote:
Hello,
I am pursuing to develop a DSL for the portfolio manager to ease him in his asset management stuff. I want to know what should I choose for its implementation? ANTLR or Scala parser combinator? 
What are the pros and cons of using a parser generater vs a language having parser combinators?
Thanks,Sam.

Meredith Gregory
Joined: 2008-12-17,
User offline. Last seen 42 years 45 weeks ago.
Re: The decision why to use Scala for implementing a DSL for th
Dear Abdul,
i heartily recommend using an internal DSL. My recommendation comes from the fact is that with an internal DSL you can use the rest of Scala; i.e., you don't have to provide syntax (and ultimately semantics) for arithmetic, access to foreign libraries, etc. Almost all external DSL's grow up to be a Turing complete language with a bias towards the domain they are supporting. Such an offering requires 2 person years. Full stop. Scheduling less time or resources is fantasy, imho.
That said, you can get a lot of support from judicious use of tools -- ranging from XText to BNFC (my favorite). A rough and ready slogan to keep in mind:
  • Non-terminals : Types :: Terminals : Values
Keeping this alignment will make for a smoother path. Design syntax as if the non-terminals in the grammar were a type level representation of your domain; and the terminals were the simplest representation of concrete values. This will simplify the number of moving parts in your stack. Otherwise, you have to maintain the standard pipeline
  • Syntactic representation
  • Semantic representation
  • Compiler from one to the other
  • Executive operations on the Semantic representation
If the syntax is organized so that the abstract syntax is the semantic representation, then parsing is effectively your compiler. Likewise type-checking semantic operations is in alignment with parsing.[1] This optimization makes a great deal of sense in a functional language where the semantic representation is likely to be isomorphic to the abstract syntax, anyway (if for no other reason than simplifying reasoning about correctness).
Best wishes,
--greg
[1] An unspoken bit of folklore: type-checking and parsing are effectively the same operation. In type-checking you are asking whether this expression inhabits some type. In parsing you are asking whether this expression inhabits some non-terminal of the grammar. In a functional language -- where what constitutes a symbolic expression can be very, very abstract -- the line between these is so blurry as to be nigh on invisible.

On Tue, Jul 5, 2011 at 3:45 PM, Daniel Kristensen <daniel [dot] kristensen [at] gmail [dot] com> wrote:
In addition to the previous suggestions, you can also check out parboiled - https://github.com/sirthias/parboiled/wiki

Cheers,
Daniel

On Tue, Jul 5, 2011 at 3:22 PM, Abdul Sami Siddiqui <abdulsami2 [at] gmail [dot] com> wrote:
Hello,
I am pursuing to develop a DSL for the portfolio manager to ease him in his asset management stuff. I want to know what should I choose for its implementation? ANTLR or Scala parser combinator? 
What are the pros and cons of using a parser generater vs a language having parser combinators?
Thanks,Sam.




--
L.G. Meredith
Managing Partner
Biosimilarity LLC
7329 39th Ave SWSeattle, WA 98136

+1 206.650.3740

http://biosimilarity.blogspot.com

Copyright © 2012 École Polytechnique Fédérale de Lausanne (EPFL), Lausanne, Switzerland