The days are passing way too quickly, and I'm glad I have been logging, because it helps keep me grounded. Yes, I see some of my favourite project ideas slipping away, but I also see some progress, and that is heartening. Also, it is useful to re-evaluate early and often.

I have started to have to say "no" to things more, which is always hard, but it's realistic. Many of the conventions of life hide choices under assumptions. You go to high school, because that's the choice. You take the classes they offer, and within each class you do the assignments chosen for you. When I got to university the first time, I was blown away by how much math existed that my teachers had never alluded to, and that I had never even thought to look for. It was endless. Yet even at university, even at grad school, many of the choices can be delegated, and then perhaps you take a job in your field. This is the "track" I was drawn to, and partly born to.

So now I am having to say "no" to way more things I can say "yes" to, and that's great, because on the one hand, almost all of the choices have advantages, so it's hard to lose, and on the other hand it is training me to choose, and that is a powerful skill.




  • Read Lecture 1 and did Homework 1, exercise 1.
  • Cleared up some confusion I was having about ghci, with the help of Hacker Schoolers.


  • Figured out how to use Factor code outside of the Factor code tree, using the environment variable FACTOR_ROOTS, and how to set up the vocabularies so they will be found.

    "if your vocabulary name is a.b.c then the expected location from FACTOR_ROOTS is a/b/c/c.factor and and a/b/c/c-tests.factor with with IN: a.b.c"

  • Started writing a minimal test, and had trouble figuring out some basic idioms.

  • Skimmed through Slava Pestov's Google Tech talk again.

    • Slava compares the way polymorphism is handled in OOP, functional languages, and Factor:

      • OOP passes messages to classes via methods. So for example, there may be a rectangle class and a circle class, and they each implement an area method.

        Disadvantage: hard to define new operations; have to add to every class, and you may not have access.

      • Functional languages have algebraic data types: when you define the operation, you give a definition for each data subtype that matches.

        Disadvantage: When there is a new type, you have to extend every operation.

      • Factor borrows from Common Lisp in decoupling:

        Generic words have behaviour that depends on the type that is on the stack.

        E.g. GENERIC: area ( shape -- n )

        This then allows any method to be independently defined:

        M: rectangle area [ width>> ] [ height>> ] bi * ;
        ! Recall that the bi combinator cleaves the two preceding quotations, so that they can both apply to the previous object.
        ! width>> and height>> are thus applied to the rectangle that area has grabbed from the stack.

        M: circle area radius>> sq pi * ;

        Then you can define a type MIXIN which alllows you to declare new types as instances of another class.

        TUPLE: parallelogram ... ;
        parallelogram shape
        M: parallelogram area ... ;
    • I created an object using TUPLE with a default value to use in my test.


I got clarification on the functionality of the backup command and figured out why I was confused about it. Now I am in a position to continue writing my proposal draft.


I did not get to the linguistics, but I read another post by someone excited about concatenative languages: Daniel Spiewak's The Joy of Concatenative Languages Part 1.

Pseudo-Random Thoughts

I keep thinking about the connections between type systems, proofs, and natural language parsing. The Haskell lecture said "Programs with type errors will not even compile, much less run." I have been developing an analogy to natural language where compile :: parse, and run :: create a meaning structure. I hope to develop that more over the coming weeks.