Lambda the Ultimate

I am not sure I understand. Can you elaborate?

Is used as a proposed example of a concept, with two constraints. it says nothing about the types of e1 and e2 just that both method calls should make sense for them. So this constraint is only realted to use of e1 and e2 in such statements.

On the matter of making progress: But thank God, Stroustrup finally wakes up and smells the coffee!

Also kudos to Stepanov for convincing Stroustrup to get his acts together.

You know, someone may know about high order types etc. etc. and decide to produce a streamlined design note.

But I agree: One shouldn't confuse this kind of documents with research papers.

Currently, if you want to use functional combinators, e.g. those defined in the <functional> standard header, you must define your functions as function objects. Standard functions just won't work. This is because the combinators must have access to the types of function arguments, and you must explicitly provide such access using typedefs such as argument_type. As a result, you can't use all the standard functions, instead you must wrap them as objects (that define these typedefs). If you do want to use one of the function objects as a function, the syntax becomes very weird:

foo()(3);

All of this is very annoying since the compiler obviously has access to all the required information.

.. Stroustrup doesn't know any type theory.

See my notes on the generic programming comparison paper.

This proposal is very weak: its type orientation is akin to object orientation and flawed by the same covariance problem. The correct way to handle this kind of thing is well known and used in SML and Ocaml via the module system.

Stroustrup has to resort to inheritance to handle two types as required by the very concept the proposal is designed to support -- iterators. It is clear the proposal, by attributing properties to individual types, cannot work properly: iterators, like vector spaces, are characterised by TWO types:

vector space: scalar type S, vector type V iterators: value type V, iterator type I

and associated functions with axioms .. which are constraints on the functions.

[From the example:]

"bool b = e1<e2;"

All this does is tell you the programmer was too lazy to pass the comparison function required. This is not a type constraint, nor is it an axiom, but a hack to compensate for the way templates are instantiated in pass two using Argument Dependent Lookup which in turn is a hack because there is no module system to pass bundles of arguments...

.. of course in C++ there really is a convenient vehicle for a module system -- classes -- and that should have been used instead I think. ** Classes can contain typedefs to several types, and static functions, and so can emulate modules.

function x() { ... }
x(); // Invokes the function
var y = x;
y(); // Invokes the same function

Using x() and y() is exactly the same. OTOH consider a scenario where x is a method and an object z:

z.x(); // Invokes method x for the instance z
var y = z.x;
y(); // Invokes method as a function, in JS this is null

The problem here is that y is assigned the value of the property, not the instance/property pair. You might say that the delegate construct in .NET was invented to deal with this issue. Obviously, we could envision a change to the PL spec so that y is assigned the instance/property pair, but then what would should happen in this case:

a.b = z.x;
a.b();

Would the invocation of the method be for the instance a or z?

One place where the problem was especially pertinent was list comprehensions. Consider a list of objects:

os.for_each(f); // invoke f on every object in os

How would I invoke a method on every object? If I write:

os.for_each(a.b);

it would invoke the function referenced by b without the instance a. Also, what should I do if I wanted to invoke a method for each object in the sequence?

The solution we used in BeyondJS is the Function.from function. It takes an object reference and a method reference and returns a function that invokes the method on that instance, e.g.:

var y = Function.from(z, z.x);
y(); // calls z.x()

You can also write it as:

var y = Function.from(z, "x");

either way, it feels like a bit of a hack.

Stroustrup's solution, when coupled with something like binder1st would address this issue, OTOH it could also likely break lots of existing code.

Oh yes, obviously this would be a none issue if we just went with dynamic dispatch instead of methods in the first place. You can even say that the new call syntax is a dynamic dispatch limited to the first arg.

1/ it was based on templates. In XL, I use generic types without arguments, but with validation to represent concepts

2/ It was combined with the ability to declare "true" generic type, that make functions that use them generic automatically.

I'll probably write to him to point that out.

See http://cvs.sourceforge.net/viewcvs.py/mozart-dev/mozart/xl/TESTS/instantiation/minimax_vararg_generics.xl?rev=1.7&view=markup for an example of what you get once you have these capabilities. In the example, you declare a "concept" (to use Bjarne's terminology) named "ordered". It's not because you fail to pass a less-than, as someone else suggested, because that assumes an Ada-like model of explicit instantiation, where something like the STL cannot be constructed.