Bug Vanquisher: Computer Theory

More Horrors

Sun, 11 Nov 2007 10:48:02 GMT

Right off Brad Abrams blog!

Isn't it odd that...

From the files of things that make you go “hmmmm”.
System.Exception (the base class for all exceptions) is indeed an exception: throw new Exception ()
But…
System.Enum (the base class for all enums) is not an enum: typeof (Enum).IsEnum == false
System.ValueType (the base class for all ValueTypes) is not a ValueType: typeof (ValueType).IsValueType == false
System.Attribute (the base class for all custom attributes) is not a custom attribute [Attribute] -> compile error
...
# Brad Abrams said on May 10, 2004 9:21 PM:
Oh, and I just noticed that System.Array is not an Array:
typeof (Array).IsArray = false...

This again proves my point that root in a hierarchy is always special. The rules used to build that hierarchy do not apply to the root, breaking the constraint system.

Building The Tools

Sat, 03 Nov 2007 08:17:58 GMT

Connected with the extremely twisted last post, consider the methods of programming the machines we have seen since 1943. Let us build a hierarchy of tools we use for programming and how they must have come to be what they are right now.

ENIAC was programmed using rewiring and four years later than that for ROM function tables. Only six women programmed it. Compilers existed long before that. Assemblers came out a little late. We see the first portable programming language in 1972. High level languages soon follow, my first love enters the picture, the world is swarming with all sorts of OO and high level languages by mid 1980s. Declarative languages add to the mix at this time too. Right now, we are partying on very expressive programming environments.

Grab Visual C++ compiler, the language I use most. Or better yet csc.exe. Consider how that compiler itself must have been built. If you have seen rotor, you will know that csc itself is written in C++. Therefore, it will require a C++ compiler, definitely cl.exe because of this. Put cl.exe into the interrogation box and ask the same question, who is your mother? It will say cl.exe with a build number or version number smaller than mine.

But this isn't a chicken and egg problem because it must have begun at the first build of cl.exe. Let's say it was compiled with a C compiler. Then, who was the mother of that compiler? Some earlier C compiler. Who gave birth to that first one? An assembler is the most likely answer, say masm.exe. The question repeats itself, only this time in the context of assemblers. First assembler would have built the second and itself must have been built by some machine which required programming by re-wiring (only a guess, I have no proof :)).

