Y Combinator

There is so much information on the internet that I cannot possibly study everything worth knowing. Everytime I read an article I take a risk. I am spending five minutes of my precious time in an attempt to get some sort of benefit. Thus when it comes time to pick and choose what I read I generally avoid things that are poorly named. For example "lambda". Any language where you actually have to type out the word lambda has a serious problem. The word lambda has no English meaning. The reason that the lambda calculus uses the lambda symbol is because in math people like to use single-character identifiers. I'm sure that someone could either come up with a better name for clarity or a better symbol for convience (Haskell uses a slash).

Thus when I see something along the lines of "Y Combinator in language X!" I know that I can safely ignore it. Anything named Y Combinator can't be useful. Except that it is. Of course the article named "Y Combinator in language X!" never meantions what the Y Combinator is or why I would want it but this tutorial does. I don't even know C# but I can see how this would be useful.

In object oriented languages the "this" or "self" keyword is used to refer to a method's object. Cahalang will have something similar for functions. It will be easy to implement because that address is already stored at [edx+4] when the function is called. Now I just need a name for it. The top two contenders are "this" and "$$". The argument for "this" is that it is familiar and works well. The argument against is that people are going to want to use it as a name for the first parameter of functions to simulate object oriented methods. The argument for $$ is that it works well with a feature that will be in 2.0: parameter names of implicit parameters for functions. So rather than writing:

(int x)->(int y){ y=x*x }

you could write:

{$1(int)*$1(int)}

or maybe:

{$1(int)*$1}

With $$ as the function name a factorial function would be:

{ if $1(int) {$$($1-1)} else {0} }

Hmm... not really beautiful code. Maybe with the types specified would look better here:

(int n)->(int f){if n {$$(n-1)} else {0} }

or if I made the if/else syntax into a simple tuple:

(int n)->(int f){if n, $$(n-1), 0}

Still not great but this isn't a functional language so I'm ok with it for now I guess.

Actually I think that I know the problem here. The problem is that the syntax for implicit parameters is too long. Rather than saving space it making things longer. What if the square function could be written like so: {$1*$1} But then how do we know that it should only takes an int without some fancy algorithm? Well since we are probably using it soon, probably passing it to a function, we have some context. I think that this parrallels how I am going to handle boxed tuples vs class literals, vs denoted classes. Maybe functions with malformed types get their type from the first time that they are assigned to a variable or called with arguments. I believe that this is similar to the var keyword in C#, where variables get their type from their initializer. I think that this is workable. Good thing that my language is simple.

So here is the plan:

1.0: type inference only for the return values of functions that do not have type specified.

2.0: type inference for implicit parameters, variable declarations, etc...

3.0: even more type inference.

I definitely do not intend to go all the way, because explict types are good for providing context in certain situations. However I do see the benefit of type inference. I use it in C++.

Here is the signature of on of my functions in my game:

template
void MovePoint(Point& point, World* world, Direction direction, EvalFunc is_good)

EvalFunc is always passed a function that takes a Tile* and returns a bool. I just figured that templating it would be easier than figuring out what the C++ function pointer syntax was. In my language it would be:

(Tile@)->(bool)@

of course you would probably be passing it by value, so you would drop the final @.