Goals for v0.1

[mjarkk]

Now we are making some good progress it might be a good idea to add checkboxes to the readme for all the things we want for the v0.1 release.
I guess we should start with a v0.1 because we only have support for 1 target language.

Some things i think we should definitely have:

• A cli that can compile .tp into .js
• Imports working correctly
• Support all features in JS

[TheOtterlord]

Now we are making some good progress it might be a good idea to add checkboxes to the readme for all the things we want for the v0.1 release.

Yeah, once we have a list of things to complete before v0.1.0 we should probably store it in the README or in a ROADMAP file.

I guess we should start with a v0.1 because we only have support for 1 target language.

Yeah, although I think we should try and support at least one lower level language before v0.1.0.

Here are a few things to consider

• Full documentation and examples
• A get started tutorial?
• Command line arguments (like run and build along with tags like --debug)

We will have to also come up with an installer of sorts.

[mjarkk]

Yeah, although I think we should try and support at least one lower level language before v0.1.0.

That might be a good idea to actually show of what the point of this programming language is :)
I would really like to support rust but that's a complicated language so it might be more handy to start with something less strict like C, C++ or Go.
I have almost no experience with C nor C++, but a lot with go so might be worth supporting Go as second language??

Command line arguments (like run and build along with tags like --debug)

I'm not sure how run should work though?

We will have to also come up with an installer of sorts.

I think we should start with publishing this on crates.io so people can just install this by running:

cargo install talpalang
# or
cargo install talpa

(cargo install compiles a binary from source to ~/.cargo/bin/)
We could use that for now as it's supper easy to use, and beside that we could also add the binaries for every platform in the github releases.
A lot of other rust programs also do this like bat.

[mjarkk]

Also i think we should start thinking about how a "talpa" project should look like.
Like in rust everything needs to be inside the src folder or in go you need to have a main package with a main function.

If we want to keep things simple i think we should have something like a talpa project folder with the talpa files and a target folder we compile to using something like > talpa build --JS talpa_files target though this is a long command.

Because we compile into many languages i think most people would like to separate this code base from the rest of the code so most people will put talpa code in a separate git folder.
This also gives us the possiblity to allow building something directly from a repo using:

> talpa build --JS git@github.com:talpalang/talpa.git target

but again this is a really long command.

Like many other languages we could maybe also add some sort of config to the target like:

# Talpa.toml
[package]
location = "github.com/talpalang/talpa"
lang = "js"
version = "v2.1.0"

This way we can just do something like talpa build and the code will be fetched and build into this dir (somewhat like the cargo package manager does with dependencies).

[TheOtterlord]

I have almost no experience with C nor C++, but a lot with go so might be worth supporting Go as second language??

Go could work for a second language as it does compile into a binary. As we are going to eventually need support for C/C++ I am going to try and learn a bit in my spare time.

I'm not sure how run should work though?

I imagine that in the language support library, we would include an option for extra-build commands (such as gcc or other compilers) and run commands (call main.exe for binaries. Run Node.js for javascript?) and if no run commands are specified, the compiler will print out a message to let the user know after compilation.

I think we should start with publishing this on crates.io

Yeah, I guess it provides a nice installation. I would want to look for other options in the future to remove cargo as a dependancy.

Also i think we should start thinking about how a "talpa" project should look like

There are a few ways of doing this. You could go with a loose layout where it just compiles main.tp in the current directory or the specified file in the cli args. You can also have a manifest file like Cargo.toml, package.json or pubspec.yaml. I think the manifest would be better as it allows for more customisation and can help to shorten build commands.

If we want to keep things simple i think we should have something like a talpa project folder with the talpa files and a target folder we compile to using something like > talpa build --JS talpa_files target though this is a long command.

I think something like talpa build with the manifest telling the compiler the target and the language (these could be overidden with command line args if required).

Because we compile into many languages i think most people would like to separate this code base from the rest of the code so most people will put talpa code in a separate git folder.
This also gives us the possiblity to allow building something directly from a repo using:

I like this idea a lot. It would also help us when we start building Talpa example libraries.

Like many other languages we could maybe also add some sort of config to the target

Like I state above, something like a yaml or json file would be great. Personally, I think that to avoid dependancies we should code a simple yaml like language that only implements what we need. It would then be smaller and more reliable that using a dependancy.

Something like this could work:

[package]
name = "hello-world" # package name
version = "0.1.0" # version of package
target = "src/" # target file defaults to main.tp but "src/start.tp" could also be a valid argument
output = "debug/js/" # output folder
lang = "js" # target language

[dependancies]
math = "https://github.com/talpalang/mathlib" # could maybe target .git file instead?

You would then run talpa build.

If we used JSON with a similar format to NodeJS, we could let the user define their own build commands such as talpa build-js.

[TheOtterlord]

Quick note.
Maybe we should use a task list in your first comment to keep track of all the things we want for v0.1.0 and we can tick them off as they are completed?

EDIT: Actually I noticed this. It seems you've closed it, but I think that it could be a good alternative to the task list. What do you think?

[mjarkk]

