Fix bullet points

Apparently having new lines between points count as new bullets

Author: chenglou

docs/build-advanced.md

@@ -10,7 +10,6 @@ You might use some pre-processor to generate boilerplate code during development
 **Note**: pre-processors can be classified as two categories:
 
 - System-dependent, which should be delayed until running on user machines.
-
 - System-independent: lex, yacc, m4, re2c, etc, which can be executed any time.
 
 BS has built in support for [conditional compilation](conditional-compilation.md), which satisfies the first point. This section is about the second point.

docs/build-configuration.md

@@ -96,7 +96,6 @@ Output to either CommonJS, ES6 modules or AMD. Example:
 ```
 
 - `"module": "es6-global"` resolves `node_modules` using relative paths. Good for development-time usage of ES6 in conjunction with browsers like Safari and Firefox that support ES6 modules today. No more dev-time bundling!
-
 - `"in-source": true` generates output alongside source files, instead of by default isolating them into `lib/js`. The output directory is otherwise not configurable.
 
 ### suffix

docs/build-performance.md

@@ -39,9 +39,7 @@ We've stress-tested bsb on a big project of 10,000 files (100 directories with 1
 <!-- TODO: better repro -->
 
 - No-op build of 10k files: `440ms` (unfortunately, that's the minimum amount of time required to check the mtimes of 10k files. But maybe we can cleverly optimize this in the future).
-
 - Clean build: 5 minutes.
-
 - Incremental build: depends on the file, but should be under `1s` unless it has lots of dependents.
 
 ## Incrementality
@@ -61,9 +59,7 @@ OCaml/BuckleScript/Reason uses the concept of interface files (`.mli` or `.rei`)
 Unfortunately, JS build systems are usually the bottleneck for building a JS project nowadays. Having part of the build finishes blazingly fast doesn't matter much if the rest of the build takes seconds or literally minutes. Here are a few suggestions:
 
 - Convert more files into BuckleScript/Reason =). Fewer files going through fewer parts of the JS pipeline helps a ton.
-
 - Careful with bringing in more dependencies: libraries, syntax transforms, build step loaders, etc. The bulk of these dragging down the editing & building experience might out-weight the API benefits they provide.
-
 - Wait for us to create our own super fast linker (aka bundler).
 
 ## Hot Reloading

docs/community.md

@@ -8,5 +8,4 @@ BuckleScript and [Reason](https://reasonml.github.io/) are sister projects. The
 Come say hi!
 
 - [Discord](https://discord.gg/reasonml)
-
 - [Stack Overflow](http://stackoverflow.com/questions/tagged/bucklescript)

docs/comparison-to-jsoo.md

@@ -8,9 +8,7 @@ Js_of_ocaml is a popular compiler which compiles OCaml’s bytecode into JavaScr
 However, there are a few areas that BuckleScript approaches differently:
 
 - Js_of_ocaml takes low-level bytecode from OCaml compiler, BuckleScript takes the high-level rawlambda representation from OCaml compiler.
-
 - Js_of_ocaml focuses more on existing OCaml ecosystem (OPAM) while BuckleScript’s major goal is to target NPM/Yarn and existing JS workflows.
-
 - Js_of_ocaml and BuckleScript have slightly different runtime encoding in several places. For example, BuckleScript encodes OCaml Array as JS Array while js_of_ocaml requires its index 0 to be of value 0.
 
 See also the [What & Why](what-why.md) page for more info on BuckleScript's emphasis.

docs/conditional-compilation.md

@@ -10,7 +10,6 @@ People used to use preprocessors like [C preprocessor](http://tigcc.ticalc.org/d
 Instead of a preprocessor, BuckleScript adds language-level static `if` compilation. It's less powerful than other preprocessors since it only supports static `if` (no `#define`, `#undefine`, `#include`), but there are several advantages.
 
 - It’s tiny (only ~500 lines) and highly efficient. Everything can be done in a **single pass**. It's easy to rebuild the pre-processor into a standalone file, with no dependencies on compiler libs, to back-port it to old OCaml compilers.
-
 - It’s purely functional and type-safe, and cooperates with editor tooling like Merlin.
 
 **Note**: BuckleScript's conditional compilation doesn't work with Reason yet.
@@ -104,13 +103,9 @@ atom
 ## Typing Rules
 
 - type of INT is `int`
-
 - type of STRING is `string`
-
 - type of FLOAT is `float`
-
 - value of UIDENT comes from either built-in values (with documented types) or an environment variable, if it is literally `true`, `false` then it is `bool`, else if it is parsable by `int_of_string` then it is of type int, else if it is parsable by `float_of_string` then it is float, otherwise it would be string
-
 - In `lhs operator rhs`, `lhs` and `rhs` are always the same type and return boolean. `=~` is a semantic version operator which requires both sides to be string.
 
 Evaluation rules are obvious. `=~` respect semantic version, for example, the underlying engine

docs/difference-from-native-ocaml.md

