Lambda the Ultimate

Well, its been really quiet around here, and I have been working on the design of my own programming language(like probably half the rest of the people here...), and so I figured I would bounce some of my ideas off people here and find out why they're wrong :)

The type system is mostly what I'm curious about opinions for. It starts with records or structures(however you want to look at). The programmer can make a type like so:

type complex {
	a as real;
	b as real;
}

Now, when it comes to functions, they determine type compatibility by a pattern matching mechanism. This pretty much means functions can be overloaded, and matching is on all arguments, which could be as simple as a type name, or it can merely look for a member of the record to match on, or any other number of patterns.

I'm not sure how creative this is, but a couple of my motiviations, I like pattern matching and I think type inferencing stuff is cool too, but for me, coming up with the entities I want to manipulate is part of how I write code and think of the design. So the idea of maybe "naming" the patterns, and calling that a type has appeal to me, and then overloading functions with different type signatures/patterns seems like a lot of what I want.

One other slightly oddball feature is that in an argument declaration, a function can delcare "with coercion", in which case if an argument doesn't match any pattern, a single parameter function is sought out that starts with the character '!' which denotes that it can be used for conversions between types. This may be a bad feature or hard to implement, but I like the idea of being able to selectively allow something like it(at the programmers request of course).

As to object oriented programming, I'm going to have lexical closures and hashes, which may not make the OO people happy, but it seems to get a lot of cases.

The rest of the language is a bit imperative feeling, but even the control constructs return values, and it has anonymous functions. For algebraic expressions, the language allows functions of two parameters to be called in an infix notation, and since function names are allowed to range over about anything you want, this makes it easy to do operator overloading(without making it a special case), but it also means that I don't really have precedence(although I'm still thinking about that), which also adds a little uniformity with the built-in types, since several of them will have some operators meant to be used in infix form.

Here's a couple of more examples:

type phasor {
	r as real;
	theta as real;
}

function * phasor:(a as phasor, b as phasor)
{
	return (phasor:[a.r * b.r, a.theta + b.theta]);
}

Now, a function that wanted complex numbers(but didn't care whether they were in polar or rectangular form might be declared like so:

function dosomething '[phasor, complex]:(a as '[phasor, complex], b as '[phasor, complex])
{
    ... do something ...
}

A function that wanted a structure with a specific member might go like this:

function getnext 'typevar:(a as 'typevar:[next as ref 'typevar])
{
	return (a.next);
}

Okay, bad example maybe(lists are a primitive type), but still. The quote is used to denote that the type is allowed to range over anything that matches the partial pattern to follow. In cases like this where it shows up multiple times, the same value must be substituted throughout. In fact, the use of the same "variable"(type or otherwise) even in different arguments in the pattern declaration requires the values match. I guess these are more like "logic" variables than anything.

I'm still working on syntax, especially for the pattern matching, but this is just to give you an idea of my current state of mind.

Any feedback on this is appreciated. This language is just me doing it for fun and the experience of designing a language. I'm using things on the edge of my understanding, but I'm also trying things that I think I would like to solve problems that bug me. So be harsh :).