purescript

I'm curious why this isn't a backend for the existing PureScript compiler, since the front-end seems to be copy-paste identical?

PureScript has a lenient FFI so you can choose to use 99% pure functions if you like (at your own risk).

Yes it does.

This seems like it could be useful, but I don't seem to be able to create a discussion which is visible to everyone, yet only editable my members of my team, which is my main use case (for discussing project direction and such). "Public" seems to mean "visible to everyone in the organization".

You might find our recent blog post interesting:

https://medium.com/fuzzy-sharp/migrating-to-postgres-2dc1519...

TL;DR: persistent + esqueleto + servant

Category theory matters to programming because, among other things, it teaches us how to abstract over programming languages. What better definition of abstract programs than "things with types which compose"?

Now consider categories with various types of constructions (products, limits, exponentials, etc.) and you'll notice they correspond to requiring certain features in your language.

I work on the PureScript (http://purescript.org) compiler, tools, libraries and book in my spare time (along with many other unpaid contributors), because it's the programming language I wished had existed when I started creating it. It's still the closest thing to a perfect environment for web development, at least as far as I'm concerned :)

Just model this as taking an old, immutable web to a new one.

    impact :: Web -> Web

Persistent data structures will let us reuse the best parts of the old web efficiently.

> Aside from apps at work

Now I'm curious :)

Here is foldl implemented using foldr in PureScript, along with an example of using laziness to gain modularity:

http://try.purescript.org/?gist=63d81adf9f5257ffa4f576df2658...

We recently added a way to dump out the compiler's intermediate representation as JSON, so it's actually very straightforward to create new backends by transforming that output [1].

The representation is fairly compact, so the requirements for a PureScript compiler backend are fairly minimal. You just have to translate all of the features of the IR:

- Functions with lexical scoping - Support for the primitive types defined by PureScript (we need to define some of these types more concretely in a specification) - A way to encode records. This could be something like JavaScript's objects, or just a map data structure.

The JS backend actually does more optimizations before code generation, but it starts from the same intermediate representation.

[1] https://github.com/paf31/24-days-of-purescript-2016/blob/mas...

Halogen is not the only option for building web applications with PureScript. There are simpler options like Pux and Thermite, which are possibly much easier to teach. Halogen is optimized for a different use case.

You don't need to constrain yourself. AltJS allows users to mix and match different languages for different problems. Use a pure functional language where it makes sense for you, and don't where it doesn't.

This is from 2014. Here is the 2016 version: https://github.com/paf31/24-days-of-purescript-2016

> to become even more hardcore on algebra and categoric language

In some of the standard libraries, yes, that's true. However, it's possible to use PureScript without the standard libraries, and use alternatives such as Preface (a teaching library) or Neon (an alternative to Prelude)

https://github.com/paf31/purescript-preface

http://pursuit.purescript.org/packages/purescript-neon/0.1.1

The situation has improved since cabal install was required.

npm install -g pulp purescript

should be enough now.

> Still, type classes seem to appear less and less elegant as time goes on

I think part of the problem is that type classes are so easy to abuse. When you have a problem like e.g. monad transformers, where a) you have a lot of boilerplate code which would be irksome if written out by hand, b) you have laws to make sure the generated code is sensible, and c) your types have exactly one such sensible instance, then classes are very nice. Abuses of type classes exist where any of the three above conditions fail to hold IMO, and a scrap-your-typeclasses approach can be very valuable then.

I haven't used latest Halogen yet, so I can't give a detailed comparison, but the approach in Thermite [1] is indeed what I am referring to above. It was based on some work in the OpticUI library [2], and has worked out quite nicely for the few projects I have applied it to.

I will say that the types in Halogen seem more complex, but they can be justified by the fact that the coproduct machinery helps ensure all actions get handled somewhere. This may be possible with prisms, I'm not sure yet. This library [3] seems relevant.

One issue I've found, which I understand the Halogen folks are also finding, is that it is tricky to wire up action handlers such that a subcomponent can invoke an action and have a parent act on it and invoke its own action in response. Granted, this is a relatively infrequent use case, and you can always push such logic into some shared parent.

[1]: https://github.com/paf31/purescript-thermite/ [2]: https://github.com/zrho/purescript-optic-ui [3]: https://github.com/joneshf/purescript-totally

I know there is the Focus library [1]. I'm not sure about prisms, traversals etc.

[1] http://package.elm-lang.org/packages/evancz/focus/1.0.1/Focu...

I've found lenses (for zooming state) and prisms (for zooming actions) to be very useful for solving this problem.

My answer to this has changed quite a bit over the last year. It used to be the case, at least as I saw it, that Elm had a UI focus, and PureScript tried to be a general-purpose language. So it came down to typical expressiveness vs. tooling/analysis tradeoffs. You could use Elm and maybe sacrifice some general-purpose language features like dealing with arbitrary effects, but buy yourself best-in-class tools like their excellent time-traveling debugger, and hot code reloading. Or you could pick PureScript, and have a general-purpose language which ran in a bunch of environments with lots of native libraries, but at the expense of tooling.

