p-script to f-script

[amitu]

fastn is kind of internally two languages, a bit like how HTML and JS are two "languages", but a single document can contain both. HTML is the outer "container", which internally can refer to JS in a few places. Similarly for us, p-script is the outer "container", and it can from p-script to f-script.

In HTML we do it via two ways, either the <script> tag, or via adding click-handler etc, eg onclick: "foo()".

We currently have the following ways to go from p-script to f-script:

-- integer foo():

1 + 2

This is a bit like <script> case, this is a user defined function. How do we know this is a function, because of the (), but also because the return type of this function is integer which is not a UI as currently we only data from user defined functions in fastn. We will have to come to this later on, can we go from f-script to p-script, a bit like how we go from javascript to "HTML" in React using JSX syntax. Just for record, my current bias is no, we will not have any syntax to go from f-script to p-script, because our component syntax is already there to create a "function" that returns a UI. Javascript had no syntax, and they only had "functions" which are pure data, which is why we consider Javascript and more current programming languages as "data languages", fastn aspires to be a "ui language".

The other ways we go to f-script are variables:

-- foo: $x

Here we are doing variable interpolation. Currently this is not valid:

-- foo: $x + 1

Which is what this discussion is about. Should this be valid? What would be the precise syntax?

We similarly have

-- foo: 
color if { x > 10 }: red

Here we went to f-script using the {} "curly notation".

Strings Are Special - But Also: Most Strings Are "UI"

One solution we can come up for this problem is string agnostic, same solution for everything, string and non string alike. But I feel we have to also consider strings are special use case.

We want to style individual parts in the string, we have to possibly even add event handing etc inside the string.

So a type agnostic approach would not work. Similarly a string interpolation syntax would not be enough. Unless we treat strings as raw code, and then parse the code somehow before rendering.

Lets look at various choices we can make for the three different cases.

Type Agnostic

This is what we have right now, you can put either string literal, -- foo: x or put $x: -- foo: $x, and it kind of does not matter what is type of $x, from syntax's point of view (type of x must still match the caption in foo). This is type agnostic. We can put -- foo: $bar(a=$x) also, and it does not matter if $x is string or any type. These are type agnostic solution, and def are going to have to keep these, and possibly improve their syntax.

Strings Are Special

Next comes strings are special, we want to be able to write -- foo: Hi, $name and this requires us to parse the string and find the $x references. This only makes sense for strings, and basically nothing else, so this is strings are special solution.

We definitely want to do some version of this.

(Most) Strings Are UI

But this is the biggest problem. $name in "strings are special", was assumed to be string, and it can lead to issues, eg if you did: -- foo: Hi, **$name**. Here you are trying to make the name appear in bold by wrapping name in ** markdown bold syntax. Problem is this only works if name say does not contain **Amit** Upadhyay. A naive substitution will lead to this markdown getting generated: Hi, ****Amit** Upadhyay, which will lead to bolding an empty string, first four *, and starting the bolding for ** Upadhyay, and not ending it. Markdown parser will "handle" it but this is clearly a bug.

So what do we do? Teach people about markdown escaping? It would be better to not create the intermediate string, if we treat Hi, **$name**, not as string, but a thing with a "hole"/"slot" for putting some other thing, we solve the escaping problem, by creating this DOM structure: Hi, <em><em>Amit</em> Upadhyay</em>. This is arguably the "correct" thing, follows the users intention.
sg.](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals). Python and JS both will covert it to string type after applying the interpolation. And will do interpolation multiple times, if this process is to be chained. Important point is every time this operation is applied, the down-stream strings are flattened out into a string, and you do not get a nested tree, but just a flat string. (Technically with JS template literals can write your own template literal that can preserve the tree, but this is not the default javascript string literal template interpolation behaviour let msg = 'Hi ${firstName}' (using ' because, well because of the problems I am trying to solve in this very document)).

A nested tree is superior is our thesis. Python/JavaScript picking string as string is why they are "data languages", and we are "ui language".

Servers Need Strings

Not all strings are UI and some strings should always be "flat strings". Such strings are usually input you send from forms to backend for storing in DBs. DBs can not handle "ui", and they need strings. So we have to convert "strings" to some format that can be stored in db. Escaping, XSS, SqlInjection etc etc.

Markup Syntax

We also have markup syntax:

-- component f:
caption text:

-- end: f

-- component r:
caption text:

-- end: r

-- ftd.text: {f: Hello {r: world!}}

Which you can think of as:

    <ftd.text 
         text=
            <f 
                  text=Hello <r 
                       text=World
                   >
             >
     >

So what is the type?

I think we should have string type, or maybe we call them string-literal type, which will be used for forms, and other such things, where our intention is flat string (call it flat-string?).

And string, which is what you want most of the time, because largely when you are writing components and documents in fastn, you want the strings to be full of styling etc, be an alias to ftd.ui.

We already have a type, ftd.ui, which can be used in 0.4, to represent any UI. We can say ftd.text takes ftd.ui instead of string.

[amitu]

string vs text vs label | string vs text-block vs text | string vs text vs inline-text

We can think of three types, string that we already have, but only reserved for data sent to server, or other programmatic strings.

We then have two types, text | text-block and label | inline-text, one for representing blocks of text, e.g. body of a blog post, and other an inline text, like caption of an image or code snippet, or text of a button etc.

The short and long texts are not strict aliases to string, but represent nested UI.