whistle-lang/whistle

🕴 One hella programming language

whistle's Issues

Better errors and error handling

Related to #16. Our errors should be a standardized, numbered and give a tip to how to fix the error along with a nice message like that of rust. We should also have different error ranges depending on if the error is a lexer, parser, compiler, type or other error.

Proposal to add a fun currying syntax for nested function calls

This is an quite old idea but it would essentially allow for a function to be called in multiple different stages before finally executing:

fn bake_a_cake(first: str)(second: i32)(third: bool): str {
  // function body goes here
}

It could then be called like:

val first: fn((second: i32)(third: bool): str) = bake_a_cake("add something")
val final: str = first(123)(false)

This would probably require an auto or automatically inferred type along with a fn type for function references.

Integrate wasm-opt

Optionally integrating wasm-opt would allow us to create even smaller and faster code, without having to write our own optimizer.

Proposal to add conditional parameters to functions

Conditional parameters, while only syntax sugar would be a cool way of doing different things when the input of the function is different. I am undecided on wheter this is a good idea as it is just syntax sugur and would complicate things like compilation and type checking but its a cool idea at least:

// recursively calculate the factorial of n
fn fac(n: u64): u64 {
  return n * fac(n - 1)
}

// when parameter n is 1 call this function instead
fn fac(n: u64 == 1): u64 {
  return 1
}

The above code would be equivalent to, and while not in this case shorter it is in some ways more readable (and in some ways not):

fn fac(n: u64): u64 {
  if n == 1 {
    return 1
  }

  return n * fac(n - 1)
}

A manifest format and file

Probably using toml, or perhaps as a part of the entry file of a Whistle program?

Standardized parser and error handling

It's in the title, should be part of the spec

A formatter/linter and style guide

A simple formatter and linter, like clippy using the whistle lexer, parser and AST would be nice to have. In my opinion it should be opinionated, and be able to also only check for formatting errors instead of always fixing them. Along with the formatter we should also provide a standard style guide.

Here's my proposal for a minimal style guide we can start with:

• 2 spaces instead of tabs
• snake_case for everything but types which should be PascalCase
• docs should always start with ///

Inline functions

Proposal to add inline functions using the inline keyword:

export inline fn test_inline(a: i32): u32 {
  return a as u32
}

This would most likely be implement by adding another field to the Compiler struct which contains the instructions for each registered inline function. This is useful for things like std/math, and other high performance, or small tasks where a function call is not desired.

An opinionated package manager and registry

Will require some standardized syntax for imports and also #18.

Tips and inline wasm

The language should be extendable using "compiler tips" which are essentially macros, or simply put: compiler tips. These tips would be modularly implemented using an rust interface of some sort, keyed by the tip type as specified by identifier between the parenthesis of the tip: #(wasm). Tips are specified to be able to be single or multi-line depending if the body is surrounded by squiggly parenthesis.

These tips are implemented in rust as taking the body of the tip as raw text and could for example take wasm text format and convert its body to instructions. This would allow for unsafe, but greatly more powerful code much like the rust asm macro.

Broken website link

https://whistle.deno.com/ doesn't exist. Should it be https://whistle.deno.dev/ instead?