Conditions can have spaces as block attributes, but not as phrase attributes

[0x8000-0000]

This text:

$ cat tc.sam 
!annotation-lookup: case insensitive
!smart-quotes: on

example: Title

    section:(?when=some time)
        {Lorem ipsum dolor sit amet, consectetur adipiscing elit.}(?when=other time) {Cras lobortis erat leo, eu tincidunt leo efficitur vel.}(?when=always)

Is rendered to XML as:

<?xml version="1.0" encoding="UTF-8"?>
<example>
<title>Title</title>

<section conditions="when=some time">
<p><phrase>Lorem ipsum dolor sit amet, consectetur adipiscing elit.</phrase>(?when=other time) <phrase conditions="when=always">Cras lobortis erat leo, eu tincidunt leo efficitur vel.</phrase></p>
</section>
</example>

[0x8000-0000]

It seems from the language spec that the intent is to have multiple conditions, leaving it up to the semantic layer to interpret them. Which is fine, but should the semantic layer always "and" the conditions or always "or" the conditions?

How do we express that something applies to apples and oranges, and that something else does not apply to cats nor dogs?

[mbakeranalecta]

Conditions are tokens. They can't contain spaces. Error detection for things like this is poor though. There parser relies too much on regular expressions to do all the error detection it should. Instead of seeing a condition attribute with an error, if did not see the attribute at all. This is a case of a language that outgrew the simple implementation it began with. Really, the parser should be rewritten by some one with the skill set to write a proper recursive descent parser with full error checking. (Which would also involve a more mathematically robust specification to define what is an error, since lightweight markup by it's nature often treats broken markup as plain text.) ⁣Sent from TypeApp ​

…

On Feb 10, 2020, 3:33 PM, at 3:33 PM, Florin Iucha ***@***.***> wrote: This text: ``` $ cat tc.sam !annotation-lookup: case insensitive !smart-quotes: on example: Title section:(?when=some time) {Lorem ipsum dolor sit amet, consectetur adipiscing elit.}(?when=other time) {Cras lobortis erat leo, eu tincidunt leo efficitur vel.}(?when=always) ``` Is rendered to XML as: ``` <?xml version="1.0" encoding="UTF-8"?> <example> <title>Title</title> <section conditions="when=some time"> <p><phrase>Lorem ipsum dolor sit amet, consectetur adipiscing elit.</phrase>(?when=other time) <phrase conditions="when=always">Cras lobortis erat leo, eu tincidunt leo efficitur vel.</phrase></p> </section> </example> ``` -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: #206

[mbakeranalecta]

And. The intent was not to support complex conditional logic at the markup level. It causes too much grief. The intent was the language should be primarily be used for declarative semantics, not for implementing logic in the markup (which most writers do not understand). These is a fair bit in the book about this. ⁣Sent from TypeApp ​

…

On Feb 10, 2020, 3:44 PM, at 3:44 PM, Florin Iucha ***@***.***> wrote: It seems from the language spec that the intent is to have multiple conditions, leaving it up to the semantic layer to interpret them. Which is fine, but should the semantic layer always "and" the conditions or always "or" the conditions? How do we express that something applies to apples and oranges, and that something else does not apply to cats nor dogs? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: #206 (comment)

[0x8000-0000]

Really, the parser should be rewritten by some one with the skill set to write a proper recursive descent parser with full error checking. (Which would also involve a more mathematically robust specification to define what is an error, since lightweight markup by it's nature often treats broken markup as plain text.)

I was contemplating that yesterday.

[0x8000-0000]

And. The intent was not to support complex conditional logic at the markup level. It causes too much grief. The intent was the language should be primarily be used for declarative semantics, not for implementing logic in the markup (which most writers do not understand). These is a fair bit in the book about this.

I understand. However... ​

How do we express that something applies to apples and oranges, and that something else does not apply to cats nor dogs?

This is a problem for my use case. I need to be able to express both situations, succinctly.

[mbakeranalecta]

SAM condition attributes were designed to be a basic facility for simple cases. All it seeks to do is to pass a token to the applications layer to be evaluated to TRUE or FALSE. The intent then is that the application layer will suppress the content that that condition applies to if the token evaluates to FALSE. Interpretation of the condition token is left entirely to the application layer, so nothing prevents you from embedding complex Boolean logic within a condition token, if that is what you want to do. But there may be a better way. The problem with conditions generally is that they can get very complex so a single universal semantics for all conceivable conditions will typically be beyond the ability for most writers to handle correctly. But nothing in SAM prevents you from implementing your own conditional logic using annotations. This allows you to specify conditions in whatever way makes sense for your application and for your writers. Here is an example using standard Boolean logic, but it could be anything that makes sense for your use case: ``` {foo}(if 'cats OR dogs') {bar}(if 'apples BUT NOT oranges') ``` The if annotation is not part of SAM. It is part of the language you create in SAM, and it can be anything word like: `condition`, `only-when`, `unless`, `gruznatz`. You would have to implement the logic to interpret these annotations, of course, but then, you have to implement logic to interpret condition tokens as well. Like XML, SAM is just a markup language. It has minimal default semantics and it does not have a default processing chain (other than it strictly-for-convenience HTML dump). Complex conditional logic should be part of the language you design in SAM, and you should be able to design pretty much anything you want. That is the virtue of a semantically extensible language.