Plain Merge files will have the extension .mg
But there is a pending merge feature that allows you write language specific
code in a merge file. This will be done by adding a language extension to the
file name. For example, a merge file with python code in it will have the
extension .mg.py
Note
This is a work in progress and is subject to change Following snippet is using rust syntax highlighting which is not native but the closest to merge syntax
// A comment (MAY CHANGE TO A #)
#[
rust = {
main_only = true,
}
]
/// Following syntax may change in the future
/// The full syntax is:
///
/// [to_yeet] -> [to_suck]
/// lang! {
/// ...
/// }
-> [rust_result] // Means: suck the rust_result out!
rust! {
println!("[RUST]: START");
let rust_result = 0;
println!("[RUST]: END");
}
[rust_result] -> [c_suck] // Means: Yeet rust_result to the following lang! and suck the result to c_suck!
c! {
printf("[C]: START\n");
printf("[C]: %d\n", rust_result);
int c_result = 0;
printf("[C]: END\n");
}
Main challenge is type checking. Merge is a multi-language programming language and each language has its own type system. This means that the type checker needs to be able to type check multiple languages at the same time.
I'm planning to leave this to the user for now. And provide the utilities to make it easier to do so. (Which is probably going to get automated by the time)
Error handling is another challenge. Each language has its own error handling system. And the error handling system of the language that is being used to write the merge code is not necessarily the same as the error handling system of the language that is being used to write the code that is being merged.
I'm planning to use file-tree in a way that makes it easy to handle errors. (e.g putting every language call in a separate file and using the file name to) I can offset the merge block according to the file and block that caused the error.
Will inspire a lot from markdown syntax highlighting.
Firstly merge code will get seperated to a file tree. Then the yeets and sucks will get resolved. Then the code will get compiled to the target language. (with the build script if it's necessary)
Build scripts will get written inline (but for quick testing purposes, it's better to write them in a separate file). They will get compiled to the target language and then executed.
#[
rust = {
build = "rust/Cargo.toml",
}
c = {
build = "c/Makefile",
}
]
Saved for later (not essential for now)
Some languages are not standerdized. So I'm planning to use the build scripts to test the code. (if essential)
#[
c = {
test = {
dir = "c/tests",
test = "make test",
},
}
]
Same with testing (uses default if possible, else uses build script)
#[
c = {
doc = "make doc",
}
]
Saved for later (not essential for now)
Same as testing and documentation
#[
c = {
bench = "make bench",
}
]