LISH
...probably stands for lisp-like-shell or list-shell or something.
Introduction
I like lisp/scheme syntax, i like bash, i like procedural programming. However, i do not like how difficult it is to write slightly more advanced scripts in bash. Hence this project.
This is a transpiler for a lisp/scheme syntax procedural programming language to bash. It has several features which make the usage of this language more pleasant than writing bash, like type checking during compilation, no implicit conversions, better array handling, additional verifications here and there and so on.
This aimes to output somewhat readable bash code that preserves the file structure of the input code. This means, that when possible the variable and function names you declare in lish will be used in the output bash code. Also all autogenerated varialbes (which are really required in bash sometimes) will get somewhat meaninful names.
Preserving the file strucutre really means, that the output bash scripts will have to same names like the input lish files but with the .sh ending and the folders you create will be created in the output directory.
Hope you like it, give me feedback :)
References
Check out the code on github
Using the compiler
currently the only option the compiler supports is compile . This expects an path (relative or absolute) to the entrypoint file and an output directory path.
lish compile ./path/to/entrypoint/main.lish --out=./path/to/outputdirFeatures
| Summary | Description | Status |
|---|---|---|
| Typesafety | Checks for types. Types can (and then must) only be provided where the compiler is not always able to infer the type by itself. E.g. array creation or when defining functions. | stable |
| Block scope emulation | Within functions, conditions and if statments proper scoping is emulated. This might lead to more compile errors when you try to use variables inside this scope and outside, because in the resulting bash code, this does not work. | unstable |
| Importing | Imports work only via individual symbols. You must import every function or value separately. The resulting bash code will only have one 'source' statement. Also variables are imported immutable. | stable |
| Better arrays | More intuitive array creation and usage. Including out of bounds checks and passing arrays to functions or returning them from functions. | stable |
| Program calls | You can call every program as you would do in bash by just calling the '$' function. The result is always returned as a string (might change in the future) | incomplete & unstable |
| Tables | Structured data. | not yet implemented |
basics
There are a few syntax and evaluation rules worth being explained before you go to the api docs and start coding
expressions look like this (functionName args ...). You can also use {} or [] brackets. It does not matter, as long as the open bracket matches the closing bracket
types are denoted like this #typename . For container types like arrays, you must use the type brackets < > e.g. like this: <#array #int>
symbols/names symbols i.e. names for variables, constants or functions must be valid bash names for these things. I.e. they must satisfy the regular expression [a-zA-Z][a-zA-Z0-9_]*[a-zA-Z0-9] . Also they cannot start or end with an underscore or have two underscores directly next to each other.
function returns a function always returns the last value in its body. This is also the value used for verifying a match with the return type.
If the functions return type is #void, then nothing is returned and the last expression is not verified against the return type.
importing requires relative path from the current file. That means, to import a function from another file from the entrypoint file, you have to provide a relative path from the entrypoint file to the file you want to import the function from