Definition in problem statement template?

[vexorian]

Does anyone else think this feature could be useful? Adding the definition section to the problem statement template.

Good things:

• Generated Problem statement HTML will be a stand-alone description of the problem (currently you need to read the generated source code to know the return type).
• Coders are familiarized with it.
• Quickly knowing the return type as opposed to waiting till you read code is useful in solving process: If the return type is long it can be a hint.

Bad things:

• Problem statement would be longer (Can fix this by making it possible to hide the definition section through options).
• It is actually complicated to implement. I was trying to add it myself, I forgot that this section is very language specific. So far it appears that the cleanest way to do this is to have a problem-definition template as a requirement for the problem-desc template. (Will template requirements automatically call a requirement if none is defined?) Since this requirement of an extra template will complicate things and configuration, that's why I am asking...

Update:
In reality, it appears it is quite possible to make a template that works in all the C-like languages. Python and VB would need separate templates. It still requires us to have a separate problem-definition template for each language, though.

Update 2:
Python might be an issue to do even with a separate template. An alternative would be to make a different HTML renderer for each language. The python HTML renderer should turn integer type to "integer" as opposed to just empty. There could also be a method HTML renderer. This might be too much of an issue, indeed.

[vexorian]

After some changes to #113 , it is possible to select the language in Type;html(cpp), this way we can actually make the definition always use Java/ c++/ C# syntax in definition. Which is like the problem statement in statistics. So that is an alternative, make problem-desc always use Java by default, allow to change to c++ and maybe C# if it is really that different to Java.

[vexorian]

Currently my definition looks like this, except using c++ http://gist.github.com/vexorian/8177600

[zen0wu]

@vexorian I've reimplemented this functionality, it turns out it's not that complicated.
The workaround is to add a renderMethod method to each language, then the method signature can be successfully rendered, including Python.
About the problem of <> under C++, I rewrote the TemplateEngine to work on this.
Now there's a new named renderer called seq, which is a special one.

Here's a simple description.
It accepts a list of renderers, like ${key;seq(a,b,c)},
it's an iterative renderer, if you see a renderer as a function, then the output is c(b(a(key))).
The form of a could be:

1. '#', means the same as ${key}
2. $x(y,z), means take the previous output as a key name k and call ${k;x(y,z)}.
   (Haven't tested this, since there's currently no usage scenario, but seems interesting and powerful,
   also not sure about whether the $ will cause any problems.)
3. other named renderer like html(grid), just means the same as ${key;html(grid)}.

This renderer allows nested named and normal rendering, which may make the engine more powerful,
although not in a direct way. Then the result of rendering a type in C++ can be further rendered by
writing ${p.type;seq(#, html)}. The language-specific HTML renderer change has been roll backed.

This is a major rewrite, and may cause bugs, please help me test it.

Also, we can remove the showDefinition options in the problem desc template, but it's also OK to leave it there.
I'm also considering to simplify some of the complexity from this template, it seems to be too complex, like the fancy circle on the case number. And it seems to be suffering some aligning problems.

[vexorian]

hmnn.

• While it is great to make Greed generate language-specific problem definitions, I actually liked forcing a language (java) on problem definition: This way the HTML file stays the same when I change language and the <type> tags in statement are still using java anyway (unless we managed to fix this somehow). So I would like to keep the ;html(java) renderer or something similar for a custom template :).
• seq seems complicated but as long as it works and you document it well in the wiki that's fine.
• As long as we are making changes to the template system. It would be nice to have something to format floating-point values. If you provide 2.0, you could choose to render it as 2.000 or 2.0 .
• Regarding the HTML template (simplifying, removing the number decorations, let me create a separate issue: What to do with problem statement template #117

[zen0wu]

• A new options called forceDefLanguage is added to force the definition part to some given language, false means no forcing.
• the format thing could be achieved by custom named renderer I think.