Re: [cellml-discussion] Describing rules for translating expressions into arbitrary languages

2007-05-08 Thread Andrew Miller
Jonathan Cooper wrote:
> * Andrew Miller <[EMAIL PROTECTED]> [2007-04-29 23:51]:
>   
>> I have defined a file format specification, called MAL (or 
>> MathML-language mapping) designed to contain all the information needed 
>> to generate expressions for a specific programming language. I would 
>> welcome any feedback anyone may have on the specification. I would be 
>> particularly interested in hearing if you can think of some extension to 
>> the language which is needed to support generation for a certain 
>> language. The specification follows...
>> 
>
> I think this is a sensible direction to go in.  I am curious, however, as
> to whether there was any particular reason not to use an XML format for
> MAL?
>   
This hasn't been discussed with a wider group yet, but I though about 
making it an XML format, and decided against it for several reasons:
1) Most of the structure of the MAL file couldn't be represented 
efficiently as XML. For examples of why separate languages are needed 
for representing this type of information efficiently, look at XPath for 
example, which has also chosen not to use XML for similar reasons.

2) The remaining structure (which is basically just a mapping between 
keys and values) could be represented in XML, but I feel that it would 
add complexity (at least in the sense of verboseness) to MAL without a 
lot of gain. If MAL had more complicated hierarchical structures, there 
might have been a better case for using XML.

I was actually originally going to have the API ask for the pattern for 
each MathML operator through a programmatic interface, but I decided 
that this would just result in the need to write some sort of table in 
your programming language, as opposed to writing a nice language 
independent, re-usable table.

We don't want to require specialised tools to edit MAL, because it is 
intended to simplify the process of creating language bindings, not 
complicate it.

Best regards,
Andrew

___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion


Re: [cellml-discussion] Describing rules for translating expressions into arbitrary languages

2007-05-08 Thread Jonathan Cooper
* Andrew Miller <[EMAIL PROTECTED]> [2007-04-29 23:51]:
> I have defined a file format specification, called MAL (or 
> MathML-language mapping) designed to contain all the information needed 
> to generate expressions for a specific programming language. I would 
> welcome any feedback anyone may have on the specification. I would be 
> particularly interested in hearing if you can think of some extension to 
> the language which is needed to support generation for a certain 
> language. The specification follows...

I think this is a sensible direction to go in.  I am curious, however, as
to whether there was any particular reason not to use an XML format for
MAL?

Jonathan.

-- 
Jonathan Cooper  MSN: [EMAIL PROTECTED]  www: jonc.me.uk/

It is astonishing what foolish things one can temporarily believe if one
thinks too long alone.  - Keynes
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion


[cellml-discussion] Describing rules for translating expressions into arbitrary languages

2007-04-29 Thread Andrew Miller
Hi,

I am looking at refactoring the CCGS into several components, as 
discussed in an earlier e-mail. As part of this, I am looking at how I 
can separate out the language specific parts of code generation. At this 
stage, I am focusing on how expressions get generated, rather than 
entire assignments. This will then be combined with code to generate the 
procedural steps required to evaluate a model. Writing a program to 
generate code for a new language will then be as simple as iterating 
through the procedural steps, writing out assignments of expressions 
into variables, in addition to supplying all the language specific glue 
to the integrator.

I have defined a file format specification, called MAL (or 
MathML-language mapping) designed to contain all the information needed 
to generate expressions for a specific programming language. I would 
welcome any feedback anyone may have on the specification. I would be 
particularly interested in hearing if you can think of some extension to 
the language which is needed to support generation for a certain 
language. The specification follows...

MAL Format is intended as a succinct but complete description of how to
translate expressions from MathML into the syntax of another programming
language. It is intended to be both simpler but more powerful (within the
problem domain it is trying to address) than more generic approaches such as
XSLT.

Format:
The format consists of a series of tags. Each tag has a series of 
alphanumeric
characters(the tag name), followed by a collon and a space (": "), 
followed by a
series of characters (the tag value). The tag is terminated by a 
carriage return
or line-feed character, and the next tag starts at the first character which
isn't a carriage return or line feed.

Where line-length formatting transforms (such as for FORTRAN 77), a
post-processing stage must be used to achieve this. The reason for this 
design
decision is that expressions alone do not determine line length.

The following tags are defined:

Name: opengroup
Value: A string which can be appended before another string to force that
  string to have the highest precedence.
Examples:
  opengroup: (
  Sets the open group string to be (, which is the open group character in
  languages like C.

Name: closegroup
Value: A string which can be appended after another string to force that
  string to have the highest precedence.
Examples:
  closegroup: )
  Sets the close group string to be ), which is the close group character in
  languages like C.

Name: The name of any MathML operator.
Value: A string describing the format. This string shall start with a
  description of operator precedence in the target language, and then 
describe
  a pattern for generating the target language expression.

  A precedence description is specified between #prec[ and ]. The following
  precedence descriptions can be used:

  #prec[n(m)] where n and m are integers between 0 and 1000. Sets the outer
  precedence to n (this is a precedence score for the resulting expression),
  and the inner precedence to m (this is a precedence score below which
  operands must be if they are not to require opengroup / closegroup strings
  around them.

  #prec[n] where n is an integer is a shorthand for #prec[n(n)]

  #prec[H] is a shorthand for #prec[1000(0)].

  In an operator description, character sequences which are not matched 
below
  are written directly out to the output mathematics.

  #expri reference the recursive expansion (according to the rules
  in the MAL file) of the ith operand, where i is a positive integer. The
  highest i value present also acts as the number of operands which must be
  present in the MathML to avoid an error.

  #exprs[text] expands to the concatenation of each consecutive operand 
after
  expansion according to the rules. The string text intervenes between 
operands,
  but is not added before the first operand or after the last.

  #logbase expands to the expansion of the logbase element contents. This is
  only valid for log. If no logbase element is found, the string 10 will be
  inserted.

  #degree expands to the expansion of the degree element contents. It is 
only
  valid for root. If no degree element is found, the string 2 will be 
inserted.

  #bvarIndex expands to the text of the bvarIndex annotation (as 
retrieved by
  the AnnotationSet supplied to MaLaES) on the source of the bound variable
  referenced.

  #uniquen (where n is an integer) expands to a globally unique integer. 
If uniquei
  (for the same i) is used more than once in the same line, it refers to the
  same number. However, a different number is generated each time a rule is
  processed.

  #lookupDiffVariable (only valid on diff) finds the ci associated with the
  diff (differentiation of something other than a variable is not 
supported by
  this form, and will result in an error), and then finds the source 
variable
  associated with that ci. It then asks the supplied Annotat