Current mood:	tired
Current music:	None

Lambda Datatypes and Aspect Classes
Time for another post. I have work in the morning, so mainly I'm going to address a comment on my first post. I also have an idea thats completely incomplete, and I'm tired enough to not want to solve it now.
Its a fairly simple idea with many complex reprecussions. One element of Object Oriented Programming is Inheritance. Some languages allow you to inherit from only one class, and some allow you to inherit from more than one class. Dual inheritance is not a problem until you consider what happens when both super classes share a common super class. Both classes are initializing the same base class, and no one knows which one is dominant or passive, and how to keep both classes from changing the base class in ways that are incompatible with each other.
(I apologize for the confusion those last few sentences have; this is a common CS problem, and I'm too tired to explain in detail now. Just ask for a better explanation if you don't fully understand)
For those familiar with Aspect Oriented Programming, this might make alot of sense. First some background however. I have been working on a small framework for some very simple IRC bots. There is a simple base class that all IRC bots have, that already contain the code to make a connection to an IRC server, stay connected, join and part channels, and optionally execute arbitrary code for debugging purposes. I then came up with several tasks or aspects a bot might want to perform, tasks such as randomly saying thing, quotes, phrases, single words, logging the chat and compiling statistics, or providing authentication for operator status. (This server doesn't have any service bots.) I want to be able to create aspect classes that a Rabid Developer (my nickname for programmers who uses lots of premade code and glue it together to create all sorts of complex programs) can take to mix and match the different pieces he needs. These would be classes that have limited functionality, such that they can only touch the base class in specific predescribed ways. The Aspects would need to be written by the base class developer and by no one else, so that he(they) can ensure they are all compatible with each other, or at least document which ones don't work with which other ones. Other than this, I have this mental block trying to figure out what some of these rules should be.
Now here is the part where we answer a few of your letters.
Nightstrike9809 wrote: Its a truly interesting idea but I feel I am missing the true point of this, how would you implement Lambda Datatypes?
This is no different than template functions in C++. However, from a semantical point of view (and not necessarily that of the compiler) I am thinking of creating an Interface to borrow a term from java for a Function<...> that can have any number of generic data types, but is forced into using it. There would then be a required method __func__(...) that could take any number of parameters (possibly defined by the generic datatype decleration) and to borrow from python, this would make all objects implementing this interface "callable" and capable of being passed arguments, returning arguments, etc....
You can figure how badly you want to kludge your language's syntax from here.
As to why I would want to torture myself to provide such odd functionality, its the same argument as using templates/generics in the first place. From my academic high point, I feel that the compiler should spot as many errors first, which translates into better syntax error detection on the IDE's behalf as well. Anyone familiar with Eclipse should understand how much this can be a help (or hinderance). The basic idea works like this though. I have my callback function. When its called, its called with arbitrary data some other programmer in my project team passed to me. I want a garauntee that this chunk of data implements methods X, Y, and Z. By using generics, I can tell this peer of mine, I will only accept objects that implement these methods. When I pass the callback to the connect method of a widget, I might pass it like this:

widget.connect<String>(some_callback, "From John")

void some_callback<D implements String>(Widget widget, D data) {
other_string = data + " with love";
}

Thats it for now, I'm tired, Good night.