Thursday, October 7, 2010

Sets are values

As well as being functions, set are values. You can apply functions to them, pass them around, etc.
Wait, what is {1,2} + 2, you ask?
Simple: it is just {1+2,2+2}={3,4}.

Similarly, {...,-3,-2,-1,0,1,2,3,...} * {2,3} = {...,-9,-8,-6,-4,-3,-2,0,2,3,4,6,8,9,...}.
It's just that set monad or ambiguous choice that you thought might be cool.

But sets are types, so this means you can do type-level arithmetic; (2 * Integer) * 3 = (6 * Integer)
Of course, this probably makes the type system undecidable... but I certainly don't care!

Saturday, October 2, 2010

Software VC

Since software is change, it stands to reason that good software should have lots of change, right? It should be easy to change, fun to change, quick to change, etc.

The current method of software distribution, namely binary executables, is not that good a format then. Neither is text, since you can't run it. So something else must be devised... a distributed environment? a serialization format for objects over the network? I have no idea, yet. But commit logs are pretty useful; something like that format would be cool.

Problems and their solutions

Search time! Programming language problems and my solutions for them:
Programming language problems
Programmers are stupid -> make them users. (who are even more stupid!)
No paradigm is complete -> continuously invent new ones
Performance -> whole-system optimization
Three programming language problems solved forever (using HQ9+)
Incrementing a register: ++ (implicit stack)
Hello world: "Hello world!"
Quine: "There is no source", so quines are meaningless. But hacking up something legible won't be too hard.
99 bottle of beer on the wall:
bottlefunc = {
  0 -> "No more bottles"
  1 -> "1 bottle"
  x -> x " bottles"
}

99..0 | bottlefunc | {
  x " of beer on the wall, " tolower(x) " of beer;\n"
  (x == 0) ? "Go to the store and buy some more, " x.first " of beer on the wall."
           : "Take one down and pass it around, " tolower(x.next) " of beer on the wall."
}
Important things for a programming language to have
Unicode support: This is all about how you define a character. And, as it turns out in Unicode, there are no characters, there are only code points, integers from 0 to 10FFFF. And there are all sorts of code points that have no resemblance to characters; byte order marks, zero-width spaces, text direction overrides... such a pity that there are no conditional characters to make it Turing-complete!
Anyways, I am certain you see that Unicode is large enough to be put in its own separate library. So that is where Unicode will be, and the language will remain close to the keyboard. (which appears to be close to ASCII)
The problem Self solves
The duality between classes and instances creates a problem. But classes, as depicted in the link, are data structures. So, logically, if removing classes is a good idea, so is removing abstract data types, unions, records, and the other data structures we know and love hate.

Sets are functions

Sets are functions of type a -> Boolean. Stating that sets are well-defined is equivalent to stating that their function terminates.

Types are sets and sets are types

The essential property of a type is whether a value belongs to it. So too with sets. So let a ∈ S be the same as a instanceof S.
Subtypes are subsets.
Function types are special subsets of set tuples.
(Disjoint) set union is the sum type
The Cartesian product of two sets is the product type of the two types.
Set equality is type equality
The power set is the type of subtypes.
The universe set is the set of all bit patterns.
Set intersection is interesting and does not appear in any language I know of, other than subtyping.

I am not certain what the axiom of choice says when applied to types; it is probably rather profound.