Since I have e2e tests, I only use the agent for: guiding it on how to write the e2e test ("use tmux to try the new UI and then write a test") or to evaluate its overall usability (fake user testing, before actual user testing): "use tmux to evaluate the feature X and compile a list of usability issues"

I'm building an alternative, and I haven't opened emacs for a month now

I'm building Fresh [0] [1] as an alternative to VSCode that runs in your terminal, with the main goal being ease-of-use out of the box (not a vi-clone modal editor), for example supports mouse, menu, command palette, etc out of the box. LSP as well. I'm focused on making it easy to use with minimum or zero configuration.

[0] https://github.com/sinelaw/fresh [1] https://sinelaw.github.io/fresh/

Also, recently I found out just how expensive (runtime-wise) it is to host a full-blown TypeScript host, such as Deno. This is very cool tech but kind of bloated when all you want is to run some JavaScript, e.g. as a plugin system. It's possible to just pre-compile (transpile) your .ts files and then ship only the JavaScript output and use a lightweight runtime (QuickJS or even the new Micro QuickJS), but then compilation becomes a neccessary step for what could've been purely dynamic, ad-hoc and quick plugins (think elisp in emacs).

minfern is my second shot at this, and I'm exploring just how much JavaScript idioms are "must have" for it to be useful.

Try it online at: https://sinelaw.github.io/minfern/

It could be used for checking code targeting normal JS runtimes, or runtimes like mquickjs (though minfern is more strict but also allows things like ‘const’ which mquickjs doesn’t). minfern is based on the type system for Infernu, which I wrote back in 2015, but is less hacky and has a cleaner implementation.

Very simple example:

  function calculateTotal(product, quantity) {
    return product.price * quantity;
  }
  var item = {
    name: "Wireless Mouse",
    cost: 25 // Note the property name is 'cost', not 'price'
  };
  console.log(calculateTotal(item, 2));

  Error: Property 'price' not found in type {cost: Number, name: String}
      ╭─[ tests/example_error.js:11:13 ]
      │
   11 │ console.log(calculateTotal(item, 2));
      │             ───────────┬───────────  
      │                        ╰───────────── Property 'price' not found in type {cost: Number, name: String}
  ────╯

- Full type inference with principle typing, support for type annotations

- Parameteric polymorphism (aka “generic functions”)

- Structural typing with row-type polymorphism

- Object method typing with equi-recursive types (for self/“this”)

- Polymorphic object methods (still considered rank-1)

- Basic constraints “Plus a” and “Indexable a” to allow + and [] to apply to different types like numbers, strings, arrays.

This allows a subset of JS expressions to be checked.

Some JS idioms are not allowed by this system:

- No union types (design choice) - return values, variables, arrays, etc must have a single type. Currently it doesn’t support returning null/undefined either, this can be fixed in the future by adding Optional as a type, but makes principle typing harder.

- No sum types (yet) - this explains why I haven’t added Optional, I think sum types will fit in the type system and are doable. Once added also enums could be expressed.

- Value restriction forbids reassigning to polymorphic variables after declaration (ML-style).

- As a result of the above - can’t use && / || operators like some people do in JS. The operators are required to have the same type on both sides (no allowing “undefined” on one side)

- No type coercion, converting a number to a string (for example) requires using String() constructor.

- And probably other limitations that people might see as a limitation rather than a feature of the type system.

Disclaimer: this type checker comes with NO WARRANTY. I am not a language expert. I didn’t prove soundness, and would love someone who’s an expert to look at it. That being said - it looks correct on all the tests I’ve tried. It’s based on HMF and other published type systems but combines things in a different way.

GitHub: https://github.com/sinelaw/minfern

Comments URL: https://news.ycombinator.com/item?id=46410720

Points: 2

# Comments: 1

no ansi color rendering

- Homebrew (MacOS)

- Arch Linux AUR

- Debian/Ubuntu .deb

- Fedora/RHEL .rpm

as well as cargo install (which builds from source), npm, npx or building from source by cloning

I hate it, and I'll keep working on reducing it

Tree-sitter is supported and used internally for a subset of languages for syntax highlighting (other languages use textmate grammars). What exactly do you mean by support for tree-sitter parsers?

I wasn't aware of Debug Adapter Protocol! I'll take a look at that.