(* An OCaml comment. (* You can nest them. *) *)

Some infix operators:
Equality: =  (*though also used in Let-In for assignment*)
Inequality: !=
String concatenation: ^
Integer modulo: mod
Floating-point arithmetic: /. +. -. (* etc.; they all have extra periods*)

(* Let-In expressions *)
(* Vaguely imperative, less-indented style *)
let x = q in
let y = w in
q + w
(* Functional, more-indented style *)
let x = q in
    let y = w in
        x + y
(* Using tuple unpacking *)
let x, y = q, w in x + y (* we're not concerned with indents in this example *)

If-Then-Else:
if x then y else z

Lists:
[] (* Empty list*)
[1; 2; 3; 4] (* List literal *)
x::xs (* Cons operator *)
xs @ ys (* List concatenation operator *)

Tuples:
let triple = (x, y, z) ;;
Tuple types are *-separated and parenthesized: (a * b * c)

Functions:
(* Named functions *)
let add x y = x + y ;;
(* Anonymous functions; "lambda"s *)
let otherwise_nameless_add = fun x y -> x + y ;;
(* Recursive functions *)
let rec factorial = if n <= 1 then 1 else n*(factorial n-1)
    (* The "rec" is required; you can also include it harmlessly when declaring non-recursive functions. *)

Algebraic datatypes:
type expr =
    | VariableX
    | Negative of expr
    | Plus of expr * expr
(* Calling constructors *)
let sum = Plus(VariableX, VariableX) ;;
(* Declaring a generic ADT *)
type 'a list =
    | Nil
    | Cons of 'a * 'a list

Pattern matching
let as_string sum =
    match sum with
        | VariableX -> "x"  (* Yes, you could leave the "|" out for the first case, but I find that annoyingly irregular. *)
        | Negative(ex) -> "-" ^ (as_string ex)
        | Plus(left,right) -> "(" ^ (as_string left) ^ " + " ^ (as_string right) ^ ")"
Parens are unfortunately often necessary for nested match-es.

Types of somewhat interesting functions:
List.map: ('a -> 'b) -> 'a list -> 'b list
List.left_fold: ('a   -> 'b       -> 'a       ) -> 'a  -> 'b list -> 'a
(*               accum   list item   new accum     init              result
                (----------"reducer"---------*)

Now, I’m a would-be language designer. Programming language theory fascinates me, and to that end I’ve read a number of books on different languages to try and get a feeling for all the various approaches and paradigms. I’ve also read many interesting blog posts found via proggit (and some via Lambda the Ultimate) which argue about language issues.

From all this, I’ve reached some conclusions which I’m going to try and lay out in a series of blog posts.

In this first post, I’ll cover:

The Problem of Delimiting Blocks

All modern languages are block-structured. (Thank you Dijkstra!) That is, code segments are semantically and syntactically organized into a tree. Let’s start with an example of some code in a Blub-average of today’s most popular languages:

class Foo(Object)
{
    void bar()
    {
        if (baz)
            quxx();
    }
}

The first problem we have is which brace style is the “Right One”. This is a perennial holy war. The style in this example wastes lines just for parentheses. On the other hand, it makes it very easy to perceive the block structure of the code. On the gripping hand, in practice, programmers don’t really care about the braces (except when the compiler gives a syntax error about them being wrong), and instead pay attention to the indentation. Secondly, we have the sub-problem of whether one-statement blocks should have braces around them; we have clarity and maintainability (what if the block expands beyond the one statement and someone forgets to add the braces? In many cases, this leads to subtle bugs the compiler does not warn you about.) versus wasting space and causing unnecessary scrolling. At any rate, we are led to the obvious question of: Why not use the indentation programmers insert anyway to delimit blocks and do away with the braces altogether? And indeed, some languages have tried this. The posterboy is Python (my current favorite existing language).

However, this solution has problems of its own:

1. Copy-pasting code into environments where indentation is not preserved (e.g. some online forums) causes it to become unintelligible (well, in practice, one can apply some heuristics and try and re-indent it manually, but there’s no way to ensure you got it exactly right, and if the code is long enough, it’s a real PITA; whereas code using braces can be automatically re-indented by several tools)
2. As one sees every so often in the Python community, there are people who harbor unreasonable hate towards syntax-significant indentation. From what I understand, most of these people have bad memories from some early version of FORTRAN and their fear is completely irrational. But if you want your language to be a very popular one, you’re probably going to have to accommodate these people.
3. We’re still left with the second code formatting holy-war of spaces vs. tabs as the indentation character. (BTW, have you seen *NIX‘s default tabstop of 8? Personally, it makes my eyes bleed.)

Of course, along with braces are their friends the semicolons, and they annoy the heck out of me; they’re just plain unnatural. I should not have to always remember to end a line with anything other than a linebreak, because 90% of the time, statements are only one line long; the other 10% are the ones I should have to type extra characters for, and only then after considering refactoring the line so it’s more readable anyway. This is basic Huffman coding people! Optimize for the overwhelmingly common case, not the exceptional one. (If this was a research paper, I would back up this 90-10 distribution with some empirical statistics, but since this is just a blog post, I’m not gonna bother.)

So, in summation, semicolons and braces are bad design choices. Eliminating the semicolons is relatively simple. As for the braces, our choices for what to replace them with are the off-side rule (i.e. syntactically-significant indentation) or begin-end keywords ala ALGOL or Pascal. Though I personally prefer the former, I opt for the latter due to the aforementioned issues with the former. Now, does this actually solve our problems, or is this a meaningless textual substitution? We’ll get to that in just a sec. There is a downside to vanilla begin-end though, and that is that it looks retro/outdated (i.e. like Pascal) or like a scripting language (using the pejorative connotation; i.e. like sh or BASIC). However, if we do it intelligently, like Ruby does, we can reduce the resemblance and make the substitution meaningful. All we need to do is realize that the begin keyword is technically superfluous and that we can force end to always go on a line of its own. Here’s an example of code in this style:

class Foo(Object)
    void bar()
        if baz
            quxx()
        end
    end
end

Advantages:

• No dangling else problem as long as you have a elif construct.
• Only one indentation style (Well, you could not indent the ends, but since they require their own line, there’s no particular reason not to.)
• No space is wasted compared to the more compact of the 2 main brace styles.
• The required ends solve the “what if this one-line code block grows to multiple lines?” problem

Now, in Iguana, I plan to alter this just slightly by allowing 1-line blocks to use colons and skip the end keyword; this let’s us re-special-case one-line bodies without any ambiguity or strain on the parser while continuing to avoid the multiline growth problem. Here’s what this looks like:

class Foo(Object)
    void bar()
        if baz: quxx()
    end
end

Of course, in this particularly simple example, you could also write it like this:

class Foo(Object): void bar(): if baz: quxx()

But I would hope your code reviewers would thoroughly chastise you if you did, so please don’t.

I agree it is not the cleanest or most obvious approach, but it’s a compromise between theoretically-best and familiar-enough-to-be-popular.

Earlier this quarter, I, in partnership with Nick, participated in a programming contest put on by the CSE Department. It used a Java framework called “CodeRally” and involved programming an AI for a car on a virtual track. The cars start out at random locations and score points by doing various things, such as going through the track flags in order, throwing and hitting other cars with spare tires, etc. until time runs out. We named our AI “King Regicide” (all credit to my Desmondian counterpart for the name).

Our initial strategy we dubbed “tirespamming”; that is, just try and hit people with tires constantly and ignore trying to go around the track circuit. We got it partially working, but then decided that due to the point spread we should focus on writing logic to go around the track circuit. After fixing a particularly nasty bug that sometimes surfaced when turning from say 5° to 355°, we tuned the tire-firing logic and did decently in simulated contests. We also wrote some smart logic for when to activate our emergency shields. We had dreams of writing some code to evade tires, but we never got around to it.

We ended up finishing 19th in the second qualifying round, one short of the top 18 who got to advance to the final round. However, a couple instructors and TAs, who were ineligible to win any titles/prizes, finished ahead of us, and due to the aforementioned random starting locations there was a large random factor involved and not enough rounds were done, in my opinion, to mitigate this, so we got slightly screwed over. Oh well. Se la vie.

This was almost made up for by the hilarity of “Disappointer”, Prof. Dana Dahlstrom’s entry in the contest. I forget the exact details, but I believe that after a set amount of time stuck in a pileup (see next paragraph), it would extricate itself, tirespam the car who caused the pile-up and throw all available tires at it, and then go back to being stuck. All assembled got a grand laugh out of it.

On an interesting note, the biggest problem in the contests ended up being “pileups”. These are when one car runs out of fuel while going around the circuit, and another car hits it and is too stupid to go around it. Yet more cars would then also pile-up behind these cars, blocking the inner cars from moving at all. This would usually cascade until all the cars were motionless and part of the pile-up. Only one or two cars had AIs which were smart enough to deal with this situation, and interestingly they weren’t even the top finishers. We tried to add such a feature near the end of the contest, but completely ran out of time.

In the end, those who actually won the contest admitted that their AIs didn’t do anything particularly fancy compared to the average entrant: just go around the circuit, throw tires occasionally, and activate shields when necessary; I believe this further supports my assertion about the large, unaddressed random factors involved.

All in all, it was grand fun even though we were robbed of our chance to advance to the finals, and I look forward to next year’s contests. Props to the Dini Group for sponsoring the contest and providing caffeine and food!

Interesting trivia

• index[array] ≡ array[index] ≡  *(array + index)
• arguments to a function may be evaluated in any order by the compiler
• The signed-ness of plain char is compiler-dependent

C99 Hotness

• Boolean type introduced:

#include <stdbool.h>
bool a = true, b = false;

• //-comments formally allowed
• declarations can go anywhere within a function; C89 forces you to declare everything at the start of the function

Syntax

#include <something_in_std_lib.h>
#include "your_own_lib.h"
enum SomeEnum {A, B, C};
typedef someDeclaration newTypeAlias;

• const keyword, like Java’s final
• static keyword means private to this source file, like C#’s internal

Basics

int main(int argc, char * argv[])
char aStringVariable[length];

• EXIT_SUCCESS, EXIT_FAILURE defined in stdlib.h

Function pointers

int foo(char);//declare function
int (*funcPtr)(char) = foo;
int result = funcPtr('a');//use func pointer

Objects

Defining

struct Foo
//unions use same syntax, just w/ different keyword
{
    int a;
    char b;
}

Using

/* C99: */ struct Foo bar = {.b = 'Q', .a = 42};
/* C89: */ struct Foo baz = {42, 'Q'};

Defining macros

• Function-like macros: #define foo(a,b) ((a)-(b))
• The ## operator within macros:
  • Given: #define foo(x) MSG_##x
  • Then: foo(A) ≡ MSG_A
• The # operator within macros – converts operand to string

Useful macros

Assertions:

#include <assert.h>
assert(booleanExpression);

• #define NDEBUG – disables asserts
• #error "Message" – causes compile error with given message
• Conditional compilation: #if, #elif, #else, #endif

Metadata macros

• __func__ – name of current function
• __LINE__ – current line number
• __FILE__ – name of current file
• __TIME__ – time of compilation
• __DATE__ – date of compilation

Standards macros

• __STDC__ – bool for whether compiler is C89-compliant
• __STDC_VERSION__ – 199901L >= if C99-compliant
• __STDC_IEC_559__ – bool for IEEE-754 compliance

Stdlib survey

• stdlib.h: malloc(), free(), array sorting, binary search, str->num conversion, random numbers
• stddef.h: defines NULL, size_t
• string.h: also includes general array/memory stuff
• math.h, time.h: speak for themselves
• errno.h: defines errno global var
• ctype.h: ASCII character classification
• fenv.h: controls floating point rounding mode, etc [C99 only]
• limits.h: limits of integer types
• float.h: describes properties of float representation
• See also my summary of the essential parts of the stdlib

GCC options

• -o exec_name (instead of a.out)
• -Idir_name:other_dir_name (places to also look for headers)
• -fsyntax-only (just check syntax)
• -ansi (use C89)
• -std=c99 (use C99)
• -Wall (warn about a bunch of stuff)
• -pedantic (adhere pedantically to standard)
• -Wextra (warn about strange/pointless code)
• -g (add debug info)
• -pg (add profiling hooks)