First Entry | Lambda Datatypes
Lately I have had a lot of interesting ideas for computer programming, and I finally decided, I should keep a journal of my ideas to share them with others and so that they can give me feedback on it. If I get good at keeping this thing up to date, I might even write a more personal friends only journal.

To give you hopefully faithful readers an idea of where this is coming from, my name is Yaakov, and I am a Computer Science and Engineering major at the University of Connecticut, which, if you haven't figured it out, means I live in the US. Hence, I make no apologies. Although I have known the fundamentals of programming since i was nine, I have only recently in the past year and half began taking programming seriously and wanted to explore more than just the BASIC material I have known till now. (Pun Intended). Most of my ideas involve creating a flexible language similar to Python or the POSIX Shell, that is also robust like Java, C#, and Objective-C, and (you can start laughing) low level enough for an operating system to be written in it. Simply put, one Operating System, One Language, One set of commands to memorize, and One ring to bind them all. (There will be room for other languages, and I will probably write more on this later, so save your flames for then. Thank you.) In the past year I've been programming in Java, and my first set of posts will most likely take a slant in that direction. Such as this one.

Onto the goal of this post. My current language of choice is Python. I've been using it for one of its common descriptions. It's a convenient glue between many different programs and libraries on my computer. It's designed around the whole 'nix structure so most of what is available to me is integrated very nicely. However, one thing has been pissing me off tremendously. Java is incredibly strict about its data types; so strict that I am garaunteed the second my fingers touch the keyboard what methods are available on the data that I am working on. Python can't do that. I don't blame it; I think it is a fine language in how and what it implements and why it implements it as such. This won't meet my goals. Compile time checking is as important to me as Garbage Collection. It ensures certain basic things programmers take for granted will work as intended without wasting programmer effort keeping track of many details. I'd love to hear about good uses for run time checking, but other than the case I will discuss later, I don't know of too many cases where I wasn't banging my head against the screen in frustration with python.

Abstract
The following proposition is intended to create a consistent structure that gives the programmer some of the benefits of Python's weaker data type declaration system without sacrificing compile time error checking. I will discuss one specific case now that I've run into with the pygtk libraries, and save the more general purpose for discussion later. This idea is also incomplete as of now.

Background
Some Object Oriented languages that require strict type declaration implement some system of template classes that can be compiled multiple times, each time handling a different data type. Java's system is a favorite of mine. Not only is it incredibly consistent and the compiler issues are hidden very well from the programmer (unlike in C++), it even lets you create a contract saying that all data types must implement a certain interface (i.e. a certain set of methods). Furthermore, some languages that implement procedural functions (such as C++) also implement templates for said procedural functions.

Theory
At a cursory glance, Python has many structures simiilar to C++ and Java that appear as if they could be controlled with better type declaration. Certain aspects (methods like __ge__(x)) could be moderated into a set of interfaces such as Numerical and StringLike (suggestions are open for better names). However in my discovery of the pygtk libraries and its implementations of signals I found a case that would be difficult to enforce strong typing. I will assume the reader is familiar with signals and event based programming. (If I get many requests going "Huh?" or the like, I'll put up an entry explaining this.) I can create a callback function with the signature:

callback(widget, data)

where data can be any arbitrary data that can be passed from the widget emiting the signal. This data is usually specified when connecting the signal to the emiter using the signature:

widget.connect(callback, random_data)

and random_data could be any type. In Java, this random data would have been passed as type Object which is the supreme ancestor data type for any class. However, inside the callback function, I would have to typecast this Object into my desired data type which results in run time checking. Queue templates, for the same reason Java 5 introduced them. Only this time, the templates apply to the method. I have a connect signature like so:

widget.connect<D>(CallBack callback<D>, D random_data)

and the callback is:

callback<D>(Widget widget, D data)

Simply put, our class methods can create their own arbitrary data types seperate from the template data types they are already working with. There is an obvious responsibility for programmer to keep the template names from colliding because our methods obviously inherit the template type namespace from their class. If I have the type T floating around already, my new type can't be called T, though D is a valid name. I call these Lambda datatypes because in terms of creating lambda functions, we are creating lambda functions that take a datatype as a parameter and return a function or class specific to that datatype. Obviously the overhead in treating it that way means the compiler will do things differently, but the concept is the same.
--fin--