Ya i was trying some things out but closed it because we already had the todo list in the readme.
Though using those tasks lists would mabye be a bit more orgenized.

[mjarkk]

I've filled the tasks list with things we need to do for v0.1.0.

About the configuration file..
So we have 2 things:

1. A repo with talpa code
2. A target folder where the code from the repo needs to be compiled into

For the repo with talpa code i prefer not to have a configuration file but i think we eventually probably need to if we want to do dependencies properly.
I don't like configuration files because they per definition make things more complicated and adds one extra thing you need to understand or in the case of the package.json from nodejs a lot of things you will need to understand.
I'm personally oke with that if it adds more value than not having it like with dependencies, GoLang at first had the dependencies in the code but now they also have a dependencies file because it only caused complication for large projects.

In npm the "scripts" seem to me to show it's biggest problem as you have so many tools like bundlers, compilers, transpilers, etc.. you just need a custom command runner by default. nowadays you almost always use something in between of the thing you want to run and the package.json file this not only makes things more complicated because of the extra programs involved here not even talking about the fact it can execute executables from the devDependencies but also because you need to know the tool used in between that seem to change every 2 years.
As you can see i'm not a big fan of the javascript ecosystem it's all just so complicated because it was not designed to be this way.

Talking about things that are designed to be used this way, Cargo.. rusts it's package manager.
every cargo command is simple and you almost directly if not directly know what they do it's that simple there are no wired quirks and almost everything explains itself.
The packages are very easy to understand and don't cause a gigantic node_modules folder in every project.
So i propose this config file in the repo with talpa code (but it's not require to have for now at least):

# Talpa.toml
[dependancies]
math = "talpalang/mathlib" # shotcut for: github.com/talpalang/mathlib
math = "github.com/talpalang/mathlib" # Imports from a specific repo

Now about the target.
Lets say we we have a empty folder we want to compile our talpa code into.
As described earlier i think we should also use a configuration file and i think we should also specify the same logic here as above here things should be simple.

# Talpa.toml
[package]
location = "github.com/talpalang/talpa"
lang = "js"
version = "v2.1.0"

Using this config it's very clear to an user what talpa does when you run talpa build, it fetches the code from the location and compiles it into lang and the version it uses is also clear

[TheOtterlord]

Yeah, I think a toml like configuration built into Talpa would make the most sense. I would like to avoid using a prebuilt package as I think we should avoid dependencies completely. Also cargo & crates.io have so many issues and I can't even get crates.io to work on either of my computers. It would not be to hard to build a config support like toml.

Also, we may want to consider the ability to compile into multiple languages from the start. Even though we only support one so far, in the future people may wish to compile into several languages.

[mjarkk]

Also cargo & crates.io have so many issues and I can't even get crates.io to work on either of my computers

Wired.. it works perfectly everywhere where i've installed rust via https://www.rust-lang.org/tools/install

Also, we may want to consider the ability to compile into multiple languages from the start. Even though we only support one so far, in the future people may wish to compile into several languages.

Yes true.
But we should not let the configuration specific multiple targets.
If users want to do such things they can create a folder structure like this:

js/
  Talpa.toml
swift/
  Talpa.toml
go/
  Talpa.toml
rust/
  Talpa.toml

and it can be all these using something like:

talpa build ./*

[TheOtterlord]

Wired.. it works perfectly everywhere where i've installed rust via https://www.rust-lang.org/tools/install

Yeah, I keep getting errors when it updates the index, I've tried half a dozen solutions but nothing works. I even tried a fresh install on another computer and that also failed.

If users want to do such things they can create a folder structure like this

Yeah, that looks good.

[TheOtterlord]

Maybe we should create an example repository that contains a working talpa project?
This could help to better visualise what a talpa project looks like.

[mjarkk]

We should probably have that!
But maybe we should postpone that a bit until the CLI supports import and compiling into a target dir.

[TheOtterlord]

Yeah, that makes sense

[TheOtterlord]

By the way, I was about to start adding support for Go, but I can't access a return type.

Has this been implemented yet or am I getting ahead?

[mjarkk]

Return type should be implemented it might be though that the struct / fields are private.

[TheOtterlord]

Ok, thanks. I’ll have a look :-)

[TheOtterlord]

Looking at lines 8-12 in function.rs I can't see a variable for return type. Could it be located elsewhere?

 8: pub struct Function {
 9:   pub name: Option<String>,
10:   pub args: Vec<(String, Type)>,
11:   pub body: Actions,
12: }

[mjarkk]

This return type you mean right?
https://github.com/talpalang/talpa/blob/master/src/compiler/tokenize/action.rs#L56

For the struct itself it's located here:
https://github.com/talpalang/talpa/blob/master/src/compiler/tokenize/action.rs#L89

[TheOtterlord]

Not quite. I mean the type of the data returned by a function. The bit between the arguments and the scope.

fn do_something() RETURN_TYPE {
}

[mjarkk]

Oh you mean that..
That indeeds seems to be missing,
I'll fix it today :)

[TheOtterlord]

Great.

I've began work on Go support in the golang branch. I figure it's best to keep it seperate until it has a good enough support and passes all checks.