paf31's comments

Do you mean PureScript?

I think it really depends what you're trying to do. There's definitely a class of problems where the impact of a runtime type error would be low. But there are plenty of other cases where you want to constrain what you or your users can do at compile time.

> I fail yet to see what advantages PureScript brings compared to Elm.

I think they fit different use cases. Elm is excellent at interactive web apps using FRP. PureScript is a little more general purpose and has a few type system features which Elm currently does not (type classes and rank N polymorphism). Also, PureScript's generated code is a bit simpler and doesn't need a runtime library.

There are a few options, but the most fully-formed is probably purescript-react. I'm also interested to see where the virtual-dom bindings go. The last chapter of the book covers how you might go about writing a library for working with DOM elements in PureScript.

Yes - in fact, that's the approach we encourage for working with immutable arrays: https://github.com/purescript/purescript-arrays

It uses JavaScript's evaluation model - i.e. strict, but you can write lazy code using libraries, such as purescript-lazy.

It has been discussed before: https://github.com/purescript/purescript/issues/396

The reason I have been against the idea so far is that an integer type is easily accomplished using the FFI and user code. Here is one example (not quite what you're asking for, but hopefully instructive): https://github.com/darinmorrison/purescript-int64

Consider a recursive function like factorial:

  fact :: Number -> Number
  fact 0 = 1
  fact n = n * fact (n - 1)

This will build stack frames and fail with a stack overflow for large inputs. We can fix this by using tail recursion and an accumulator:

  fact :: Number -> Number
  fact = go 1
    where
    go acc 0 = acc
    go acc n = go (acc * n) (n - 1)

The PureScript compiler will recognize that every recursive call is in tail position, and will convert the function to a while loop.

If we want to perform side-effects during the recursion, we typically use a monad to track the type of side effect in use. For example, we can use PureScript's Eff monad to trace information to the console:

  fact :: Number -> Eff (trace :: Trace) Number
  fact = go 1
    where
    go acc 0 = do
      trace "Done!"
      return acc
    go acc n = do
      trace "Keep going ..."
      go (acc * n) (n - 1)

In the case of the Eff monad, the PureScript compiler employs some special tricks in the optimizer to enable the tail call optimization, so we're still OK. But this is only possible because Eff is defined in the standard library (at least until we implement custom rewrite rules).

In the general case, the compiler only sees applications to the monadic bind function of the underlying monad. For example, if we use the Writer monad instead:

  fact :: Number -> Writer String Number
  fact = go 1
    where
    go acc 0 = do
      tell "Done!"
      return acc
    go acc n = do
      tell "Keep going ..."
      go (acc * n) (n - 1)
  

which is equivalent after desugaring to the following code:

  fact :: Number -> Writer String Number
  fact = go 1
    where
    go acc 0 = tell "Done!" >>= \_ -> return acc
    go acc n = tell "Keep going ..." >>= \_ -> go (acc * n) (n - 1)

This is an example of "monadic recursion" - a recursive function whose return type uses some monad. In this case, the recursive calls are no longer in tail position, so the compiler cannot apply the tail call optimization. The result is that the compiled JavaScript might blow the stack for large inputs.

The point is that idiomatic Haskell code is often not appropriate in JavaScript because of the different semantics, so it might not be appropriate in PureScript either. The good news is that many Haskell idioms have corresponding PureScript idioms (often using the Eff monad).

Free HTML version is here: https://leanpub.com/purescript/read

(Copied from below) I've written quite a lot of TypeScript, and I generally feel very productive in it, but occasionally I feel like I want more from the type system (type classes, rank-N types, sum types, etc.) and tidier syntax. You might be interested in Bodil Stokke's recent Strange Loop talk, where she discusses why she switched from TypeScript. https://www.youtube.com/watch?v=yIlDBPiMb0o

I've written quite a lot of TypeScript, and I generally feel very productive in it, but occasionally I feel like I want more from the type system (type classes, rank-N types, sum types, etc.) and tidier syntax. You might be interested in Bodil Stokke's recent Strange Loop talk, where she discusses why she switched from TypeScript. https://www.youtube.com/watch?v=yIlDBPiMb0o

I think it's definitely possible to put knowledge of Haskell to use in PureScript, but it's not like Fay, Haste, GHCJS etc. where you can copy code verbatim. I think of PureScript as "an environment in which to write principled JavaScript". That requires that, to a certain extent, you should have JavaScript's semantics in the back of your mind while developing. For that price, you get ease of debugging and some tools which you don't have in many other compile-to-JS languages (an expressive type system, type classes, ability to refactor with confidence etc.)

Of course, one of the best things about AltJS is the interoperability with other languages. PureScript won't be the best tool for every case, but it has a simple FFI. It's possible to write complete front-ends in PureScript, but I'd love to see more examples where PureScript is used alongside something else (I've used TypeScript with PureScript successfully, for example).

"Simple readable JavaScript" as opposed to the sort of output you might expect from compilers for other Haskell-like languages which attempt to preserve Haskell's semantics. Certainly there are cases where using techniques from pure functional programming can lead to poor performance (monadic recursion jumps to mind), but it is perfectly possible to write fast code using PureScript. And if you really need to squeeze out every last bit of performance, you can always write code in JavaScript and use the FFI.

PureScript developer here. Happy to see this here, and happy to answer any questions.

You couldn't pay me enough to work on some stacks.

Also, certain technologies do a good job of convincing potential employees that you know what you're doing and committed to using the best tools available IMO.

Also why not consider remote employees?

My approach is to try to attract strong developers by using the best languages and tools. What technology stack do you use?

Very nice. It took me a while to realize that array literals aren't supported, but once I did that I was able to write concatMap and watch it being evaluated.

A couple of points:

- If there is a syntax error, the box just turns red. It would be nice to see what the issue is.

- You could probably make it clearer that it's possible to execute arbitrary expressions, by editing the map term, for example.

Presumably this doesn't prevent a developer from creating another "pattern class" subclassing some superclass in another package, thereby breaking existing pattern matches?

Added to my calendar :)