Summary
In of itself not that exciting, but it can enable some interesting paradigms.

---

Advertisement

I was looking for a solution to two problems. First I wanted an abstraction sufficiently powerful to allow programmers to develop their own "const" checking mechanism (or its inverse a "mutable" checking mechanism) without hard wiring such a thing in the language. Second I wanted an abstraction which a programmer could use for checking at compile-time (or at least rely on the type-system) whether or not a variable had been "initialized".

The problem is that hard-wiring things like const, or non-null pointers, or regions (ala Cyclone), introduce significant complexity into a language design. These are powerful abstractions, but because they are hard-wired they are inelegant and contribute to overall language complexity and its inability to adapt to new paradigms.

A clue to a possible solution occured to me recently when examining Cyclone. A memory-safe dialect of C. It uses the type-system (at compile-time and run-time) primarily to assure that the program is type-safe.

What occured to me, was that the Cyclone group developed a more sophisticated static type system. What I want to see is this kind of system generalized so that a C dialect can have an easily extended type-system. (I have this nagging feeling that I am just reinventing OCaml in small steps, but at least I am approaching it as a software developer and not an academic simply interested in lambda calculus and type-safety proofs).

At this point is where my flight-of-fancy begins. I believe that a language where all variables (including the "this" pointer) can have their type redeclared, would be sufficient to cover many abstractions such as "const" or "is-initialized". Consider the following pseudo-code:

class Initialized<type T> {
  subtypes {
    T;
  }
}

class Const<type T> {
  subtypes {
    T;
  }
}

class FuBar {
  public 
  {
    def Init() { 
      assert(!is_initialized(this)) 
      reassign_type<Initialized<FuBar>>(this);  
    } 
    def Fu() { 
      assert(is_initialized(this)) 
    } 
    def Bar() { 
      assert(is_const(this)) 
      assert(is_initialized(this)) 
    } 
  }
}

FuBar a;
a.Fu(); // boom, not initialized
FuBar b;
b.Init(); 
b.Fu();
b.Bar(); // boom, not const
Const<FuBar> c;
c.Init();
c.Fu();
c.Bar(); 

This is just the rough beginning of an idea, but perhaps someone can tell me more about ML or other languages with flexible type-systems and how they compare with these kinds of abstractions.

Talk Back!

Have an opinion? Readers have already posted 10 comments about this weblog entry. Why not add yours?

RSS Feed

If you'd like to be notified whenever Christopher Diggins adds a new entry to his weblog, subscribe to his RSS feed.

Digg | del.icio.us | Reddit

About the Blogger

Christopher Diggins is a software developer and freelance writer. Christopher loves programming, but is eternally frustrated by the shortcomings of modern programming languages. As would any reasonable person in his shoes, he decided to quit his day job to write his own ( www.heron-language.com ). Christopher is the co-author of the C++ Cookbook from O'Reilly. Christopher can be reached through his home page at www.cdiggins.com.