Cicero conditional block expression is not a block expression

[lambdafu]

Describe the bug
The block expression {{#if flag}}...{{/if}} only works on a single line, and thus is not a block expression after all. 😞

To Reproduce
Grammar:

Hello

{{#if flag}}
Bye
{{/if}}

Sample.md:

Hello

Model:

o Boolean flag

Output of cicero parse:

12:47:16 PM - error: invalid syntax at line 20 col 10:

  rule1 -> "
           ^
Error: invalid syntax at line 20 col 10:

  rule1 -> "
           ^
    at Lexer.next (/node_modules/nearley/node_modules/moo/moo.js:397:13)
    at Parser.feed (/node_modules/nearley/lib/nearley.js:270:30)
    at Function.compileGrammar (/node_modules/@accordproject/cicero-core/lib/parsermanager.js:539:21)
    at ParserManager.setGrammar (/node_modules/@accordproject/cicero-core/lib/parsermanager.js:113:37)
    at ParserManager.buildGrammar (/node_modules/@accordproject/cicero-core/lib/parsermanager.js:184:10)
    at /node_modules/@accordproject/cicero-core/lib/templateloader.js:225:32
    at Generator.next (<anonymous>)
    at asyncGeneratorStep (/node_modules/@accordproject/cicero-core/lib/templateloader.js:16:103)
    at _next (/node_modules/@accordproject/cicero-core/lib/templateloader.js:18:194)
    at process._tickCallback (internal/process/next_tick.js:68:7)
12:47:16 PM - error: invalid syntax at line 20 col 10:

  rule1 -> "

Expected behavior
A block expression should be able to hold, uhm, blocks? What's up with that? 🐈 Also, error message is not helpful. This also seems like a bug that a fuzzer could find very quickly.

[jeromesimeon]

Hi @lambdafu I guess there are a couple of things going on there:

• terminology (we used the term blocks in the documentation from a template language point of view (e.g., https://handlebarsjs.com/guide/block-helpers.html) -- this really was to distinguish the {{#...}} ... {{/...}} syntax from other kind of template notations. I am assuming in your comment that you mean block from a markdown point of view? (i.e., as opposed to inlines?). We may need to review the terminology choices there.
• With the new parser we have a much cleaner relationship to markdown. Currently: {{#clause}} {{#ulist}} and {{#olist}} are markdown blocks while {{#if}} {{#with}}and{{% formula %}}` are markdown inlines

So you will be able to do this:

Hello

{{#if flag}}Bye{{/if}}

But not:

Hello

{{#if flag}}
Bye

Really bye
{{/if}}

Because from a markdown perspective you really have two paragraphs.

We could possibly handle both (the same way markdown distinguishes between html inlines and html blocks).

[jeromesimeon]

For reference:

bash-3.2$ more test/data/testIfBlock/grammar.tem.md 
Hello

{{#if flag}}Bye{{/if}}
bash-3.2$ more test/data/testIfBlock/sample.md 
Hello
bash-3.2$ ../markdown-cli/index.js transform --from markdown --to data --grammar test/data/testIfBlock/grammar.tem.md --ctoFiles test/data/testIfBlock/model.cto --input test/data/testIfBlock/sample.md
10:54:53 AM - info:
{
  "$class": "org.test.MyClause",
  "flag": false,
  "clauseId": "b9f1dc19-4ace-4ade-b6c2-81ed8ef14d30"
}
bash-3.2$ more test/data/testIfBlock/sample-true.md
Hello

Bye
bash-3.2$ ../markdown-cli/index.js transform --from markdown --to data --grammar test/data/testIfBlock/grammar.tem.md --ctoFiles test/data/testIfBlock/model.cto --input test/data/testIfBlock/sample-true.md
10:55:15 AM - info:
{
  "$class": "org.test.MyClause",
  "flag": true,
  "clauseId": "466668b0-50a3-4289-b736-5c643ff451e5"
}
bash-3.2$ 

[jeromesimeon]

Some details about your use case would help.

[lambdafu]

Hi Jerome, thanks for your response. The terminology is confusing to me, and yes, I was interpreting block elements typographically (or at a markdown level, whatever you prefer). Thanks for the clarification. Although I appreciate the effort to create a specification that allows bidirectional parsing without being intrusive, I also have to say that I was surprised more than once. This violates a little bit the "principle of least surprise" that a good toolchain should have. On the one hand, I understand that this allows dropping some markup in the rendered result (as long as the grammar is prefix-free), but on the other hand, even that is not consistent, as the all-important string type needs double-quotes anyway. Not really sure what to recommend here, though. It's a tight design space.

As for the use case, I am working in a project that is looking at legal certainty issues surrounding smart contracts, and we are very interested in Accord and integration in Hyperledger Fabric. As part of our efforts to educate ourselves, I have given an in-depth 4h workshop on Accord and HLF integration, and during my research for the material I have poked at Accord a little bit and found these issues, and thought I would report them. We are still designing the system, so my examples are artificial and just the result from playing around with the tools. But my main concern here is usability: If non-programmers are expected to be able to draft contract grammars and data models, such weird edge cases can be a real bummer.

Thanks for working on Accord, btw!