end based argument continuation

[amitu]

Status: In Progress

Owner: @Arpita-Jaiswal Started On: 1st September

TODO

• P1 Parser
• DI
• AST
• Interpreter
• Executor
• UI
• Create FTD/FPM release
• Fix all the ftd files in all fpm repos

Available styles

Common

• padding
• padding-left
• padding-right
• padding-top
• padding-bottom
• padding-horizontal
• padding-vertical
• border-width
• border-radius
• border-top-left-radius
• border-top-right-radius
• border-bottom-left-radius
• border-bottom-right-radius

Container

• spacing
• wrap

Daily Update

27th October

• Basic event working ✌️, check 7-events.ftd

26th October

• Change the value on event
• Added data in html
• Added functions in html
• Added events read in html

21st October

• Added ftd_v2 in examples

11th October

• Recusive loop in html state
• Added recursive variable in interpreter test
• Added recursion in component interpreter
• Added recursion in record interpreter

10th October

• Added iteration in Component in executor
• Added iteration in Component in interpreter, wip in executor

9th October

• Refactor: Added ExecuteDoc::execute_simple_component
• Added data-id in html node
• Added component definition and its invocation in interpreter
• Added insert_local_variable in executor tdoc

8th October

• Tests link 1 link 2

7th October

• Added html tests

6th October

• Fix html test and added ftd.column in executor

5th October

• Added ftd.row in executor
• Node and html added
• Executor added test
• Executor initial setup

4th October

• Added intepreter component-invocation test

3rd October

• Interpreter ComponentDefinition done
• Interpreter Component done and added to interpreter state

2nd October

• Set variable function in interpreter
• Interpreter ComponentDefinition

29th September

• Added variable_definition to interpreter
• Added variable_invocation to interpreter
• Added expression in interpreter

28th September

• Interpreter ast_value to property value added

26th September

• Interpreter Record test added
• Interpreter Record added

25th September

• Added condition in component property test
• Added condition in headers test
• Added condition in headers
• Ignore comments while processing AST
• Added condition in component and variable invocation
• Added componentInvocation test

24th September

• Added line_number in VariableInvocation
• Added line_number in variabledefinition and created struct for header
• Record field updated
• Added line_number in record
• Line number added in import
• Added events in Component
• Added iteration in Component

23rd September

• Component definition test added in AST
• Component Invocation added in AST
• Component Definition added in AST

22nd September

• Some minor fixes related to ast variable
• Added variable invocation ast
• Added more test for AST::VariableDefinition
• Variable value done

21st September

• Added ast for import and record

15th September

• bringing back `component` keyword #421
• anonymous list #385
• Variable Invocation #424

12th September

• Rename AST to DI (import, record)
• Added Definition in DI
• Added Invocation in DI
• Tests

11th September

Read About

• HM type system
• Chomsky Hierarchy in Theory of Computation
• Context-free grammar / Context-free language
• Regular grammar
• Pushdown automata
• Finite Automata

10th September

• FTD AST for import
• FTD AST for record

9th September

• Create Interpreter States (works only for the variable for now)
• Integrate Variable in the interpreter

8th September

• Create Interpreter States (works only for the variable for now)
• Integrate Variable in the interpreter
• Implement Record

7th September

• Implement Variable

6th September

• Implement Variable Value/Property Value

3rd September

• Variable Kind Data

2nd September

• P1 parser

1st September

• P1 parser

---

Related Discussions

• ftd `DI` (Definition and Invocation) #417
• ftd `Definition Tracker` #419
• ftd Ast #413
• end based argument continuation #388
• FTD P1 Parser #390
• bringing back `component` keyword #421
• arbitrary nested sections using `end` (good bye sub-section) #381
• anonymous list #385
• Variable Invocation #424
• instead of `append-at`, what if we have `$children` #380

Say if I have to write something like this:

-- clippy.check: absurd_extreme_comparisons
group: correctness
level: Deny
what-it-does:
> Checks for comparisons where one side of the relation is
> either the minimum or maximum value for its type and warns if it involves a
> case that is always true or always false. Only integer and boolean types are
> checked.
why-it-is-bad:
> An expression like `min <= x` may misleadingly imply
> that is is possible for `x` to be less than the minimum. Expressions like
> `max < x` are probably mistakes.
known-problems:
> For `usize` the size of the current compile target will
> be assumed (e.g., 64 bits on 64 bit systems). This means code that uses such
> a comparison to detect target pointer width will trigger this lint. 
> 
> One can use `mem::sizeof` and compare its value or conditional compilation
> attributes like `#[cfg(target_pointer_width = \"64\")] ..` instead."
example: 
> -- ft.code:
> lang: rs
> 
> let vec: Vec<isize> = vec![];
> if vec.len() <= 0 {}
> if 100 > std::i32::MAX {}

