Lambda the Ultimate

Thanks Miles, that is a great example. I didn't realize the Scala did it so nicely.

Now what about example two? Is there an idiomatic translation into Scala?

Example 2 can also be done with implicits

class A {
  val f = 42
}

trait B {
  def f : Int
  def g = f * 2
}

implicit def a2b(x : A) = new B {
   def f = x.f
}

val x : B = new A

println(x.g)

I suspected this would be possible in Scala, thanks a lot for showing me how to do it.

Sorry for spamming here. I just realized Example 2 can be done in Scala with structural typing. It's a variant on the implicit a2b version but with a structural type as the input to the implicit.

class A {
  val f = 42
}

trait B {
  def f : Int
  def g = f * 2
}

implicit def withf2b(x : {def f : Int}) = new B {
   def f = x.f
}

val x : B = new A

println(x.g)

I promise this is the last time. :-)

This is cool. Is there a way to name the anonymous struct:
i.e. {def x : Int}?
Otherwise I fear it might have troubles scaling to non-trivial examples.
So far my favorite (as if it matters) is the sol'n you proposed using implicits.

Yes, in Scala you can create aliases for types. E.g. "type WithX = {def x : Int}". This is strictly a type alias like a C's "typedef" or Haskell's "type." It does not define a new type like Haskell's "newtype."

Too often there is some implied relation between members and 'just give me something with these two fields' is insufficient.

A classic example of this is Object.equals and Object.hashCode, both of which rely on each other to preserve invariants of the standard libraries. There's nothing in the language to ensure that when one is overridden, the other is as well (nor that the combination actually preserves the intended invariants).

This is a good point and a pervasive problem with programming: all of those unverified (and worse often unstated) assumptions in APIs.

I think perhaps if we allowed contractual specifications in traits and interface, could help with this. This way we could have something like:

trait Hashable
{
  interface {
    bool Equals(x : Hashable);
       ensures { 
         result <-> x.Equals(this);                         
         result -> HashCode() == x.HashCode(); 
         x == null -> result == false;
       }    
    int HashCode();
  }
  invariants {
     this.Equals(this);
  }
}

I think perhaps if we allowed contractual specifications in traits and interface, could help with this.

Maybe. I think though that current mainstream languages don't have too much of a problem with those assumptions. You're already doing OOP, so the most onerous invariants can be contained within the class. I also think that requiring the programmer to explicitly inherit from a type is (usually) a sufficient contract that they won't foul things up (more than usual).

Currently I am of the opinion that the most practical approach is to distinguish between an interface (where an object must simply contain the members) and a class (where an object must explicitly inherit from or be the class). This can be pretty easily implemented within a structural type system. The behavior doesn't vary too much from what most programmers know, but provides a good amount of expressiveness.

an awesome (as in superb) idea.

...what does your example mean? I think if you spend time looking into it, you'll find this far, far more complicated than it first appears. If the assertions of invariants in your code are to be ensured statically, you get to deal with theorem proving and the decades of accompanying research. If instead they're enforced dynamically, you get to deal with object contract checking, with precedent in Eiffel, PLT Scheme contracts, Spec# and the Boogie methodology. Dynamic contract checking has lots of fiendishly hard problems like how to check undecidable or computationally expensive properties, *when* checking should be performed, what guarantees are provided, and when/where are programs allowed to temporarily violate invariants (which is crucial).

We all want the ability to express and (ideally) mechanically verify properties of programs. Example programs without semantics are a good starting point, but they only get you so far.

Actually I have spent some "time" "looking" "into" "it" ... but I don't claim to be an expert ;-)

I think calling the implementation issues "fiendish" is overstating it a bit. I omitted the semantics because there are already a large number of working solutions to choose from.

I think that most people who have studied the problems of contract verification eventually accept that no solution is going to be perfect. I am operating on the premise that any solution is better than just writing assumptions in your docs.

The "Concepts" feature in the new C++ standard is very much like this.

...axioms in concepts are just fancy documentation, they are never checked, neither statically nor dynamically. Nor do they even have a defined meaning.