Roadmap & Ideas

[ovr]

General

StaticScript language should be compatibility with TypeScript as it possible but with additional features

• 90%+ of TS programs must be able to be compiled by ssc (to executable)
• SS programs without additiona features from statiscript must be able to be compiled by tsc (to js)

JS Types:

• [X] Number (double)
• [X] String (C string?)
• [X] Boolean (i1)
• [ ] Undefined
• [ ] Null
• [ ] Object

Statements:

• [ ] Yields /generators will be done by https://llvm.org/docs/Coroutines.html
• [ ] Try/catch - https://llvm.org/docs/ExceptionHandling.html

Tooling:

• [ ] Language server, similar to typescript language server
• [ ] Debug - https://llvm.org/docs/SourceLevelDebugging.html

Objects and classes

There will be two types of objects:

Static object

It's not possible to mutate (add/drop fields from this objects), object are structures that mapped directly to memory and methods are functions with pointer to structure (this)

Dynamic objects

Unoptimized objects that will be V8 objects

Feel free to add ideas by comments

Advanced features of StaticScript

Types:

• [ ] int8/int16/int32/int64/int128
• [ ] uint8/uint16/uint32/uint64/uint128
• [ ] float32/float64 (alias to number)/float128

To implement it, we need to use own fork of TypeScript (https://github.com/static-script/TypeScript) and implement base support inside Frontend part

Own standart library:

Implement standart library on StaticScrtipt

This issue will be updated when new ideas will come :)

[ghost]

Great job ovr, I'm looking forward to this project.

[lantos1618]

Cool project. Have you any ideas on how you're going to implement Async/await? also add dependency list cmake, make, llvm version...

[rishavs]

Will npm be used for project management? can we have ssc invokable by npx?

[aiko-is-bored]

Hello! I've actually a few ideas and wanted to rewrite an implementation of this project from scratch.

1. Undefined: Just another way of saying null.

2. Null: Use LLVM's getNull for floats. Every "Number" is just a floating point in LLVM. Strings are just just string-primitive as an object. Objects are the real kicker here.

3. Objects: Use a dictionary-like structure. We can implement hash-tables easily. Simply put, we store strings, etc, in a hash table. This allows for easy, fast access in non-class objects, and even easier sharing. For example, console.log tells the compiler to find console, and then grab the hashed log element. We can easily extend the c-like string primitives as an object. But, it doesn't have to be that hard. Instead, we can just create a Java or C++ like class, and implement the new keyword found here: https://mapping-high-level-constructs-to-llvm-ir.readthedocs.io/en/latest/object-oriented-constructs/index.html

There are a few reworks I'm looking for here. The first one is the console_log. We want to have said support for the following things:

• Modules

• Import/Export

• Compiler Modules

• Easy extensibility by adding new module folders in the pkg/modules section.

This will make programming and our life a lot easier. My idea for this is to make the modules like Go-ish.

import 'io'

function helloWorld(): Undefined {
   io.log("Hello world!") // <- or console.log("Hello world!")
}

helloWorld();

This allows for better, easier code. We also would want an args lib, preferably one with a default parsing algorithm, which is very possible. Check out https://godbolt.org/ to help. Try using C or C++ to get an array of arguments.

[aiko-is-bored]

Also, by default, functions should be LLVM's void.

[hinell]

@aiko-is-bored I think it's generally bad idea to reinvent the wheel. Only if you want to do it just for fun.