Now though, Elm has become a more general-purpose language, adding effects and various other features, and PureScript has better UI libraries and tooling/editor support. So the gap has closed somewhat.

Speaking generally, the goals of the two projects are pretty similar. I can't speak for the Elm community, but "bring strongly-typed FP to the JavaScript community via the web platform" seems to approximate the goals of both projects pretty well (maybe someone from the Elm side can correct me here?) So the goals are similar, but the execution is very different. I think Elm and PureScript differ greatly in opinions regarding _how_ to bring strongly-typed FP to JavaScript. This is not just a question of language features (type classes and HKTs are often mentioned), but also things like how the language should present its foreign function interface to JavaScript, what the entry point to an application should look like, whether to build features into the language or in libraries, how to grow a language community, etc. In practice, these make the experience of using each language very different.

> when would we want one vs. the other?

Elm provides tools with which you can become productive quickly. Also, it's used in production by NoRedInk and others, so it's clear that it is general-purpose enough to be used for real applications. I think there will be two paths to PureScript for most users - from Haskell, and from JavaScript, quite possibly via Elm. Just as users might move to Elm because they want type safety and expressiveness, they might move to PureScript because they find themselves wanting even more type safety and expressiveness. Certain abstractions are possible in PureScript, but (I think, again, would be glad to be corrected..) not in Elm - free monads, monad transformers, monadic tail calls, van Laarhoven lenses, etc. SlamData is an example of an (open source) company putting these tools to great use.

> I wish all these alt-JS-haskellish language authors (of PureScript, Elm, Roy, etc.) would just work on making GHCJS better.

All three of those have very different goals and trade-offs from GHCJS.

I agree that it would be nice to share more work/knowledge though. One of the nice things about AltJS is that several languages can coexist in the same codebase.

I hope you find PureScript has improved considerably since you last looked, but if you have any specific issues, please drop into #purescript IRC and let us know.

There are some PureScript projects that I know of running on Node, although it is admittedly less common. I'm currently working on a framework to build REST services in PureScript, so hopefully the situation will improve shortly.

The largest all-PureScript application I know of is SlamData[0], which takes about 12s for a rebuild, but SlamData uses a _lot_ of modules. For smaller projects it's much less. It's not great, but performance is one of three main goals for the current milestone. There is an alternative front-end called psc-compile[1] which reduces the incremental build times considerably. I hope to be able to integrate it soon.

  [0] slamdata.com
  [1] github.com/bitc/purescript/tree/psc-compile/psc-compile

Monad transformers and PureScript's row-based effects are two complementary approaches to the problem of extensible effects.

Some effects in PureScript look a lot like the effects provided by certain monad transformers (StateT/ST/Ref, ExceptT/Exception, etc.), but there are differences in terms of how things compose. Take StateT and ExceptT for example: you can compose them in two ways, and get two different monad transformer stacks, with different behaviors (surrounding how state propagates when an exception occurs). There are valid use cases for each, but with the ST and Exception effects, there is only one way to combine them: the way the underlying (Javascript) runtimes chooses for us.

There are things which each one can do which the other cannot. Fortunately, we can mix and match in PureScript since we have the purescript-transformers library. A typical arrangement is to stick Eff on the bottom of a monad transformer stack.

_Edit_: of course, everything you can do with a monad transformer can be done more verbosely with pure functions and the underlying monad, so you _could_ replace monad transformers with Eff in many cases, but in practical terms, it might not be all that useable in some cases.

I don't know Alice ML but one advantage of using abstractions like Applicative is that you can write code which is polymorphic in the particular applicative you choose. So, you can mock your concurrent requests using the Identity or ZipList applicative, and use the type class laws to prove things which are true about both. I'm guessing, but it looks like the spawn syntax is built-in here. Not that it's not as elegant as the Concurrent version, but likely not as powerful from an abstraction point of view.

An Applicative functor is a type constructor which lets you lift functions of arbitrary numbers of arguments to functions whose arguments are wrapped with that type constructor.

Concretely, if you think about promises in JavaScript, for example, if you have a function A -> B -> C -> D, say, and you have three promises of types Promise A, Promise B and Promise C, you can construct a Promise of type Promise D by running the three in parallel, and applying your three-argument function when they are all done. So you've turned a function of type A -> B -> C -> D into one of type Promise A -> Promise B -> Promise C -> Promise D. If you can do that sensibly for any number of function arguments, you have an Applicative. ("sensibly" here means that there are type class laws which have to hold)

Every Monad is also an Applicative functor, since you could use do notation to compose your promises instead, but there are other interesting Applicatives which do not come from Monads.

One thing I find surprisingly effective is that I write a todo list on paper every morning, and check items off as they get done. I keep a longer todo list of personal goals on a Trello board.