TypeScript:
/**
* This Fetch API interface allows you to perform various actions on HTTP
* request and response headers. These actions include retrieving, setting,
* adding to, and removing. A Headers object has an associated header list,
* which is initially empty and consists of zero or more name and value
* pairs.
*
* You can add to this using methods like append()
The purpose of this proposal is to outline a design for handling bindings in ReScript that is safe and easy to use. Bindings are an important aspect of ReScript, as they allow developers to use external JavaScript code and libraries in their ReScript projects.
Currently, ReScript provides several ways to handle bindings, including using the @module annotation and the %raw syntax. While these methods work well, they can be complex and error-prone, especially when dealing with large and complex external libraries.
In this document, we will explore two alternatives for handling bindings in ReScript without using import. The first approach combines the @module and %raw annotations, while the second approach utilizes a single @module annotation for more concise and straightforward code.
|: instead of |. For example, type someType = A |: B |: C(string, string).type list<'a> = undefined |: {tag:"Cons", _0: 'a, _1: list<'a>}.type either<'a, 'b> = Either('a) |: Or('b). This allows for more expressive types and greater flexibility in the type
We present a program analysis motivated by the need to solve some termination problems observed during the development of a parser for the new syntax introduced with the ReScript language. Learning from previous experience, it was decided to avoid parser generators, and go instead for a hand-crafted parser. In this way, the parser could be optimized for performance, be more maintainable, and most importantly give much more flexibility with error messages.
The new parser delivered on the promises, though a new issue appeared during live testing. The laptop would get hot once in a while, and only improve after re-starting the editor. Not all the time, but often enough to notice. The problem was an infinite loop in the parser, triggered by unexpected character combinations introduced while editing and never encountered in automated tests. It took a while to reproduce the issue and locate a mistake in the p
| Warning Dead Value With Side Effects | |
| whole_compiler.ml 2173:7 | |
| Numbers.Int16.+lower_int64 is never used and could have side effects | |
| <-- line 2173 | |
| let lower_int64 = Int64.neg (Int64.shift_left Int64.one 15) [@@dead "Numbers.Int16.+lower_int64"] | |
| Warning Dead Value With Side Effects | |
| whole_compiler.ml 2174:7 | |
| Numbers.Int16.+upper_int64 is never used and could have side effects |
| module M : sig end = | |
| struct | |
| let x0 = fun _ -> [0] | |
| let x1 = fun _ -> [1] | |
| let x2 = fun _ -> [2] | |
| let x3 = fun _ -> [3] | |
| let x4 = fun _ -> [4] | |
| let x5 = fun _ -> [5] | |
| let x6 = fun _ -> [6] | |
| let x7 = fun _ -> [7] |
| $ Blacklist=test ../node_modules/.bin/gentype -dce-cmt . | |
| Warning Dead Analysis Cycle | |
| stdlib-406/lexing.mli | |
| Results for stdlib-406/lexing.mli could be inaccurate because of circular references | |
| Warning Dead Analysis Cycle | |
| stdlib-406/pervasives.mli | |
| Results for stdlib-406/pervasives.mli could be inaccurate because of circular references |
| and parseInt = (p: Parser.t) => { | |
| let res = | |
| switch (p.token) { | |
| | Int(n) => n | |
| | _ => | |
| Parser.err(p, "integer expected"); | |
| (-1); | |
| }; | |
| Parser.next(p); | |
| res; |