Closing has begun

Our hopefully soon to be ours fixer upper money pit is close at hand! Yay!

Mein Gott im Himmel!

So I went to the gym for the first time in two or three years today. I weigh 199.5 lbs! Even subtracting a generous half-pound for the towel, that's 199lbs!

AAAAGGGHH!

I know where I'm gonna be instead of eating lunch, every day for the next millenium, or until I'm back under 165, whichever comes first.

Koan of the Month

Translated from Dogen Zenji:

Heaven and Hell are the flowers of emptiness.

Molly loves literature

new language

So I'm working on a design for a new programming language. Specific goals are as follows:

• non-strict semantics by default (lazy if easy enough to do)
• strict semantics on demand
• strong typing
  
• garbage collection
• support for object-orientation
• tail-call optimization
  
• implicit currying (incl constructors)
  
• support for second-order functions like foldr
• syntactic sugar for lists
  
• good record facility
• algebraic datatypes
• type classes (Haskell)
• type classes as types
  
• type parameters (ML or Haskell)
• monadic I/O (etc)
  
• dataflow variables (Oz)
• pattern matching
• exceptions

Some of this isn't so much language as compiler. For example, I plan on getting garbage collection from compiling to the Java Virtual Machine. I could use a Boehm gc, but the point of compiling to the JVM is twofold:

1. no need to port the darn thing
2. HUGE library support built in
   

I'm following the set-theoretic notion of functions as product types (aka pairs), but am not making any distinctions (like in Z) between injections, surjections, &c. Also, (except where optimized away), in the type-system, there are only operations: application and evaluation. Application is always unary, and evaluation is always nullary. Construction of algebraic datatypes is to be accomplished by application.

The one thing I haven't really figured out is the record support. This's the fly in the oitment, and also the sine qua non of the project. Languages like Haskell are very good at the types of programs academics need to write, and hence have pretty darn poor record support, but real-world coding means a strong record system, preferable extensible if not downright object-oriented.