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.