Care for a little comparation with TypeScript ? If i know TS why should i look at PS ?

(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

With some languages, a big part of the selling point is that it's the same or similar to a language the programmer already uses. Clojure and ClojureScript come to mind, or even server-side JavaScript. Now, with ClojureScript, another common selling point is the synergy with react -- something that would appeal even to people not using Clojure (maybe because they're averse to the JVM).

So where is PureScript positioned related to this? Let's say I'm writing a backend in Ruby or Python and not Haskell, why PureScript instead of CoffeScript or sweet.js?

(I'm actually interested in this, not intended as a put-down.)

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).

Is there any particular reason why PureScript was designed with a single number type (so no proper ints)? I know that's how JS sees things, but now with a whole proper type system it would seem like we should have proper numbers? I admit I haven't read the entire docs, is there a way to e.g. have the type checker ensure a number field such as a year in a date isn't assigned a non integer?

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

As long as it is efficient and compiler supported (I.e an int add ends up as the proper instruction, and improper assignment ends up as a meaningful compiler error) I think the implementation doesn't matter. Going to Natural numbers and such feels like a separate topic from just having efficient and type safe (modulo overflow) integers.

Consider what it would take, writing in C, to store and compute integers in the "double" type, including range checks after every operation. Unless you go the asm.js route or otherwise ensure that your JIT special-cases integers, constructing range-limited integer types out of JavaScript doubles has a non-trivial cost.

Personally, it surprises me that with all the years of extensions to ECMAScript, nobody has added 1) sized integer types like word32, word64, and so on, and 2) transparent bignums, similar to int/long in Python.

I'm not sure I understand the problem, I meant that in PureScript there would be distinct number types, and the PureScript compiler would forbid me to assign an int field with a double value. The generated JS would be all regular JS "numbers" (ie floating point throughout).

I mean there are several compilers from langs with strong type systems, such as F#->JS with FunScript, and in those, usually the source lang has integers...

What happens when you take two "integer" fields and add or multiply them? The compiler would need to check that the result still fits in an integer.

No compiler in existence makes these kinds of checks on anything except maybe literal values in special cases. What you propose would entail evaluating the program's runtime behavior at compile time. Ensuring anything that gets put in an integer field is an integer is easy assuming you have type annotations on everything.

For the cases you mention the checks would simply be: integer * integer = integer, integer + integer = integer. Problems only arise when real/floating point numbers are introduced and how to handle integer division.

>No compiler in existence makes these kinds of checks

If your claim is that no compiler in existence can make these kinds of checks at compile time, that's not true. Any dependently-typed language can do this (Idris, Coq, Agda, ATS). In fact, even a language with refinement types can do this, like Liquid Haskell.

And a number of languages do these checks at runtime: Ada and Nimrod are two that come to mind.

Assuming you mean two 32 bit integers, the result is a new 32bit integer that may have overflown. The compiler doesn't care in any language I know of.

This looks really cool! Do you currently have any abstractions for interacting with DOM elements?

I'm only a bystander, but I believe PureScript doesn't include data-to-DOM binding. If you want to do it manually, I would look at the Eff monad[1].

It sounds like there are adapters to few popular frameworks, like React [2] and Angular [3].

[1] https://leanpub.com/purescript/read#leanpub-auto-the-eff-mon... [2] https://github.com/purescript-contrib/purescript-react [3] https://github.com/purescript-contrib/purescript-angular

I'm guessing a JS-controlled framework, like React or Mithril, would be a better fit if you choose to use PureScript as a core piece of your app, as they are function-based, like PureScript.

Interesting. For my current project, I don't want to include large frameworks so it looks like this library [1] should do the trick.

[1] https://github.com/aktowns/purescript-simple-dom

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.

If you don't write Web stuff, you can ignore JS completely, and PureScript too.

If you prefer dynamically-typed languages, use them directly (JS, CoffeeScript, etc.)

If you prefer statically-typed languages, you must care about a dynamically-typed language, since every statically-typed language can be thought of as a dynamically-typed language + a machine-checkable safety net. For example, Haskell/ML/etc. are built on Lambda Calculus, C/FORTRAN/etc. are built on machine code. If you're programming for the Web, why not use JS as the dynamic part of your language (the "computational content")?

I didn't want my comment to devolve into an argument about the merits of static vs. dynamic. My comment is really to ask why would I use Typescript for web programming? Where does it fit? It doesn't seem to fit in or fill a need that isn't already possible with any combination of static and dynamic languages used separately. In fact I feel it blurs the separation of concerns between static vs. dynamic.

Do you mean PureScript?