Lambda the Ultimate

C++ supports covariant return types -- that is, class A can have function foo that returns a BaseClass pointer, and B can derive from A and override foo to have a return type of DerivedClass pointer.

Why couldn't this be extended to covariant members?

class Base {
};

class Derived : public Base {
};

class A {
protected:
    Base x;
};

class B : public A {
protected:
    Derived x;
};

With covariant members, this would make it so in instances of A, x is a Base, but in instances of B, x is a Derived. In vanilla C++, B's x would simply hide A's. All of A's code that B inherits using x should still work because Derived inherits from Base. Currently to do this you need boilerplate to take advantage of covariant returns:

class A {
protected:
    virtual Base& GetX() { return x; }
    Base x;
};

class B {
protected:
    virtual Derived& GetX() { return myX; }
    Derived myX;
};

Further boilerplate has to be written if you don't want x and myX to both be allocated in B, and you'll need to call GetX() everytime you want that member in your code rather than accessing it directly.

Covariant parameters would follow the same pattern although I'm not sure of a good use case for them other than for getting around C++ not having virtual operators (you may want to define an Assign member function to use in place of the assignment operator because it could be virtual and have it take a covariant parameter for what to assign to).

I'm curious if there are any OOP languages out there have tried to more strongly support the covariance relationship between classes. I've seen some variation in how classes inherit (whether for interface or code reuse) between languages but no difference as regards this behavior.

The slides from my presentation on the Cat programming language at Lang. NET 2006 are now online at http://www.cdiggins.com/cat/cat.pdf

I'm a bit nervous to be posting here, but I am interested in feedback from the many bright minds that visit here regarding an idea I've been considering for a while:
Here is my official blog posting on the subject

The essence is this:
"Under Condition Propagation missing information is explicitly noted and antecedently avoided. Rather than extend logic systems or stop execution at run time, the compiler in-effect ensures that expressions are never evaluated that do not satisfy the conditions. The logical implications of this are significant. Unlike null-like solutions, operators, and thus truth-tables, remain logically unaffected by the missing information. For example, the AND truth table remains in it's traditional, four entry, form. Each primitive operator may publish compiler meta-data regarding the conditions under which the operator is able to operate. With this information the compiler ensures that any conditions are resolved prior to evaluation. The compiler also propagates the condition meta-data to allow the developer to choose at what point prior to evaluation to resolve the condition. Logic, arithmetic, relational and other operations can all be defined in their true logical form, unaware of missing information because they will never be requested to deal with it."

I'm student thesis, and i'm interested in proofs of the following :
Show tha the functor F presrves pullback ????

F = Ox(1+_) : Set to Set
Where :
O is an arbitrairy Set
Set : category of set.

Thank you very much in advance

We hear this refrain time and again - "I can't stand the parentheses in lisp". Left to myself, I'd argue that lisp/scheme's parenthetical expressions are simple and elegant, but I do know some good programmers who stay away from lisps purely for syntactic reasons.

Not that I searched deep, but I didn't find any good existing solutions to the problem other than switch language to Ruby or Python and family, so I tried solving it myself and would like your comments on my solution to the lisp readability "problem".

I've described it here and put up C source code for the translator ez2scm on google code hosting as well.

In summary, ez2scm a source translator that translates an indentation based "ez" syntax to "scm" source.

Is there any language out there that can handle polymorphic replacement? First, to define replacement: If I replace A with B, all references/pointers to A now in fact reference/point to B. In C/C++, this is possible if A and B are the same concrete type. Either A can just be made equivalent to B, or B can be copied over into the same memory location as A. Either way pointers/references will now point to B. But what if B is a subclass of A? It may have added members. So simply assigning A to B won't work. Replacing B in A's space won't work either, because B may not fit, possibly forcing lots of stuff in memory after A to be moved, which would be pretty expensive.

The most obvious solution that comes to mind is copying all of B's parent class members into A's space, and then setting up a pointer to point to where the rest of B's members could be found. There would be some additional memory overhead, because every object would need to have space allocated for this pointer. Member accesses would check if the pointer was not NULL, and if so correctly setup indirect accesses (so there'd also be a slight performance cost when replacement occurred). This also of course introduces fragmentation issues. But the pointer would not have to be used in every case -- only when there was no space after As original spot.

In case anyone is wondering under what context I started thinking about this: language level support for undo. A convenient and easy to setup way of performing undo is to simply make a copy of an object as a backup, manipulate the original, and then if the user clicks cancel, set the original to the backup. This by itself doesn't necessitate replacing -- but it would be convenient for instances where user manipulations entail _creating a new object_. For example, a plot program has the option to plot data in 2D or 3D. Because the rendering of the two is so different and involves caching different data, the 2D plots and 3D plots are separate types that subclass from a master Plot type. When the user opens the plot's properties, they can click a checkbox to change between the 2D and 3D plots. If they switch from say a 2D plot to a 3D plot, assigning the original to the backup won't necessarily work because they may not be the same type anymore. So it'd be nicer if the backup could _replace_ the manipulated original. (This isn't necessarily the best design example, maybe someone can utilize their imagination to come up with a better one...)

By ranking the importance of the criteria below, you can use this program to help you choose between ten of the most popular programming languages today, Java, Visual Basic, C#, JavaScript, PHP, Lisp/Scheme, C/C++, Perl, Python, or Ruby.

Take a look at the page source to see how the determination is done. Feel free to object to the weights used in the calculation.

It's a bit silly, I know, but it made me grin so I thought I'd share.

The program for this year's Erlang Workshop is now available online at:

http://www.erlang.se/workshop/2006/

The workshop will be held in Portland, Oregon, on September 16.

Of special note this year is a 90 minute tutorial on "Large Scale Software Engineering with Erlang: Using Advanced Erlang/OTP" by Francesco Cesarini of Erlang Training & Consulting. This will be a good opportunity for software developers who have heard of Erlang to learn what all the buzz is about.

Registration before August 18 costs $85 for non-ACM members and $75 for students and ACM members.

Marc Feeley
General Chair of the Erlang Workshop

Hello,
I wrote a small Lisp interpretter for Ruby. It supports macros,
and is fully integrated with Ruby - lambdas are native procedures, lists are native Array objects
and so on. That required a few unusual things for a Lisp, like cdr/cons actually
copying the list, special function (send obj method args) for message passing.

There is hello-world code for webrick-based HTTP server in RLisp in examples/ directory,
so it's basically good enough for playing. And I guess it can be used to build
macro systems for Ruby - many people seem interested but don't know where to start.
Now you can start by playing with RLisp :-)

The code is here.
The documentation is only on my blog so far - 1, 2, 3. I'll try to get some real docs later.

Some of you my find this discussion (especially the cost estimates) interesting.