This machine may have built a few assemblers. Those assemblers must have boot-strapped themselves and eventually one of them may have become powerful enough to build a C compiler. (Actually, from what I just read, it goes way back than that assumption. C was a transformation of B which had a compiler who origin was in BCPL's compiler. But let us again skip the details and say BCPL compiler may have been built with an assembler.)

This early compiler must have boot-strapped itself too and built more powerful versions of it and other compilers. Definite proof for this is the C-front, first compiler for C++ which produced C code as a result which was compiled and executed. The process has been bootstrapping itself ever since and giving rise to more and more language compilers of all sort and hence, we trace the path from root to csc.exe!

If you look carefully, you will find my favorite data structure here too. Conceptually, ENIAC or something similar lies at the root. At every level, a transformation program (assemblers/compilers) is either boot-strapping itself or increase the set of available transformation programs at the next level. From ENIAC, we move to a decent number of assemblers, which boot-strap themselves to assemble BCPL (again, my hypothesis) compiler. BCPL compiler compiles B compiler which boot-straps itself and generates a C compiler. This C compiler again bootstraps and really makes the bomb go off by giving rise to other C compilers and C-front. And again, the rest is history.

Abacus->ENIAC->Assemblers->Compilers->Declaratives

Sat, 03 Nov 2007 08:09:06 GMT

It must have begin with the first ever Abacus. One of the earliest machines to help us compute. Although primitive but really effective. Even if you do not include a concept of '0' in your numerals.

Over millennia, we moved forward to faster, automated computing machines. ENIAC was born. But limited in programmability and never reproduced. Remember it is still 1943 and the design has been locked. First ever compiler makes to the front for Mark 1 in the same year. No stored program concept till 30/06/1945, machine programmability is very limited. Universal Turing Machines are still 4 years away. Even with the concept of UTM in 1948, it takes one more year for human eyes to see the first ever symbolic assembler.

Therefore, let me change the title to

Abacus->ENIAC/Compilers->Assemblers->Declaratives

Let's fast forward the boring details and link leaden paragraphs to 1972. This year is significant because it marks the turning point in programming languages and will change the flow of events forever. We see 'C' being born and the rest is history.

I am laying the ground for another post with this extremely brief history, many twisted details (some by me, for brevity's sake), and left out milestones (again my apologies).

Happy Turing Day

Mon, 25 Jun 2007 06:55:02 GMT

It's a bit late (actual date is 23^rd June), but better late than never.

The horrors within!

Sat, 02 Jun 2007 13:16:08 GMT

Have you ever given thought to the C# type system (For all purposes I will only say C# whenever I mean C#/VB.Net/C++-CLI/whatever languages.)? Ever opened a bank account which requires a reference of someone having previously opened an account at the same bank? Admitted to a school which requires previously students' parents knew you? Got membership of a club where someone else had to recommend you? Or don't forget the politics? Know what Russell's paradox is. If every set is a subset of universal set, of which set universal set is a subset then?

Each of these examples has a main theme, the idea of a tree structured hierarchy. You must start at the root to enter the system. There must a path from you to root or a relation to root in order to be part of the system. The root is special. It has no parent and without some external help, it would not even be a part of that system. The system is inconsistent specifically for the root. You need boot strapping to make root part of the system. Given the rules which apply for something to be part of the system, root will always violate these rules. The invariants which hold for every other thing that is part of the system, root is the sole entity for which they do not hold. Let me explain all these points with reference to the questions I asked.

C# type system: C# requires the each type must have a parent. If you do not specify a parent, it will implicitly inherit it from either Object if you define a class or from ValueType if you define a struct. ValueType in turn inherits from object. Therefore, whatever the construct you always inherit from Object. Java and many other languages suffer from the same problem. In my knowledge, C++ is the only language to avoid this problem by not requiring every class to inherit from one single class. Now, consider my claims.
- You must start at the root to enter the system. There must a path from you to root or a relation to root in order to be part of the system.
  As said earlier, no matter how you define your type, you always inherit from object.
- The root is special. It has no parent and without some external help, it would not even be a part of that system.
  object is special. It is the base class for every other class in C# but has no parent itself. Take a look at the disassembly we can peek at with reflector.
```
[Serializable, ComVisible(true), ClassInterface(ClassInterfaceType.AutoDual)]
public class Object
{
    // Methods
    [ReliabilityContract(Consistency.WillNotCorruptState, Cer.MayFail)]
    public Object();
    public virtual bool Equals(object obj);
    public static bool Equals(object objA, object objB);
    private void FieldGetter(string typeName, string fieldName, ref object val);
    private void FieldSetter(string typeName, string fieldName, object val);
    [ReliabilityContract(Consistency.WillNotCorruptState, Cer.Success)]
    protected override void Finalize();
    private FieldInfo GetFieldInfo(string typeName, string fieldName);
    public virtual int GetHashCode();
    [MethodImpl(MethodImplOptions.InternalCall)]
    public extern Type GetType();
    [MethodImpl(MethodImplOptions.InternalCall)]
    internal static extern bool InternalEquals(object objA, object objB);
    [MethodImpl(MethodImplOptions.InternalCall)]
    internal static extern int InternalGetHashCode(object obj);
    [MethodImpl(MethodImplOptions.InternalCall)]
    protected extern object MemberwiseClone();
    [ReliabilityContract(Consistency.WillNotCorruptState, Cer.Success)]
    public static bool ReferenceEquals(object objA, object objB);
    public virtual string ToString();
}
```
  As I have highlighted, object has no base class. Even the IL does not have an .extends directive.
- The system is inconsistent specifically for the root.
  If we try to compile the above define (suitable completed and removing internal dependencies for the sake for demonstration), C# compiler will derive it from object defined in mscorlib.
- You need boot strapping to make root part of the system. Given the rules which apply for something to be part of the system, root will always violate these rules.
  Since, object cannot be defined in any HLL, we need something external to the targeting languages to define object. If we insist on defining it in C#, it will no longer be the object we intended it to be.
- The invariants which hold for every other thing that is part of the system, root is the sole entity for which they do not hold.
  There is one invariant no type can violate. It must have a single parent. object has no parent
I am going to clump all other example together as they are not related to programming. However, banking deserves special attention.
Open a bank account/Get admitted to a school/Club membership/Politics
- You must start at the root to enter the system. There must a path from you to root or a relation to root in order to be part of the system.
  You must know someone who is already a member. Someone must invite you into the system, you cannot enter solely on yourself.
- The root is special. It has no parent and without some external help, it would not even be a part of that system.
  
  This is easiest to explain in terms of a bank account. Consider, if everyone needed a reference to someone who already had an account, how could the first person open his/her account in the first place? Something external to the system that transcends the requirement that you must know a person beforehand who is part of the system must have played a factor.
- The system is inconsistent specifically for the root.
  If you demand relationship, root will fail the test and the whole system collapses.
- You need boot strapping to make root part of the system. Given the rules which apply for something to be part of the system, root will always violate these rules.
  Root does not know anyone who previously had an account in a bank, he/she should not be allowed to open an account, but the system requires at least one member who will introduce others to the system.
- The invariants which hold for every other thing that is part of the system, root is the sole entity for which they do not hold.
  System must not require root to fulfill relationship to some parent in order to bootstrap in the first place. Every object must have a parent, root is excluded. Period.

All these are examples of chicken and egg problem. Joel Spolsky has a very nice post somewhere (I found the link, it is here) buried in his valuable archives which discusses the same problem from marketing point of view. He talks about things like, a new application requires a large customer base to be economical and have sufficient customer feedback to achieve a high quality but most customers don't have huge buying strengths and most won't waste money on something that just came out of company yesterday.

Russell's paradox asks for a set which is ever bigger than the universal set. The 'one who is all'. That set must contain everything yet must be contained in a set which is a proper superset.

Consider another example that just jumped out in front of me. A class of languages which can be recognized by a particular machine can always be defined in terms of a sort of meta language. When that describing language is fed to this machine, it fails to recognize it. All regular languages can be defined in terms of any language which will not be regular itself. Next, PDAs can be defined in language which PDAs will never recognize but TM/PM/nPDAs will. Turing machines will never recognize the language which describes them. In general, when we define a meta language to encompass all language a particular machine can recognize that language will transcend that machine. This can be proven by Cantor's diagonal argument.