Apr 12, 2013, 5:59:15 AM4/12/13
Dear Haskell friends,
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
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
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
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
with similar functions for integers. Note that
$$Number.plus([123, 234]) === $$Int.plus([123,234]) === 357
$$Number.plus([12.3, 1]) === 13.3
$$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
are now replaced by typed and transparant proper functions
$$Array.concat :: $fun ($list($Array), $Array)
$$Array.string :: $fun ($Array, $String)
"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. ....
* TypeScript from Microsoft
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!
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. ;-)