Currently there can be no empty lines. What if we can also write:

-- clippy.check: absurd_extreme_comparisons
group: correctness
level: Deny

what-it-does:
> Checks for comparisons where one side of the relation is
> either the minimum or maximum value for its type and warns if it involves a
> case that is always true or always false. Only integer and boolean types are
> checked.

why-it-is-bad:
> An expression like `min <= x` may misleadingly imply
> that is is possible for `x` to be less than the minimum. Expressions like
> `max < x` are probably mistakes.

known-problems:
> For `usize` the size of the current compile target will
> be assumed (e.g., 64 bits on 64 bit systems). This means code that uses such
> a comparison to detect target pointer width will trigger this lint. 

> One can use `mem::sizeof` and compare its value or conditional compilation
> attributes like `#[cfg(target_pointer_width = \"64\")] ..` instead."

example: 
> -- ft.code:
> lang: rs

> let vec: Vec<isize> = vec![];
> if vec.len() <= 0 {}
> if 100 > std::i32::MAX {}

Notice the blank lines added. They improve readability. They make our body parser difficult by assuming body can not start with a line containing :.

If we do indeed have more intelligent body parser, can we not do:

-- clippy.check: absurd_extreme_comparisons
group: correctness
level: Deny

what-it-does:

Checks for comparisons where one side of the relation is
either the minimum or maximum value for its type and warns if it involves a
case that is always true or always false. Only integer and boolean types are
checked.

why-it-is-bad:

An expression like `min <= x` may misleadingly imply
that is is possible for `x` to be less than the minimum. Expressions like
`max < x` are probably mistakes.

known-problems:

For `usize` the size of the current compile target will
be assumed (e.g., 64 bits on 64 bit systems). This means code that uses such
a comparison to detect target pointer width will trigger this lint. 

One can use `mem::sizeof` and compare its value or conditional compilation
attributes like `#[cfg(target_pointer_width = \"64\")] ..` instead."

How do we handle the code block?

example: 
> -- ft.code:
> lang: rs

> let vec: Vec<isize> = vec![];
> if vec.len() <= 0 {}
> if 100 > std::i32::MAX {}

One option is we mix multiline headers with self closing tags:

-- clippy.check: absurd_extreme_comparisons
group: correctness
level: Deny

-- what-it-does:

Checks for comparisons where one side of the relation is
either the minimum or maximum value for its type and warns if it involves a
case that is always true or always false. Only integer and boolean types are
checked.

-- why-it-is-bad:

An expression like `min <= x` may misleadingly imply
that is is possible for `x` to be less than the minimum. Expressions like
`max < x` are probably mistakes.

-- known-problems:

For `usize` the size of the current compile target will
be assumed (e.g., 64 bits on 64 bit systems). This means code that uses such
a comparison to detect target pointer width will trigger this lint. 

One can use `mem::sizeof` and compare its value or conditional compilation
attributes like `#[cfg(target_pointer_width = \"64\")] ..` instead."

-- example: 

-- ft.code:
lang: rs

let vec: Vec<isize> = vec![];
if vec.len() <= 0 {}

if 100 > std::i32::MAX {}

-- end: ft.code

The body

The body is too far now. Also header fields are not namespaces, so it is not obvious if they are parameters or not. Plus it is forcing us to close the ft.code, which is a self closing component.

Maybe we can do this:

-- clippy.check: absurd_extreme_comparisons
group: correctness
level: Deny

-- this.what-it-does:

Checks for comparisons where one side of the relation is
either the minimum or maximum value for its type and warns if it involves a
case that is always true or always false. Only integer and boolean types are
checked.

-- this.why-it-is-bad:

An expression like `min <= x` may misleadingly imply
that is is possible for `x` to be less than the minimum. Expressions like
`max < x` are probably mistakes.

-- this.known-problems:

For `usize` the size of the current compile target will
be assumed (e.g., 64 bits on 64 bit systems). This means code that uses such
a comparison to detect target pointer width will trigger this lint. 

One can use `mem::sizeof` and compare its value or conditional compilation
attributes like `#[cfg(target_pointer_width = \"64\")] ..` instead."

-- this.example: 

-- ft.code:
lang: rs

