Hi,

I've a problem. I have "M" model with Integer field.
I've written DSL for this model and I want parse DSLinput to "M" language for compilation and deploying to repository.
Because MGrammar output contains numbers with inverted commas, I can't compile it.

Look at simple examples:

When I write fixed number in projection, I get number without inverted commas in output:

Input:1+2

DSL:module Expression {
language Expression {
token Digits = ("0".."9")+;
syntax Main
= e:E => e;
syntax E
= d:Digits => d
| l:E "+" r:E => Add[1,2] ;
}
}

Output:Add[ 1, 2]


But when I use projection with number parameters:

Input:1+2

DSL:module Expression {
language Expression {
token Digits = ("0".."9")+;
syntax Main
= e:E => e;
syntax E
= d:Digits => d
| l:E "+" r:E => Add[l,r] ;
}
}

Output: Add[ "1", "2"]

I get output with inverted commas :(


Do you knowhow can I make projections with numbers without inverted commas?

Marcin,

Unfortunately, we don't yet have the capability to translate text on the right hand side of a production. So given a string "1", there isn't any way directly in the language to translate it to the number 1. This is something we're working on for a future CTP, but it just isn't available yet. As a workaround, you'd have to create your own graph builder and supply that to the parser and do the translation in the graph builder.

Paul

---

Paul Vick MSFT

+1 for Paul´s comment.

What your grammar is producing as "number" is the "token Digit" production.

This is a documented issue. If you take a look into "MGrammar Language Specification" document, that comes with our CTP (under /Documents/), you will find at section 4.3.2. the following:

(5) Token rules do not permit a constructor to be specified and output text values.

Converting this token value to an integer is a step that you'd need to do when you consume your graph output, as Paul mentioned.

Happy coding,
M.

Marcin--just wanted to let you know that I'm working on getting an answer for you from the development team. Hopefully I'll have something for you soon.

.Kraig

Marcin,

Unfortunately, we don't yet have the capability to translate text on the right hand side of a production. So given a string "1", there isn't any way directly in the language to translate it to the number 1. This is something we're working on for a future CTP, but it just isn't available yet. As a workaround, you'd have to create your own graph builder and supply that to the parser and do the translation in the graph builder.

Paul

---

Paul Vick MSFT

+1 for Paul´s comment.

What your grammar is producing as "number" is the "token Digit" production.

This is a documented issue. If you take a look into "MGrammar Language Specification" document, that comes with our CTP (under /Documents/), you will find at section 4.3.2. the following:

(5) Token rules do not permit a constructor to be specified and output text values.

Converting this token value to an integer is a step that you'd need to do when you consume your graph output, as Paul mentioned.

Happy coding,
M.

Any word on a good solution to this?

---

The Silverlight Tour is Coming to: Boston, MA - April 29-May 1, 2009 Washington, DC - June 16-18, 2009 http://silverlight-tour.com http://wildermuth.com http://agilitrain.com

I believe the following post should have a solution for you:
Top Six Common MGrammar Integration Errors
Specifically, Common Error #1: Getting Non-Text Output from MGrammar. Note that there's also a code download at the very bottom of the post with a sample C# project.

Let me know if this helps.

David

I appreciate the advice, but I'd love to know the future on this. It seems as though the idea of the output of a DSL needing to be text only is a severe limitation. I am of the opinion if most use of MGrammar is going to involve writing a parser, then the use of DSLs is going to be pretty limited. I'd like to see one of two solutions:

---

The Silverlight Tour is Coming to: Boston, MA - April 29-May 1, 2009 Washington, DC - June 16-18, 2009 http://silverlight-tour.com http://wildermuth.com http://agilitrain.com

Here's a tongue-in-cheek answer... (kindof). I figure if the Original Poster is already going to be walking the syntax tree as the output of this parse of an expression language, he's going to have to do some arithmetic at some point anyway... ;)

module Expression {
language Expression {
syntax WholeNum
= DigitNum
| tens:WholeNum
ones:DigitNum
=> Add[ Mult[10, tens], ones]
;
token DigitNum
= "0" => 0
| "1" => 1
| "2" => 2
| "3" => 3
| "4" => 4
| "5" => 5
| "6" => 6
| "7" => 7
| "8" => 8
| "9" => 9
;
syntax Main
= e:E => e;
syntax E
= d:WholeNum => d
| l:E "+" r:E => Add[l,r] ;
}
}

input: 12+345

output: Add[
Add[
Mult[
10,
WholeNum[
1
]
],
2
],
Add[
Mult[
10,
Add[
Mult[
10,
WholeNum[
3
]
],
4
]
],
5
]
]

---

'blog: http://diakopter.blogspot.com/ JSMeta: http://jsmeta.org/

The project I posted is definitely a work-around. We definitely want this scenario to be much easier.

From http://social.msdn.microsoft.com/Forums/en-US/oslo/thread/45cef89b-2bc5-4889-901d-f161a93257b0:
“Our goal is to remove the distinctions between the function bodies in today’s MSchema and the right-hand-sides of grammar rules in today’s MGrammar. This includes a consistent set of operators and functions for use in both contexts as well as the ability to type-ascribe (a la today’s MSchema) the results. The corresponding design and implementation work is ongoing.�br/>
I believe that's close to (or the same as) your first solution, if I'm understanding you correctly.

David