Oops! I think, I just killed Haskell!

[noknok]

Dear Haskell friends,

I shamefully confess that I have secretly started to cheat on our common passion. The question, if our user group would continue to exist, coincided with my serious suspicion if I would be able to continue with Haskell at all. Not so much because of its design flaws. But because the browser is the new universal operating system system and that just talks JavaScript, exclusively. And as much as I admire the efforts from the Utrecht Haskell community to built automatic translation systems to JavaScript, I miss the immediate availability and full power of the DOM. I must confess, that I took JavaScript seriously, and that I started to rewrite my projects.

But, as well-known and much debated among web programmers, JavaScript lacks crucial features to reasonable produce bigger projects: there is the problem with the global variables and the lack of a module system. And there is the absence of an adult type system and notation to reasonable document, predict and analyze behavior. When I started to rewrite my programs, I therefore developed my own set of concepts and tools to tackle these issues. And suddenly, all that bickering with this ugly JavaScript condensed into an entire new dialect:

I developed a strictly functional JavaScript with a (very unconventional kind of) type system and a very elegant and versatile module system.

These modules (I call them "structures", not without an obeisance to the pendant in Standard ML) are a super-concept to both type classes and modules in Haskell. And not only functions, but also these structures are now first-class: they can be arguments and returned results of function calls etc (similar to the power of structures in Standard ML; alien to Haskell with its dull modules).

The type system is very neat, based on a newly defined "Type" object and alltogether just a couple of lines in its core definition. This is totally different to the Hindley-Milner systems of Haskell or ML, but based on what is often called a "characteristic function" in mathematics, denoted by a Greek letter chi. If S is a subset of a universal set U, then the characterstic function of S is given by
  chi::U->Bool  where  chi(x) = (if (x `isElementOf` S) then True else False)
(My title for this new kind of typed lambda-calculus is "chi-lambda language".)

So, for example, I have a type
  $Number             // I use identifiers with an initial "$" as type identifiers
and
  $Number.chi(x)
returns a boolean value, depending on whether the arbitrary value x is a number or not.
There is also say a type $Int for integers, which is a subset of $Number. No problem here, but impossible in Haskell, where types have to be syntactically distinct.
As in Haskell there are type constructors, say
  $list ($Number)               // for lists (= arrays) of $Number elements
  $fun ($Number, $Int)          // for functions from $Number to  $Int
  $tuple ($Number,$Number,$Int) // for 3-tuples (= ternary arrays) of $Number-$Number-$Int elements
etc. etc. Again, and as simply as that, a call of
  $list($Number).chi(x)  
returns true iff x is an array of numbers, and false otherwise.
But there are also type constructors (these type constructors can all be derived within the small core type system) such as
  $union(t1,...,tN)          // for the (set-)union of types t1,...,tN
  $intersection(t1,...,tN)   // for the intersection of types t1,...,tN
  $finite(x1,...,xN)         // for the finite type consisting of elements x1,...,xN only
and all this is IMPOSSIBLE in Haskell!
There also is a type constructor of the form
  $model({k1:t1,...,kN:tN})
comprising all structures with key k1 of type t1, ..., key kN of type tN. As a by-product, we just obtained a schema-language for JSON!

In the next step, I introduce the structure concept and then rewrite the entire corpus of predefined ECMAScript operators and functions inside according structures. (Not a big thing really. I call this the "Prelude" part of the new language). For example, I now have the structure
  $$Number               // I use identifiers with a double initial "$$" as structure identifiers
containing the numeric functions, say
  $$Number.plus  :: $fun ($list($Number), $Number)            // a rephrase for the numeric + operator
  $$Number.equal :: $fun ($tuple($Number,$Number), $Boolean)  // works as === on numbers
  $$Number.PI    :: $Number                                   // for 3.1415...
and there also is a structure
  $$Int
with similar functions for integers. Note that
  $$Number.plus([123, 234]) === $$Int.plus([123,234]) === 357
but that
  $$Number.plus([12.3, 1]) === 13.3
whereas
  $$Int.plus ([12.3, 1])   // issues a type error, because $Int.chi(12.3) is false
By this re-definition of ECMAScript we obtain an entirely typed language, neatly packaged in structure containers
  $$Number  $$Int  $$Array  $$Boolean  $$FinSet  $$Json  $$Type  ....
and all "fully functional" in the sense that all object methods like
  array1.concat(array2)
  array1.toString()
are now replaced by typed and transparant proper functions
  $$Array.concat :: $fun ($list($Array), $Array)
  $$Array.string :: $fun ($Array, $String)
etc.

The language is also PURELY functional in the sense that it is "object-free", meaning that object methods, the "new" operator and "prototype" property are never used, although all this (as much as the whole of JavaScript itself) always remains available.

"Programming" now is the same creative process as in Haskell: building modules/structures!
And everything is neatly wrapped in structure containers, making big projects without name conflicts very easy. ....


I looked around a little and there seems to be a huge amount of projects that all strive to make JavaScript a more adult language, in particular by adding different kinds of type systems. Two really big projects from big players are:
* TypeScript from Microsoft
* Dart from Google (even aiming to "replace JavaScript as the future web language")
But my first impression is that these heavy-weight systems are much more complicated and messy. And they just don't exploit the beauty and full power of the functional paradigm!
And both are super-sets of JavaScript in the sense that they require some kind of pre-compiler to convert the new dialect into JavaScript to be run (similar to CoffeeScript). But my approach is a sub-set of JavaScript! Similar to jQuery, it only requires the inclusion of one script. (My working title for this script and my project itself is "TypeOfFun.js".) It turns out, that JavaScript doesn't have to be extended to evolve into a better language, it just has to be reduced and restricted by a couple of (optional) coding rules and conventions. Any old JavaScript browser will do!


Well, I need to work this out and clean it up. But I am very keen on presenting all this and expose it to your (hopefully merciless) scrutiny. The subject itself would probably be more at home in the cross-functional Amsterdam meetup and maybe I should try to bother them. But I have never attended before and unfortunately, I can't be in Amsterdam on their next meeting date (April 22), either. Besides, our group with Haskell background is actually my first choice of audience and critics. So, what do you think, should I prepare a talk and would you be interested?
The challenge would be my thesis, that you will never want to code in Haskell again. ;-)

Yours, Thomas