0.5 The namespace confusion (ftd, p-script, f-script)

[siddhantk232]

p-script and f-script as a concept are going to stay. But we also have ftd which means the same thing as p-script. The gotcha is that we use the namespace ftd for various things (ftd.* kernel components, http functions, misc types?). This raises a small issue that we now have so many names that might confuse the future user. The names are:

• fastn
• ftd
• p-script
• f-script

p-script is used as a concept in the spec so that might not become a word that we use in future docs unlike ftd.

The (in progress) spec overview suggests we need to call our language (p-script) something (I say ftd) and there has to be a platform that is capable of leveraging this language to render a web-ui. The platform will provide a package manager, dev tools (linter, formatter etc). This same platform can later be extended to render native UIs for android etc (or some other platform, or a subset of this platform). In fact, it kinda makes sense to have multiple platforms that support ftd (or p-script) but target android/ios etc. The package manager for android is going to differ a lot from the package manager for the web... I'll not go into much details here. I want to keep this discussion to clear out the naming confusion that I have.

Please answer the following questions:

1. Pick one between ftd and p-script. This subset deals with processors, user defined components, kernel-components, f-script interop and the p1 grammar. Every language detail except FFI i.e. f-script is addressed by this. Do we simply call this fastn and move on. Get rid of ftd? And use p-script only in our spec?
   I feel like calling it fastn is good enough. fastn is the one thing that you should care about! It is the language, it is the platform, it
   can be used to build/install/distribute packages, it can be used to render on web or ios or other targets.

2. What is f-script btw? foreign-script?

[amitu]

Pick one between ftd and p-script

I am generally fan of getting rid of ftd terminology. This is legacy, earlier we used to call it ftd language, and fpm: ftd package manager. This was a bit like Rust and Cargo or Python and PIP, but eventually I realise golang does it better, with the same name for both, and if you really ask me Rust vs Cargo is a meaningless distinction, it could as well have been rust build etc, the fact that it is not is not a feature, but a bug.

This is why we are using the fastn now for both language and tooling around it (fastn will even work like rustup, meaning it will install the right version of fastn eventually if your package indicates it needs a diff version of fastn than one installed right now).

Why do we have both fastn.package etc and ftd.row etc? Because earlier it was fpm.package and ftd.row. We renamed fpm to fastn first, and later merged the two. We want to get rid of ftd.* also, in favour of fastn.row etc.

What is f-script btw? foreign-script?

No. Check this discussion I created: intuition behind the p-script / f-script - fastn is better SGML should answer this question.

tldr: p-script is like HTML and f-script is like JavaScript (we do not have any CSS equivalent).

p-script because this is phase 1 of our compiler, and we did not have more phases, and went straight to interpreter, so p is for phase1, you can call it p1 script also.

f-script because this is the function body, or expression. The declaration of function itself is done in p-script, only the body is in f-script, and whatever is in body is a valid equivalent to a valid expression in Rust for example (expression in rust is what is part of a block, {}).

[siddhantk232]

f-script because this is the function body, or expression. The declaration of function itself is done in p-script, only the body is in f-script, and whatever is in body is a valid equivalent to a valid expression in Rust for example (expression in rust is what is part of a block, {}).

Interesting that you did not mention javascript because we currently support js expressions inside f-script. My impression was that f-script will be used to write native code (javascript for web, C# for windows apps etc), am I wrong to assume this?

[amitu]

f-script is currently very limited. It can call JavaScript function without any special syntax, but that may change. This of that as cffi of our language. It will tomorrow be able to call whatever host/target it is running against.

[amitu]

f-script tomorrow will become much more complex and that is part of 0.5, if then else, loops, local variable declarations etc.

We want f-script to largely resemble Rust, but we can take inspiration from TypeScript and other places as well.

[siddhantk232]

Got it! So f-script is also part of our language that we can't defer to some other language (rust or javascript). Tho, it is the only thing in fastn that'll have FFI capabilities so that it can call to other languages.

[amitu]

So f-script is also part of our language that we can't defer to some other language (rust or javascript).

Just to emphasise:

-- integer x: $x + $y

The part after : in this case is f-script, as that's the only thing that makes sense for an integer. Similarly:

-- ftd.text:
if: $x > 10

The part after if: is f-script. Similarly color: if $x > 10: red is f-script.

This causes problem tho.

In f-script do we use $x to refer to a variable, or just x?

-- integer foo(x, y):
integer x:
integer y:

$x + $y

Or

-- integer foo(x, y):
integer x:
integer y:

x + y

In this case, it seems x + y is better choice. But in -- integer z: x + y vs -- integer z: $x + $y, later feels "right".

Maybe we have three sub languages, p-script, f-script, and auto f-script, and auto f-script is used in -- integer z: $x + $y, but you can explicitly enter f-script mode using {}: -- integer z: { x + y }.

In case of function body, you are in f-script. In case of formal and conditionals (if: <condition> or <property> if <condition>: <value>, we are in auto f-script mode.