Sorry for the double post, I meant to edit but hit quote...

The working parts of the Java interface is pretty much the CORBA communication. Which is text-based. There probably exists a way to communicate using CORBA from Perl. You would just lose the parsing of the omc output into nicer data types.
Regardless, you would need to transform your DSL into Modelica textual code somewhere.

I think it is also still possible to use the Java interface to parse Modelica text into an AST in Java. But there is no way to go back, and it seems much too complicated. Even if the interface could unparse the Java classes back to Modelica text, I believe it would be simpler to just transform the DSL into Modelica text.

The only thing that might be tricky is pretty-printing the generated Modelica code. But if it is just generated code, do you need to look at it and need it to be perfectly formatted? If you do need that, it is always possible to do:
loadFile("uglyCode.mo");
writeFile("prettyCode.mo",list());

The Modelica code is really a transitional step, it doesn't need to be pretty at all. However I had hoped to maintain a really high development level and never having to write code generation algorithms (If possible, avoiding to learn the Modelica language altogether ). My own research primarily revolves around modeling so I'd like to avoid having another layer of translating/parsing.

Doesn't Modelica internally use ASTs when parsing .mo files ? Would it really be this complicated to translate Java data types to the ones used in Modelica ?

Yann

It would be complicated, slow, and cost too much maintenance on our side to transfer ASTs. If you take something simple like:

model M

  Real r = 11.2;

end M;

The AST for that is:

Absyn.Program.PROGRAM(classes = {Absyn.Class.CLASS(name = M, partialPrefix = 0, finalPrefix = 0, encapsulatedPrefix = 0, restriction = Absyn.Restriction.R_MODEL(), body = Absyn.ClassDef.PARTS(typeVars = {NIL}, classAttrs = {NIL}, classParts = {Absyn.ClassPart.PUBLIC(contents = {Absyn.ElementItem.ELEMENTITEM(element = Absyn.Element.ELEMENT(finalPrefix = 0, redeclareKeywords = NONE(), innerOuter = Absyn.InnerOuter.NOT_INNER_OUTER(), specification = Absyn.ElementSpec.COMPONENTS(attributes = Absyn.ElementAttributes.ATTR(flowPrefix = 0, streamPrefix = 0, parallelism = Absyn.Parallelism.NON_PARALLEL(), variability = Absyn.Variability.VAR(), direction = Absyn.Direction.BIDIR(), arrayDim = {NIL}), typeSpec = Absyn.TypeSpec.TPATH(path = Absyn.Path.IDENT(name = Real), arrayDim = NONE()), components = {Absyn.ComponentItem.COMPONENTITEM(component = Absyn.Component.COMPONENT(name = r, arrayDim = {NIL}, modification = SOME(Absyn.Modification.CLASSMOD(elementArgLst = {NIL}, eqMod = Absyn.EqMod.EQMOD(exp = Absyn.Exp.REAL(value = 11.2), info = Absyn.Info.INFO(fileName = /home/martin/tmp/prettyCode.mo, isReadOnly = 0, lineNumberStart = 2, columnNumberStart = 10, lineNumberEnd = 2, columnNumberEnd = 16, buildTimes = Absyn.TimeStamp.TIMESTAMP(lastBuildTime = 0, lastEditTime = 1.398932e+09)))))), condition = NONE(), comment = NONE())}), info = Absyn.Info.INFO(fileName = /home/martin/tmp/prettyCode.mo, isReadOnly = 0, lineNumberStart = 2, columnNumberStart = 3, lineNumberEnd = 2, columnNumberEnd = 16, buildTimes = Absyn.TimeStamp.TIMESTAMP(lastBuildTime = 0, lastEditTime = 1.398932e+09)), constrainClass = NONE()))})}, ann = {NIL}, comment = NONE()), info = Absyn.Info.INFO(fileName = /home/martin/tmp/prettyCode.mo, isReadOnly = 0, lineNumberStart = 1, columnNumberStart = 1, lineNumberEnd = 3, columnNumberEnd = 6, buildTimes = Absyn.TimeStamp.TIMESTAMP(lastBuildTime = 0, lastEditTime = 1.398932e+09)))}, within_ = Absyn.Within.TOP(), globalBuildTimes = Absyn.TimeStamp.TIMESTAMP(lastBuildTime = 0, lastEditTime = 1.398932e+09))

In addition, the AST used by OpenModelica changes while Modelica concrete syntax stays the same. Guess which one is easier to translate a DSL into? If you translate into Modelica code you also have the benefit of only having to learn Modelica. With OpenModelica abstract syntax you also need to learn some things about the compiler infrastructure (the AST is not only Modelica; it includes MetaModelica, ParModelica, parts of Optimica, and experimental/future versions of Modelica).

I see, thank you for your answers.