Skip to content

Latest commit

 

History

History
135 lines (80 loc) · 7.63 KB

README.md

File metadata and controls

135 lines (80 loc) · 7.63 KB
Raw

purescript-faq

An unofficial FAQ for the PureScript language.

What questions would you like to see in an FAQ?

This is a work-in-progress, so please suggest addition questions and/or answers.

How do I get started?

See the Getting Started Guide.

How do I bundle my app?

The simplest option is with spago bundle-app. This produces a single .js file that you can execute in node or include as a script (for example in your index.html). This runs dead code elimination, and that added delay is not ideal for quick iterations during development.

Some faster bundling option are:

The bundling process should improve once the PS compiler is modified to output ES modules.

What are my CSS options?

An issue tracking the start of a CSS guide.

What are some recommended frameworks for frontend web development?

What are the differences among the above frameworks?

  • Halogen is written entirely in PureScript.
  • React-basic enables easy interop with the React ecosystem.
  • Concur focuses on simple composition of Widgets (components).

You may have to dive into the framework docs and look at some examples to get a better sense of the differences.

What's on the roadmap?

The Intended to be Implemented page provides some visibility into items on the todo list, but could be clarified with more details on planned sequence. Ideally, we'd have a "roadmap summary" page, but until then, here's a short summary:

What's missing from having PureScript 1.0?

  • New package registry
  • ES6 modules
  • Better dead code elimination and bundling
  • Complete documentation
  • Smooth new-user experience

Do I need bower to install packages?

No. The docs referring to bower are outdated. Spago is the recommended package management tool.

Why can't I install a package listed on Pursuit?

Pursuit lists all published packages, but not all of these make it into the package set accessible to spago. It is encouraged to open PRs to add these missing packages to the package set.

You may alternatively consult Starsuit, which is a Pursuit clone that is synced to the latest package set.

Pursuit plans to be better synced with the new registry.

What's a good development setup?

A list of available editor options.

Some framework templates also demonstrate how to setup a project with automatic rebuild and webpage refresh upon saving changes:

Is there a style guide for PureScript indentation or an autoformatting tool?

Yes. The purty formatter. Note that there are still some formatting issues to fix.

For editor integrations:

How does PureScript compare to language X?

There's a task for putting together these summaries. Feel free to contribute.

How do I write ... ?

The cookbook aims to provide lots of miscellaneous examples. Feel free to request additional examples.

Why is there no built-in support for tuples (like Haskell and Elm)?

Records serve the same niche and are more readable. Also, built-in tuples, if added, are one more feature to maintain in the PureScript compiler and one that is easily expressed without built-in support. For example, using purescript-tuples, you can write the following code:

module Foo where

import Data.Tuple (Tuple(..), (/\), type (/\))

tuple :: Tuple Int String
tuple = Tuple 1 "bar"

-- You can also use `/\` to write tuples
conciseTuple :: Int /\ String
conciseTuple = 1 /\ "bar"

Relevant links:

Why use <<</>>> for function composition, and not <</>> (like Elm)?

We chose to match the syntax and capabilities of Haskell's Category class (we call it Semigroupoid and drop the identity requirement). Note that <<< in PureScript and Haskell (in Haskell it's an alias for .) allow for composing more than just functions, while << in Elm only works for functions. See Differences from Haskell.

Additionally, while not essential, it is common to use Semigroupoid composition with operators in the Functor hierarchy (eg., >>=, >=>, <$>, <*>), and using a three-character operator keeps code in alignment when split over multiple lines.

If I define an Ord instance, why must I also define an Eq instance?

Original question:

For dependent typeclasses (e.g. Eq and Ord) the operations from one are (always? sometimes?) strictly more powerful than the operations in the other (i.e. you can express eq via compare). Why is it then that if I define Ord for a type, I still need to explicitly define Eq? Shouldn't Eq be automatically derivable by having an instance of Ord?

A seemingly-redundant definition of Eq is required to avoid creating orphan instances. Imagine if Ord and Eq were in separate libraries, and the author of the Ord library defined an Ord instance for some type which didn’t have an Eq instance. If instances worked that way, that type would automatically get an Eq instance too. Now suppose the author of the Eq library adds a direct Eq instance for that type which doesn’t agree with the one via Ord. What should we do now?