archives

Mutable variables eliminated from .NET

Redmond, WA: At an unusual press conference held this Sunday morning, Bill Taylor, Microsoft's General Manager of Platform Strategy, announced that after much research into the causes of security holes and instabilities, Microsoft will eliminate mutable variables from the .NET platform and its languages, including C# and VB.NET. "One of our top researchers found that mutable variables were the major root cause preventing us from achieving the great user experience we always strive to deliver," said Taylor. "Once we realized that, eliminating them from .NET was a no-brainer."

Given that this announcement was made on a Sunday, reactions have been limited so far, but one prominent VB.NET developer commented that "Compared to the switch from VB6 to VB.NET, this ought to be a breeze." A C# developer was heard to say, "After anonymous delegates, monads shouldn't be a problem."

To ensure wide penetration of this significant update, Microsoft will be issuing updated Windows CDs to all licensed customers, free of charge. The new CDs can be identified by the distinctive holographic "Haskell Inside" logo, featuring a holographic version of this portrait of Simon Peyton-Jones, grinning from ear to ear.

LtU readers are encouraged to share any inside info they may have about this move!

By Anton van Straaten at 2007-04-01 16:31 | Admin | 7 comments | other blogs | 22264 reads

Defining Types not as Classes but as Mathematical Sets

Hi, long time browser, first time posting.

My background is largely in the C family of languages (specifically C, Java, and C#) but I've been reading into dynamic languages and it got me thinking about the advantages of dynamic type systems and bringing some of their advantages into the static world without sacrificing the bonuses static typing brings. An idea popped into my head when I asked what if an object's type and an object's class were different things and variables only refered to the former and were ignorant of the latter? Furthermore what if you viewed a type as a mathematical set of methods defining one method as equal to another method when their names and signatures are the same?

For example, in such a system the following Java code wouldn't result in an error.


public class A { // Implicitly defines Type A { int op1(int) }
 public int op1(int arg1) { return arg1; }
}

public class B { // Implicitly defines Type B { int op1(int), int op2(int) }
 public int op1(int arg1) { return arg1 + 1; }
 public int op2(int arg1) { return arg1 + 5; }
}

public class C {
 public static void main() {
  A a = new B(); // Not an error since Type A is a [proper] subset of Type B
  System.out.println(a.op1(2));
 }
}

Essentially you get dynamic type membership and static type capabilities.

So I'm pondering:
Does this lose any of the benefits of static type checking? Does this introduce any complications that would prevent a compiler or interpreter from being created? And finally is it dynamic enough?

By William Davis at 2007-04-01 23:15 | LtU Forum | 5 comments | other blogs | 5889 reads