This paper, section 2.1.2 explained the problem the FDs solve more than the Purescript book

Original link here:

• Matt Parson's blog
• Stephen Diehl's "What I wish I knew when learning Haskell"
• Bortosz Mileski's blogs / videos
• TAPL
• Type theory and formal proof
• Software foundations
• Chris Allen's talk

RTD written by justinwoo about Purescript

Purpose:

• Explain and document basic to advance syntax using meta-language

Principles:

• Verify syntax by making it compile, so that code can be quickly updated for newer Purescript releases
• Reduce compilation noise (e.g. warnings) where possible - Added (2018-08-23)
• Make the folder referrable: keep all syntax-related code in the folder and exclude everything else
• Make the folder learnable: clearly and easily indicate pre-reqs for a page.

Outcome:

• Explain Kinds
• Non-Module Syntax
• Module Syntax
• Foreign Function Interface (FFI) Syntax
• Type-Level Programming Syntax

Taken from this link

I was wondering if you had gone through the docs page I put up for general PureScript resources: https://purescript-resources.readthedocs.io

Maybe some cross-linking would be good somehow?

Hoist is very easily explained here, but it shows up in numerous function names. Knowing the name and its definition allows one to automatically know what a function name with a pattern hoistType means.

• https://julesh.com/2018/08/16/lenses-for-philosophers/

Context

Section:
    Meta
Issue Type:
    Enhancement

Body

Principles

• Provide "stable" versions...:
  • Readers of a given version should be able to read and bookmark files without worrying about those files/links breaking due to changing its name (via reordering or moving one section to another)
  • Older versions should be available via git tag.
• ...without restricting developer creativity: I should be able to continue writing new content and re-ordering things without concern
• Load the latest release: This repo should show the latest release version of this project, not the one on which I'm working. In other words, the default branch should coincide with the last release.
• Lessen maintenance as much as possible:
  • There should only be two branches, latestRelease and development since a branch name like master is overloaded with connotations. Those who want to read older versions can checkout a tag.
  • Don't hyperlink to other files (#43) until either a stable release is made or we find a better way to do that (might be its own Purescript project that we should design in this project...).
• Indicate PS version: As Purescript continues to evolve, the release should indicate which major PS version it is for with a prefix

Release Syntax

ps-[version]-vMajor.Minor.Patch where

• major change means
  • a file name has changed, so that bookmarks or links to that entity are now broken
• minor change means
  • a file's contents have been significantly updated
  • additional files/folders have been added without breaking links
  • a file's header name has changed, so that bookmarks or links to that entity are now broken
• patch means
  • a file's contents have been slightly updated (typos, markdown rendering issues, etc.)
  • a mistake has been corrected that does not involve

Printing to the console regardless of which monadic context in which code is written...

From this link

Opened Closed
------------------
Variant  Either
Record   Tuple

This function works:

f :: Int -> Int
f = plus1
  where
  plus1 :: Int -> Int
  plut1 x = x + 1

but using the where syntax with guards will not

f :: Int -> Int
f x | x == 0 = plus1
    | otherwise = 4
  where
  plus1 :: Int -> Int
  plut1 x = x + 1

This is known bug in Purescript: purescript/purescript#888

This should include the basic syntax for curried functions and the uncurried forms via the purescript-functions package (Pursuit docs here)

Coming from #7, where I realized this is a design pattern and not syntax (it was included in syntax because a number of other syntactical things came from that repo)

I asked on the Slack channel and got a good response from monoidmusician (see link). I reordered the conversation to make it clearer:

I have quick question about deriving type class instances via the purescript-generics-rep library. Type classes can be derived in a few ways if the underlying types already have an instance. For example, if I have data T = T Int, I can use derive instance name :: Eq/Show/etc. T. If I have newtype T = T Int, I can use derive newtype instance [rest of the stuff]. What does purescript-generics-rep add that is not already covered by those two?

generics-rep lets you work with the representations of sum and product types (all ADTs basically, not just those with one constructor with one field) in a type-safe way
one of the coolest uses I’ve found is deriving optics, but you need some background in lenses and prisms to understand what’s happening and the benefits of it: https://pursuit.purescript.org/packages/purescript-generics-rep-optics/0.1.0

So data T = T Int works, but as soon as I add another parameter (e.g. data T = T Int Int Int), then derive instance ... stops working and I need to use the generics-rep library?

not so much ... the builtin typeclasses will let you derive most ADTs, that’s not the issue, but you can’t newtype derive if it’s not a newtype (one constuctor with one field), so generics-rep covers other typeclasses (like BoundedEnum I think? I forget)
this is my bullet-point overview of deriving methods:

• newtypes only apply to ADTs with one constructor with one field (hint: it’s best if you use a newtype whenever you can)
• newtype deriving only applies to newtypes (of course), and it directly inherits the same behavior
• the regular deriving covers a large variety of ADTs (even recursive ones), but only a few classes (Eq, Ord, Functor, ...)
• generics-rep covers a similarly large number of ADTs, and it adds to the number of derivable classes (Bounded, Enum, Monoid, ...), but it cannot handle higher-kinds, so Functor is out
• for classes such as Eq and Functor in particular, the instances are reasonably unique, so behavior will usually be the same across the deriving methods, but performance will change, usually with: newtype > derive > generics-rep ... this also remedies the caveat I mentioned above about “[a newtype derived instance] directly inherits the same behavior”

also note that each generic class aimed at deriving will put different constraints on what kind of ADTs it will handle: for instance, GenericMonoid only handles empty ADTs and product shapes whose fields are all monoids

