End of line comments at end of input in sable 3.*

[Adam Black]

Placing "//" at the end of input results in the error " expecting: EOF" 

This is due to the sable grammar assuming all short comments end in a new line. This assumption fails at the end of the file.

In sablecc-3x.sablecc3:

• Currently: short_comment = '//' not_cr_lf* eol;
• Solutions: 
• short_comment = '//' not_cr_lf* eol?;

This appears to be fixed in sable 4 beta 4

[Pomeroy, Roger C]

I have been using Sable 3.x for several years and absolutely love it!  We have been able to build a very complicated language in an amazingly short time!

 

I now would like to something different, and am not sure if it can be done....

 

We have a need to build a translator from one “language” to several others.  We have some testing processes written in a (simple) generic language similar to a “pseudo code”, and I want to build a translator that will interpret that “pseudo language” and then output the result in several different languages (python, Java, MATLAB, etc...)

 

Building the interpreter for the pseudo code I think I can do fairly easily.   What I need some ideas on is how to write the translator so that I can add/remove target languages without modifying the translator/interpreter code.   I feel like I should be able to do something like what is done with SableCC in that it generates the parser in an “macro” form and you can output the parser in java, c, whatever by using different macro text files that define the output form.   But in this case I don’t want the parser in several languages, rather I want that macro approach for the translator output. 

 

I’m just wondering if I am way off base in thinking that this should be pretty simple ... but I’m not sure how exactly to hook it all up.  I would prefer to have a solution that can be used in the SableCC 3.x environment (just because all of my other tools are still on that), but if 4.x is a better choice, I’m willing to use it  (my understanding so far is that 4.x is not quite “ready for prime time” but some parts of it may be??)

 

Thanks

 

Roger

[Michael Mast]

You could use SableCC to translate your "pseudo code" into XML and then use XSL to translate the XML into any number of target languages.

[Gonzalo Ortiz Jaureguizar]

I work with model to model transformations. I think the best idea is to define a independient model (java classes) which represents your pseudo language and then define transformatios to each "platform dependient" language (java, matlab, etc). The independient model can be done by hand or you can reuse SableCC AST. In my experience, to use SableCC AST as your independient model is not a very good idea. SableCC AST is very verbose (it uses a lot of empty useless classes that you have to cast to its usually unique implementation) and you are going to do a lot of castings. SableCC DepthFirstWalkers are also not very powerful.

So, in my opinion, you have to:

1. Define an intermediate language model (by hand or with other tool)
2. Define a SableCC grammar of your concrete syntax.
3. Define a transformation between SableCC (CST or AST, as you want) to your intermediate language.
4. Define N transformations between your intermediate language to n platform dependient languages.
   
1. You can do it directly, which is going to be faster to develop by usually is going to generate worst code
2. Define a platform dependient model (like classes that represents the java/matlab/whatever code you are going to generate), a transformation between your intermediate model and your platform dependient code and finally generate code from your platform dependient model. You need to invest more time developing the system, but you are going to be able to do some platform dependent optimizations on generated code.

You can use Eclipse ecore to generate your intermediate language, but in my opinion it has to many dependencies and if you (or your client) are not going to use Eclipse, it has no sense to add tens of megabytes of libraries only to generate simple POJOs that you can create by hand.

2013/4/10 Michael Mast <mbm...@pacbell.net>

You could use SableCC to translate your "pseudo code" into XML and then use XSL to translate the XML into any number of target languages.

--
-- You received this message because you are subscribed to the SableCC group. To post to this group, send email to sab...@googlegroups.com. To unsubscribe from this group, send email to sablecc+u...@googlegroups.com. For more options, visit this group at https://groups.google.com/d/forum/sablecc?hl=en
---
You received this message because you are subscribed to the Google Groups "SableCC" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sablecc+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[peter lavalle]

I have been working on something like this to pre-process GLSL files for use in a Java framework - it "works" even if I haven't finished it (I need to finish arrays)

Roughly,

1. I defined a "model" in POJO
2. parse the GLSL-like file as a SableCC CST
3. pass the model to http://www.jamon.org/ templates producing .java files
4. write the .java files to my target/generate-sources folder

When I started writing this I was going to say "no no XML model!" but ... I have changed my mind. XML just has the potential to be more verbose.

POJO ...

   class <% modelObject.name %> : super_class {

XML ...

   class <% xmlObject.getAttribute("name") %> : super_class {