@@ -26,9 +26,7 @@ OCaml’s weak map is not available in BuckleScript. The weak pointer is replace
 OCaml has `int`, `int32`, `nativeint` and `int64` types.
 
 - Both `int32` and `int64` in BuckleScript have the exact same semantics as OCaml.
-
 - `int` in BuckleScript is the same as `int32` while in OCaml it’s platform dependent.
-
 - `nativeint` is treated as JavaScript float, except for division. For example, `Nativeint.div a b` will be translated into `a / b | 0`.
 
 **Note**: `Nativeint.shift_right_logical x 0` is different from `Int32.shift_right_local x 0`. The former is literally translated into `x >>> 0` (translated into an unsigned int), while the latter is `x | 0`.

docs/function.md

@@ -272,7 +272,6 @@ Fs.readFileSync("xx.txt", "ascii");
 ```
 
 - Attaching `[@bs.string]` to the whole poly variant type makes its constructor compile to a string of the same name.
-
 - Attaching a `[@bs.as "foo"]` to a constructor lets you customize the final string.
 
 And now, passing something like `"myOwnUnicode"` or other variant constructor names to `readFileSync` would correctly error.
@@ -500,9 +499,7 @@ This is an uncurried bucklescript function. It must be applied with [@bs].
 The above solution is safe, guaranteed, and performant, but sometimes visually a little burdensome. We provide an alternative solution if:
 
 - you're binding with `external`
-
 - the `external` function takes in an argument that's another function
-
 - you want the user not to need to annotate the call sites with `[@bs]`
 
 <!-- TODO: is this up-to-date info? -->

docs/generate-converters-accessors.md

@@ -30,9 +30,7 @@ type action =
 Variants constructors with payloads generate functions, payload-less constructors generate plain integers. **Note**:
 
 - The generated accessors are lower-cased.
-
 - You can now use these helpers on the JavaScript side! But don't rely on their actual values please.
-
 - Doesn't work with polymorphic variants yet.
 
 Output:
@@ -66,7 +64,6 @@ let s = submit("hello"); /* gives Submit("hello") */
 This is useful:
 
 - When you're passing the accessor function as a higher-order function (which plain variant constructors aren't).
-
 - When you'd like the JS side to use these values & functions opaquely and pass you back a variant constructor (since JS has no such thing).
 
 ## Convert Between `Js.t` Object and Record

docs/interop-with-js-build-systems.md

@@ -12,11 +12,8 @@ The JS ecosystem uses a few build systems: [browserify](http://browserify.org/),
 BuckleScript and bsb only take care of the compilation step; it maps one ml/re/mli/rei file into one JS output file. As such, in theory, no build system integration is needed from our side. From e.g. the webpack watcher's perspective, the JS files BuckleScript generates are almost equivalent to your hand-written JS files. We also recommend that you initially check in those BS-generated JS files, as this workflow means:
 
 - You can introduce BuckleScript and/or Reason silently into your codebase without disturbing existing build infra.
-
 - You have a visual diff of the performance & correctness of your JS file when you update the ml/re files and the JS artifacts change.
-
 - You can let teammates hot-patch the JS files in emergency situations, without needing to first start learning BS/Reason.
-
 - You can remove BuckleScript and Reason completely from your codebase and things will still work (in case your company decides to stop using us for whatever reason).
 
 The slight disavantage of such approach is that you need to keep both a bsb watcher and a webpack watcher open. Though if you activate [VSCode-Reasonml's bsb feature](https://github.com/reasonml-editor/vscode-reasonml#bsb), you avoid the former rather seamlessly.
@@ -40,7 +37,6 @@ You can make BS JS files look even more idiomatic through the in-source + bs suf
 This will:
 
 - Generate the JS files alongside your BS source files.
-
 - Use the file extension `.bs.js`, so that you can require these files on the JS side through `require('./MyFile.bs')`, without needing a loader.
 
 ## Use Loaders on BS Side

docs/object.md

@@ -12,9 +12,7 @@ BS splits the many overloaded usage of JS objects into distinct categories, for
 Up until recently, where JS finally got proper Map support, objects have been used as a map. The characteristics of object-as-map are the following:
 
 - contains values that are all of the same type
-
 - might or might not add/remove arbitrary keys
-
 - might or might not be accessed using a dynamic/computed key
 
 If these points (especially the first one) describe your object usage, then look no further than using the [`Js.Dict`](https://bucklescript.github.io/bucklescript/api/Js.Dict.html) API! This is a thin layer of binding we've made for such situation. Under the hood, a `Js.Dict` is just an object, and the bindings are compiled away. No performance cost. Actually, **better** than no perf cost! See the Design Decisions below.
@@ -26,7 +24,6 @@ In this mode, you can do all the metaprogramming you're used to with JS objects:
 If your object:
 
 - has a known number of fields
-
 - might or might not contain values of heterogeneous types
 
 Then you're really using it like a "record" in most languages. For example, think of the difference of use-case and intent between the object `{name: "John", age: 10, job: "CEO"}` and `{"John": 10, "Allison": 20, "Jimmy": 15}`.
@@ -287,9 +284,7 @@ If you don't want to work with `Js.t` objects and want to use idiomatic OCaml/Re
 When The two above modes of binding to objects fail, you can always fall back to this one. And sometimes this the **preferable** way of binding to objects, because it:
 
 - deals with objects with potentially arbitrary shapes
-
 - allows heterogeneous values
-
 - allows hyphen in object keys
 
 ```ocaml

