FTD P1 Parser

[Arpita-Jaiswal]

This is summary of my discussion with Abrar related to end based argument continuation and arbitrary nested sections using end (good bye sub-section)

P1 parser:

pub struct Section {
    pub name: String,          
    pub kind: Option<String>,
    pub caption: Option<Header>,
    pub headers: Vec<Header>,
    pub body: Option<(size, String)>,
    pub sub_sections: Vec<Section>,
    pub is_commented: bool,
    pub line_number: usize,
}

 // in case of caption, key would be "$caption$"
enum Header {
    KV { line_number: usize, key: String, kind: Option<String>, value: String },
    Section { line_number: usize, key: String, kind: Option<String>, section: Section }
}

Discussion with Abrar

-- <optional: section-kind> section-name: <section-caption>
<optional: section-header-kind> <section-header-key>: <section-header-value>

<section-body> 

-- end: section-name ;;<optional: section-end-marker>

-- <optional: section-kind> section-name: <section-caption>
<optional: section-header-kind> <section-header-key>: <section-header-value>

-- <optional: section-header-kind> <section-name>.<section-header-key>:

<section-header-value>

-- <section-name>.body:

<section-body> 

-- end: section-name ;;<optional: section-end-marker>

-- section-name: 
<optional: section-header-kind> <section-header-key>: <section-header-value>

-- <optional: section-header-kind> <section-name>.<section-header-key>:

<section-header-value>

-- <section-name>.caption:

<section-caption-value> 

-- <section-name>.body:

<section-body-value> 

-- end: section-name ;;<optional: section-end-marker>

-- section-name: <section-caption>
<optional: section-header-kind> <section-header-key>: <section-header-value>

-- <optional: section-header-kind> <section-name>.<section-header-key>:

<section-header-section>

-- end: <section-name>.<section-header-key> ;; mandatory

<subsections>

-- end: section-name ;; <mandatory: section-end-marker> because subsections are there

-- foo:
name: Abrar

-- integer foo.height:

-- foo.bio:

-- details: 

I am Abrar

-- age: 11

-- end: foo.bio

-- cool-thing-about-me:

I am techie and awesome

-- end: foo

-- <optional: section-kind> section-name: <optional: section-caption>
<optional: section-header-kind> <section-header-key>: <section-header-value>

-- <optional: section-header-kind> <section-name>.<section-header-key>:

<section-header-section>

-- end: <section-name>.<section-header-key> ;; mandatory

<subsections>

-- end: section-name ;; <mandatory: section-end-marker> because subsections are there

-- ftd.column foo:
string name:

-- string foo.bio:

Hello
This is Abrar

-- ftd.ui foo.details:

-- ftd.row: 

-- ftd.text: About me

-- end: ftd.row

-- end: foo.details

-- ftd.text: This is end

-- end: foo

Final P1 parser grammar

-- <optional: section-kind> section-name: <optional: section-caption> ;;  way 1: provide caption
<optional: section-header-kind> <section-header-key>: <optional: section-header-value>



-- <optional: section-header-kind> <section-name>.<section-header-key>:

<optional: section-header-value>


-- <optional: section-header-kind> <section-name>.<section-header-key>:

<optional:  section-header-section>

-- end: <section-name>.<section-header-key> ;; mandatory (because header is taking section as value)




-- <section-name>.body: ;; section body is optional 

<section-body>


-- <section-name>.caption: ;; section caption is optional ;;  way 2: provide caption

<section-caption>


<subsections>

-- end: section-name ;; <required if subsections are there: section-end-marker>

-- <optional: section-kind> section-name: <optional: section-caption>
<optional: section-header-kind> <section-header-key>: <section-header-value>

<optional: body>

<subsections>

-- end: section-name ;; <required if subsections are there: section-end-marker>

[Arpita-Jaiswal]

Can we somehow get self closing tags, eg <br /> equivalent in ftd so reader knows which sections are self closing.

-- foo:

<lots of sections>

<end of page>

In the above case, the user has to scan lots of lines (worst case the whole page) to know that foo is just a simple component, not a container component, i.e. it won't accept children or it doesn't have subsections.

Another advantage of this could be some performance improvement because parsing would be easier.

[amitu]

Point is valid, but are you adding "therefore every component must have a closing tag"? Is this concern important enough to make everything more complex?

Say you come across something drastically new, with the proposed self closing syntax change all you have learn is that it is container or not. What about other things you want to know about that component? Does it take caption? Do we introduce some syntax to make it clear it takes caption? How about body? And how many arguments and what arguments?

All we learn is something is container. When is a user ever only wondering about that?

Regarding the performance improvement, I think it would always be minor, we are taking about < 0.1% optimisation due to just this bit. The larger question is if it helps end users easily understand ftd code?

In React for example every tag must be self closing. Same is true in XML, you have a closing the tag, or it is self closing (<foo />).

So the large point is valid, or at least has a lot of prior art.

But I feel the syntax I am not sure:

-- foo:
-- bar<:   |   -- bar::   |   -- bar':   |   --. bar:   |   == bar:   |   -- bar/:
-- end: foo

I guess if we go this way we have to keep self closing one as -- foo:, since this is used more often by authors, -- h1:, -- markdown:, -- image:, -- code:, -- quote etc etc. Containers are used less frequently by authors, but more often by builders (who create component libraries). We want to optimise things for authors over builders over all.

[Arpita-Jaiswal]

-- ftd.column foo:
integer x: 
integer y: $foo.x

-- integer foo.bar: ;; defining

-- ftd.integer: $foo.bar ;; accessing

For both defining and accessing local variables like foo.bar we have to write <section_name>.<variable_name>.