let vec: Vec<isize> = vec![];
if vec.len() <= 0 {}

if 100 > std::i32::MAX {}

-- this.body:

The body

-- this.body would be only needed if any -- this.<argument-name>: (argument continuation) has been used.

Instead of introducing this, we can also do:

-- clippy.check: absurd_extreme_comparisons
group: correctness
level: Deny

-- clippy.check.what-it-does:

Checks for comparisons where one side of the relation is
either the minimum or maximum value for its type and warns if it involves a
case that is always true or always false. Only integer and boolean types are
checked.

-- clippy.check.why-it-is-bad:

An expression like `min <= x` may misleadingly imply
that is is possible for `x` to be less than the minimum. Expressions like
`max < x` are probably mistakes.

-- clippy.check.known-problems:

For `usize` the size of the current compile target will
be assumed (e.g., 64 bits on 64 bit systems). This means code that uses such
a comparison to detect target pointer width will trigger this lint. 

One can use `mem::sizeof` and compare its value or conditional compilation
attributes like `#[cfg(target_pointer_width = \"64\")] ..` instead."

-- clippy.check.example:  

;; don't have to close `.example` because example's type is `ftd.ui`
;; and depending on the actual UI constructor passed, we have to close
;; or not close. Here we are passing `ftd.code`, which is not a container
;; so it nothing has to be closed. Had we passed a `ftd.row` to `example`
;; we would had to close the `ftd.row`

-- ft.code:
lang: rs

let vec: Vec<isize> = vec![];
if vec.len() <= 0 {}

if 100 > std::i32::MAX {}

-- clippy.check.body:

The body

[Arpita-Jaiswal]

Currently, for caption, we use continuation syntax >. For instance

-- title: 
> Hello
> This is wonderful
author: Abrar

What if we follow proposed syntax and write something like

-- title:
author: Abrar

-- title.caption: 

Hello
This is wonderful

[Arpita-Jaiswal]

@amitu Please take a look.

[amitu]

Looks good.

[Arpita-Jaiswal]

For this

-- page:
header: 
> -- foo:
> bar:
>> -- ftd.text: Hello
 

-- ftd.column page:
ftd.ui header:

-- ftd.column foo:
ftd.ui bar:

Now, we need to do this

-- page:

-- page.header:
  
    -- foo:
    
    -- foo.bar: 
      
          -- foo:
          
          -- this.bar: 
              
                  -- ftd.text: Hello

With indentation, this looks fine, but without it, this looks horrible.

[amitu]

Yep. Indentation would make things more readable in some cases. Anyways we do support indentation so its alright.

[amitu]

Also I updated the description with a syntax without this.

-- page:

-- page.header:

-- foo:    
   -- foo.bar: 

        -- foo:
             -- this.bar: 
                  -- ftd.text: Hello
          -- end: foo

-- end: page.header

Am stumped here.

[amitu]

I think the resolution here is to force an -- end even for argument type ftd.ui where it is strictly speaking not needed as it takes a single component, and that component can chose to end itself or not depending on if it is container or not.

[amitu]

-- page:

-- page.header:
  
-- foo:
  -- foo.bar: 
      -- foo:
         -- foo.bar: 
           -- ftd.text: Hello
         -- end: foo.bar
  -- end: foo.bar


-- end: page.header

[amitu]

The key thing is we are still trying to reduce the number of ends needed, while still being unambiguous (at least to the program).

[amitu]

We can use anonymous list also without > s:

-- person a:

-- person.jobs:

-- job: Intern
company: FifthTry
started: 2022-08-22
ended: 2022-12-07
 
Implemented some cool stuff.

-- job: Dev Ops 1
company: FifthTry
started: 2022-12-08

Deving some ops.

-- end: person.jobs ;; we have to end because this is a list

-- person.tags:

-- string: whatever
-- string: whatever-else

-- end: person.tags

[Arpita-Jaiswal]

If we have to use "continuation" during component definition, eg:

-- ftd.row foo:
string details:
> This is foo
> Details
ftd.ui title:
> -- ftd.text: Hello

How would we do it?

-- ftd.row foo:

-- string foo.details:
This is foo
Details

?

[Arpita-Jaiswal]

Two open points as of now:

• ftd.ui list children where children is the special keyword for container type component
• We all agree that $ is just for referring to a variable. Using $ to define a variable as mutable, like -- string $name: foo is inconsistent. Should we have a different keyword or special character or header or something instead? Shobhit has suggested using mut keyword.