docs/try.md renamed to docs/playground.md

@@ -1,6 +1,6 @@
 ---
-id: try
-title: Try
+id: playground
+title: Playground
 ---
 
 You can try BuckleScript with both the OCaml and Reason syntax displayed side-by-side, with live JS output, in the [Reason Try page](https://reasonml.github.io/try/).

docs/roadmap.md

@@ -12,9 +12,6 @@ Some future plans are briefly discussed in the repo's [issues page](https://gith
 Wanna help?
 
 - Help us translate the docs! Click on the translation symbol on the upper right.
-
 - Improve the documentation and website.
-
 - [Suggest better error messages for BuckleScript](https://github.com/reasonml-community/error-message-improvement/issues).
-
 - Convert over the more things to BuckleScript! With the great interop, you can actually keep your JS library's API stable while provinding a better BuckleScript API.

docs/stdlib-overview.md

@@ -10,7 +10,5 @@ BuckleScript is mostly just OCaml, so they share the same standard library. The
 In addition, we provide a few extra modules:
 
 - `Dom`: contains DOM types. The DOM is very hard to bind to, so we've decided to only keep the types in the stdlib and let users bind to the subset of DOM they need downstream.
-
 - `Node`: for node-specific APIs. Experimental; contribution welcome!
-
 - `Js`: all the familiar JS APIs and modules are here! E.g. if you want to use the [JS Array API](https://bucklescript.github.io/bucklescript/api/Js.Array.html) over the [OCaml Array API](https://caml.inria.fr/pub/docs/manual-ocaml-4.02/libref/Array.html) because you're more familiar with the former, go ahead.

docs/what-why.md

@@ -28,9 +28,7 @@ Despite its clear advantages, JavaScript does present a few drawbacks. Here's ho
 BuckleScript's type system alone offers three major benefits:
 
 - **Strong type inference**. Almost the entirely of the language can be inferred. You don't have to tediously write all the types manually. Feel free to still type out some parts for readability!
-
 - **Sound type system**. "Sound" here means that the types _guarantee_ that they are what they are, not just 90% of the time. Once a BuckleScript project compiles, there are no runtime type errors. \*
-
 - **Expressive type features**. With well-thought-out features like [variants](https://reasonml.github.io/guide/language/variant), [modules](https://reasonml.github.io/guide/language/module) and even an opt-in [object system](https://reasonml.github.io/guide/language/object), the types guide you through your iteration process and don't block you from expressing what you need.
 
 The combination of these three highlights, along with other type system features, unlocks new workflow possibilities and is something existing gradual typing solutions for JavaScript don't offer.
@@ -43,7 +41,6 @@ The JavaScript ecosystem is very reliant on dependencies, and quite often many o
 levels:
 
 - Function and module level code elimination is facilitated by the well-engineered type system and **purity analysis**.
-
 - At the global level, BuckleScript generates code that are naturally friendly to dead code elimination done by bundling tools such as [Rollup](https://github.com/rollup/rollup) and [Closure Compiler](https://developers.google.com/closure/compiler/), after its own sophisticated elimination pass.
 
 ### Compile-time Optimizations

website/README.md

@@ -13,7 +13,6 @@ In the end, we spit out normal HTML, with all the JS dependencies (barring a few
 Two special files:
 
 - `sidebars.json`: lists the sections.
-
 - `siteConfig.json`: some header and i18n configs.
 
 During your development, most changes will be picked up at each browser refresh. If you touch these two files, however, you'll have to kill & restart the server.

website/i18n/en.json

@@ -37,10 +37,10 @@
     "nodejs-special-variables": "NodeJS Special Variables",
     "null-undefined-option": "Null, Undefined & Option",
     "object": "Object",
+    "playground": "Playground",
     "regular-expression": "Regular Expression",
     "roadmap": "Roadmap & Contribution",
     "stdlib-overview": "Overview",
-    "try": "Try",
     "typescript-support": "TypeScript Support",
     "use-existing-ocaml-libraries": "Use Existing OCaml Libraries",
     "what-why": "What & Why",

website/sidebars.json

@@ -47,7 +47,7 @@
   },
   "try-menu": {
     "Try": [
-      "try",
+      "playground",
       "load-third-party-libraries"
     ]
   },

website/siteConfig.js

@@ -70,7 +70,7 @@ const siteConfig = {
   projectName: "bucklescript",
   headerLinks: [
     { doc: "installation", label: "Docs" },
-    { doc: "try", label: "Try"},
+    { doc: "playground", label: "Try"},
     { doc: "community", label: "Community" },
     { blog: true, label: "Blog" },
     { languages: true },