ATS-Postiats VS DefinitelyTyped

This is one of my two favorite books in The Little ...er series. The other is The Rational Schemer. These are two of the most advanced books in the series.

The Little Typer provides an introduction to dependent types. These can by used to guarantee things like "applying 'concat' to a list of length X and list of length Y returns a list of X+Y". It is also possible, to some extent, to use dependent types to replace proof tools like Coq. Two interesting languages using dependent types are:

- Idris. This is basically "strict Haskell plus dependent types": https://www.idris-lang.org/)

- ATS. This is a complex systems-level language with dependent types: http://www.ats-lang.org/

The Rational Schemer shows how to build a Prolog-like logic language as a Scheme library. This is a very good introduction to logic programming and the implementation of backtracking and unification is fascinating.

This is an excellent series overall, but these two books are especially good for people who are interested in unusual programming language designs. I don't expect dependent types or logic programming to become widely-used in the next couple generations of mainstream languages, but they're still fascinating.

Not being ATS

> any safety checks put into the competing language will have a runtime cost, which often is unacceptable

This is completely wrong. The best counterexample is probably ATS http://www.ats-lang.org which is compatible with C, yet also features dependent types (allowing us to prove arbitrary statements about our programs, and check them at compile time) and linear type (allowing us to precisely track resource usage; similar to Rust)

A good example is http://ats-lang.sourceforge.net/DOCUMENT/ATS2CAIRO/HTML/c36.... which uses the Cairo graphics library, and ends with the following:

> It may seem that using cairo functions in ATS is nearly identical to using them in C (modulo syntatical difference). However, what happens at the level of typechecking in ATS is far more sophisticated than in C. In particular, linear types are assigned to cairo objects (such as contexts, surfaces, patterns, font faces, etc.) in ATS to allow them to be tracked statically, that is, at compile-time, preventing potential mismanagement of such objects. For instance, if the following line:

      val () = cairo_surface_destroy (sf) // a type error if omitted

For a low level language in which you actually need to prove that your code doesn't cause UB, see http://www.ats-lang.org/

Here's the homepage fo the language: http://www.ats-lang.org/. The trick to finding results about with google is to search "ATS programming language".

In SPARK's case, you have to state your invariants in even greater precision than in Rust, and naturally it has worse inference. That's okay, the same happens in a certain language with Atrocious Type Syntax.

Yes, things like mentioned in the post can be expressed and checked statically, as demonstrated by languages like Idris and ATS. ATS might be even more relevant as it's an imperative language too, it can get rather low-level (like talking about properties of C runtime functions) while proving required properties statically, and it includes a solver for certain amount of arithmetics so that you don't need to prove obvious mathematical identities to the compiler. http://www.ats-lang.org/

Prior to React 18, it used to include an implicit children prop, making it suitable for components expected to have children. For a long time, though, the implicit children prop type has been removed according to React 18's type changes.

Additionally, because TypeScript has a well established and widely used install-base, there are already many different definition files in the wild for supporting non-TypeScript supporting projects. One of the more extensive collections of these typings lives at the DefinitelyTyped repository, which publishes the package's community typings under the package names @types/your-package-name (where your-package-name is the name of the project you're looking for typings of) that you can look for on your package manager.

View on GitHub

Firefox maintain a library for unified extension API https://github.com/mozilla/webextension-polyfill

Their type definition for HAR request isn't exported https://github.com/DefinitelyTyped/DefinitelyTyped/blob/mast...

type NumberOrString = number | string; type Status = "idle" | "loading" | "success" | "failure" // React useState, can receive a value or a function as parameter to serve as initial value. // https://github.com/DefinitelyTyped/DefinitelyTyped/blob/a03856975a17eba524739676affbf70ac4078176/types/react/v17/index.d.ts#L920 function useState(initialState: S | (() => S)): [S, Dispatch>];

The TypeScript pull request was merged, so Sebastian (who helps maintain the React type definitions) exercised new powers in this pull request to the DefinitelyTyped repository for the React type definitions. At the time of writing, this pull request is still open, but once merged and shipped the React community we will feel its benefits.

there is an open issue: https://github.com/DefinitelyTyped/DefinitelyTyped/issues/61616

Relatively infrequently. Normally, if an npm package is popular and doesn’t have its own types, there will be a community provided types declaration file available from https://github.com/DefinitelyTyped/DefinitelyTyped