# PGLanguageV2

In the category of things I think about that don't help us release WW 2:

It would be nice to have an intermediate format that would be reached during the translation process, that would have all the PG "magic" already worked out (like values based on the problem seed), but not yet be displayMode dependant. Something like this:

<problem> <instructions>Blah, blah, blah. <math mode="display">3x^2 \frac{dy}{dx}</math></instructions> <question>Find the blabbleblobble of <math>\frac{\sqrt{4(5x^4)+2x^3+C}}{dx}</math>. <prompt evaluator="function_cmp" solution="3x^2+2x+5" /> </question> </problem>

Not necessarily that in particular, but something that can be translated into TeX, various breeds of HTML, etc. This makes the translation process look like this:

evaluate this translate ----> HTML + images pg2 ----> perl ----> intermediate ----> to output ----> HTML + MathML code form format ----> TeX

And you could also have other "source" languages. There's an old translator for CAPA problems. Perhaps CAPA could be supported natively in this scheme. I don't know enough about CAPA to know whether this is feasible.

**So where does the perl come in?**

One idea I had was to use a scheme similar to what's used to embed various programming languages in HTML on the server side: like PHP, ePerl, etc. How about Embperl? It allows you to evaluate code and throw away the result (`[- CODE -]`

) or substitute the result (`[+ CODE +]`

), and it also has several control structures. After a cursory examination, it seems that the syntax used my Embperl would be sufficient, if not particularly elegant:

[- $a = random(1, 100, 1); $b = random(1, 9, 2); -] <problem> <instructions>Blah, blah, blah. <math mode="display">3x^2 \frac{dy}{dx}</math></instructions> <question>Find the blabbleblobble of <math>\frac{\sqrt{4([+$b+]x^4)+2x^[+$a+]+C}}{dx}</math>. <prompt evaluator="function_cmd" solution="[+$a+]x^2+2x+[+$b+]" /> </question> </problem>

That evaluates to the code above.

**It's SO HARD to type [+ and then +]. Waah!**

If we *must*, a pass could be added before the embedded perl is evaluated to turn `(\$\w+)`

into `[+\1+]`

. *But I only want to do it for simple scalars!* Otherwise it gets way to fragile!

**What would the macros look like?**

Since the PG macros would be released from having to worry about the display mode, they would be reduced to just stuff that helps generate the data necessary for representing the problem in it's intermediate form. So, essentially, stuff for turning the problem seed into mathematical constructs.

**What about macros that expand the output vocabulary?**

The second phase of translation (turning the intermediate XML representation into a particulary output format) would have to be pluggable, just like the macro language. I have to think about this one.

**So what do you think?**

Let me know :)

-- Main.SamHathaway - 21 Nov 2003