Soon thereafter, justinwoo pointed me to a tutorial he wrote here.

This is used in Halogen to hide some parts of Component using mkType and unType via unsafeCoerce.

Recently came across this link on HN that enables one to write/define their own "keywords" in a language to increase readability. Not sure what problem it would solve though and what its performance costs would be.

Found this repo today.

bar x | Just y <- fn x = ... -- x and y are both in scope here

introduced on 0.11.0

Original

1. explain the dependencies that would be required in the 'hello world' program
2. provide a simple but clear hello world program that
   • uses a few FP concepts
   • has tests to verify it works correctly, thereby demonstrating how to write/structure tests using various libraries
   • has benchmarks, thereby demonstrating how to benchmark one's code
   • runs in both the Node environment and the web browser environment

Update 1:
Ideally, the 'hello world' folder would

1. Explain FP's philosophical foundations
2. Explain Prelude
3. Explain Eff/Effect (full) and Aff (somewhat)
4. Explain testing and benchmarking
5. Explain the various ways to structure an application
6. Provide exercises for the above via console-based games

This repo needs to include the licenses of the various works and sources it uses or modifies to produce the examples or explanations it has now that I have a better understanding for how things work.

Context

Design Pattern
Enhancement/ToResearch

Body

As said by Liam on the Slack channel:

There are many ways to represent an existential.If you want to do it only using the Exists type, one approach is:

newtype Foo' a = Foo' (Exists (Foo a))
type SomeFoo =  Exists Foo'

Another approach is to encode it with forall, this is done like:

newtype SomeFoo = SomeFoo (forall out . (forall a b . Foo a b -> out) -> out)

Another is to pretend with unsafeCoerce:

foreign import data SomeFoo :: Type
someFoo :: forall a b . Foo a b -> SomeFoo
someFoo foo = unsafeCoerce foo
runSomeFoo :: forall out . (forall a b . Foo a b -> out) -> SomeFoo -> out
runSomeFoo f foo = f (unsafeCoerce foo)

This document presents the following code:

newtype Attribute = Attribute { key :: String, value :: String }

attribute :: String -> String -> Attribute
attribute = Attribute { key: _, value: _ }

The compiler will throw a type error for the attribute function.
The { key: _, value: _ } notation is syntax for \v0 v1 -> { key: v0, value: v1 }.
So Attribute { key: _, value: _} is actually Attribute (\v0 v1 -> { key: v0, value: v1 }).

To make this work I'd suggest:

attribute :: String -> String -> Attribute
attribute key value = Attribute { key, value }

The overly confusing point-free version is:

attribute' :: String -> String -> Attribute
attribute' = (Attribute <<< _) <<< { key: _, value: _ }

This link explains it better and shows where I misunderstood the concept.

Just to see whether there are any other things that should be documented that I can't find elsewhere

The entry point of a program, whether it be src or test must be main and have a type signature of either Effect or Eff. (This could be modified via a flag in the build command to use a different type, but that's going beyond the typical requirements)

At the bottom it says:

Either a b has kind Type -> Type -> Type ...

However, Either a b has kind Type, whereas Either has kind Type -> Type -> Type.

Perhaps examples could be added to the existing table?

Referring to what was explained in these slides

This folder should accomplish the following:

• Explain the differences between Bower and psc-package
• Document the CLI options for the most popular tools: purs, pulp, psc-package. (Others may be added over time like purs-loader)
• Document a typical workflow from project start to finish (creation, fast-feedback development, initial publishing, 'bump' publishing)

This is a "when I get to it, if ever" goal:

Terms should include:

• pure vs impure
• local vs global mutable state
• specific prefixes/suffixes often used
  • lift
  • hoist
  • run
  • mk
  • un
• RTS
• Total

See https://github.com/natefaubion/purescript-call-by-name

See the original PR here

Right now, each project specifies its own psc-package.json file, which forces psc-package to git clone the necessary files for each project. These files could be shared between projects if they were stored in one central location and projects symlinked to that folder.

The benefits of this approach:

• a single package set version is used for all projects, making it easier to upgrade to a new version that includes bug fixes / new dependencies
• psc-package only needs to git clone once, reducing needed bandwidth and the amount of space used by this project on a local computer

See this link: http://reasonablypolymorphic.com/blog/higher-kinded-data/

This library might be worth looking at in the future

Would be lovely to have a way of navigating around all the content, as well as knowing where I left off.

Great work btw!

From this
Explain differences between data, type, and newtype when using records

If it’s a single wrapper you should be using a newtype
data with a record is not like Haskell records, and it will introduce unnecessary runtime boxing

See https://github.com/paf31/24-days-of-purescript-2016

https://liamgoodacre.github.io/purescript/instance/chain/2017/08/18/purescript-instance-chain.html

See purescript/purescript#3414

Context

Syntax
Enhancement

Body

See this syntax

(=~=) :: Number -> Number -> Boolean
(=~=) x y = -- implementation

See this repo and its purescript section

Original link here: https://chrispenner.ca/posts/typesafe-api-versioning

Purpose:

• Prepares a person to start learning Purescript through this project

Outcome:

• Show how to install Purescript and related packages for the first time
• Explain how to start, understand, and use the REPL

I've already done this for the Basic Syntax folder, but it needs to be done for the Module folder.

An instance head is essentially the arguments that a type class instance is defined for. For example, in Show a => Show (Maybe a) the instance head is the Maybe a part.

From Liam on Slack