Made my first commit to @eikeon’s hu repository, also not great, but also not bad for a first attempt, I guess.

Thought more about how to keep better track of things we’re making, came up with the idea of keeping a “log” on the “web” and maybe calling it a “web log” or just a “blog” for short.  I think this last idea may be the one that makes me millions.

Term

We have talked about terms as a centerpiece of our language.  One reason for this is to craft a language that is oriented around humans, who generally seem to have an easy time with the concept of a term.  But it is not particularly problematic to think of a term as an object or a function or even a closure if you’re wired that way, e.g. you are a being made partly of wires.

Alphabet

The term has a label, which is just a contiguous sequence of characters.  We haven’t talked a lot about which alphabet we’ll use, but I’m guessing it will either be something Unicode-ish, or we will leave it open to the lexer.  If we do the latter, the alphabet will be a set of letters from which terms may be spelled (e.g. {a, b, c, d, e, f}).

Lexicon

For any given program, there is a corresponding list of entries, which are the lexicon for the program.  The entries are terms which must be spelled with whatever alphabet is used.  No terms may be used in the program that are not in the lexicon.  The list of terms contains a corresponding list of definitions- zero or more per term.

Entries

A an entry is either empty (the term may only be replaced with itself) or contains two parts: its shape and its definition.  The shape of an entry can be thought of as its part of speech, or as a named graph with the term at the center.  The definition, when it exists, consists of one or more sentences.

Part of Speech

The part of speech, or named graph, is part of a grammar.  The grammar of a language describes which parts of speech may be employed in sentences.  A part of speech “connects” to other parts of speech (or named graphs).  This can be thought of as the local structure on an abstract syntax tree for those more inclined to think that way, e.g. robots.

Sentence

A sentence is a collection of terms that are evaluated concurrently.  This is not to say that word order in a sentence is unimportant, as the first term encountered is the first one for which evaluation begins, and subsequent terms in the sentence may rely upon this fact.

Paragraphs, etc.

Sentences may be collected together into groups and called a paragraph.  A paragraph, simply put, is a group of sentences over which side effects may be relied upon to persist.  To the extent that paragraphs are collected together into larger collections (a section, perhaps, or a chapter) the larger collection is a group of paragraphs over which side effects of the paragraph may be relied upon to persist.

Side Effects

That word, “side effects” is also at the center of this language.  Terms do not return a value like a function or a method- instead, they transform into something else, and register this transformation with the other terms.  In this sense, each term can be thought of as a simple callback if you’re inclined that way, e.g. you are Donald Knuth or someone smarter than me, at least.

Concurrency

When we say the word “concurrent” it is as a counterpoint to the word “sequential.”  As such, the statement “A, then B, then C,” is different from the statement “All of A, B, C.”  In the former, perhaps B depends upon A, and C upon B.  In the latter, each depends upon the other (or none depend upon any, if you prefer to think about it that way, e.g. you are way out there).

Fragments

Last, but not least, a sentence fragment may not be parseable.  Think of book titles or recipe ingredients- these are intentionally fragments.  When a fragment is not meant to be parsed, this is a way of registering that it will be used subsequently, and it is not considered part of a paragraph.  E.g. no side-effects persist, but the fragment itself is kept around for use later in the program.  A fragment has an implicit part of speech (shape, but not a named graph, since it has no name).

Lexing

Lexing is the process of looking sequentially through a sentence and chopping it into terms.  This process requires a lexicon.  Note: lexing, lexicon.  The lexer consumes letters until it finds a term.  It then passes this term to a parser instance and branches.  One branch starts on a new term for that first parser instance, and the other continues to consume letters until it can be certain there is no alternative lexing.  If it finds an additional possibility, it passes the term to an alternative parser instance.  As such, lexing is deterministic, but it also may yield more than one parser instance.

Parsing

Each parser instance is given a set of terms by the lexer.  As they are encountered, each term is looked up in the lexicon, where zero ore more definitions are present.  If there are zero definitions present, the term is replaced with itself.  If there is one definition present, the term is replaced with that definition.  If there are two or more definitions present, the parser chooses which to use by examining the part of speech and seeing which will work in the context of the current sentence.  If this cannot be determined, the parser branches again, and both are tried.

Compiling

The process of compiling is essentially going through all the possibilities and following them to the bottom until every single term is replaceable only by itself.  Once this has been completed, the entirety of the program is represented by a graph of terms, where the shape of the graph locally is determined by a part-of-speech.

Given the Roman number II, the integer 2, the real number 2.0, the word pair, children seem to understand the relationship between them.  Children seem to know how two chairs and two people are the same.  In the bath last night, my two-year-old asked for one of her “guys” and when I gave it to her she pointed at the other one and said “two guys.”  Then she pointed at herself and said, “I’m two!”

What is the sameness between those two guys and the two years she’s lived and the two fingers she holds up proudly each time she uses that word?  Where does that sameness break down?

If I give her three sticks and she counts them, she counts to three.  If I break one of the sticks in half, she understands I haven’t added or subtracted any substance from her stick pile, but she also understands that predicates are needed when we talk about the four sticks we now have: two whole sticks and two half sticks.  If I ask “how many sticks are there?” she could answer a bunch of different ways: 4, 3, 2, or some other answer I haven’t thought of.  In order to settle on the same answer, we have to have a conversation about what we mean by “stick” – just a whole stick?  any part of a stick?  the number of sticks before one was divided?

Mathematical logic in children seems to be something that develops early and is surprisingly capable without too much intervention.  Wonder what it is that we do to change that?

The proof of knowing is teaching.

The proof of teaching is another’s learning.

• Why I Stand Up For Stallman
• I Also Stand Up For Stallman

I have a slightly different perspective on this.  I do not stand up for Stallman, because he has no need of my support in this regard.  Stallman is perfectly capable of standing up for himself, but seems to consider it beneath him to spend time on it.  Instead, he spends his efforts standing up for Free Software.

He’s not some kid to feel sorry for, he’s a fucking MacArthur genius.  He invented Emacs.  He wrote the GPL.  He founded the Free Software movement.  He’s taken on huge corporations and tyrants and all other manner of adversaries (and friends) with their slings and arrows affecting him like water affects a duck’s ass.  He dines with presidents and prime ministers.

The origin of all this kerfluffle is some email that’s going around which makes Richard sound particular about his accommodations when he comes to town to give a FREE SPEECH.  Well, let me say this: Richard stayed at my place in DC during some such speeches, and he never once complained about anything.  At the time I lived in a bachelor shit-hole in a neighborhood in DC that was basically an open-air drug market.  Not.  One.  Complaint.

A fucking MacArthur genius, sleeping on my couch, in my shit-hole apartment, and the only thing he ever asked for was fucking wifi.

I don’t stand up for Stallman, I look up to Stallman.

Way up.

If you don’t, it means one of two things: either you don’t know about Stallman, or you’re a tool.  I don’t stand up for Stallman, but I look up to him.  And I run GNU/Linux, and I use Free Software.

Because Stallman said so, that’s why.

• any
• all
• some
• none
• one
• few
• fewer
• many
• more
• neither
• most
• such

That’s not all of them, but it’s a good start.  Indefinite pronouns, roughly speaking, are what allows us in English to signify operations on a list somewhat less… definitely… than otherwise.

These are the parallel equivalents of the Boolean operators we all know and love.  And, or, not, so, xor, nand, nor, etc.  Of course many of the Boolean operators operate most naturally on a list of two items, and the indefinite operators work well on lists of indeterminate length (in some cases, literally indeterminate, in that they could work on a list that hasn’t been counted at all).

Now, the difficulty here is that with software, indefinite logic requires us to do a bit more bookkeeping than straight Boolean logic.  For instance, when I do something like “a and b” with Boolean logic, I just evaluate a.  If a returns true, I evaluate b.  If b returns true, the whole statement is true.  Everything can be done sequentially, and programmers know to rely on the short-circuiting nature of the operation.

On the other hand, if I say “all a, b” I kick off concurrent evaluations of both at the same time (even if under the covers the machinery that takes care of this runs sequentially, or optimizes to run the faster one first or the more likely to fail one earlier).  If b immediately returns false, I need some way to tell a to stop evaluating, which might save considerable time and effort.

The Go programming language has some nice primitives built in for both operations (e.g. kicking off parallel computations, and for communicating between the various sub-processes).  The “go” term indicates parallel execution, and the <- operator on a channel indicates communications back.

Of course with a thousand nested parallel calls, interspersed with plain old Boolean logic, there may be quite a bit of this going on, but it also may happen that most the calls get shut down before doing much.

The code might look something like this:

and(a, b, c, all(c, d, any(e, f, g)), some(h, i))

Here, the term and indicates sequential execution, the term all can be thought of as a parallel short-circuiting and, the any can be thought of as a parallel short-circuiting or, and the term some can be thought of as another variety of parallel or, which maybe doesn’t short-circuit as quickly.

I think programmers would grok this if it were presented in a reasonable fashion.

thing one && thing two

I only get to thing two if thing one evaluates true.  Even if you’re not a programmer, you probably do this in practice.  Consider:

If it’s dry and warm, we’ll play outside.

Which means, if I get to the first part of the sentence, and see that it’s raining, I can just kind of disregard the rest.  I don’t have to even read to see what we were going to do if it were dry and warm, because it’s not dry.  We do the same sort of thing with “or.”  Consider:

We’ll play outside if it’s wet or if it’s dry.

If it’s wet outside, we don’t even need to read the last part of that sentence.  We short-circuit the final operation, because it’s not necessary for evaluating the truth of the whole construct.  The short-circuiting pattern is important for computers, because in the best-case scenario, it can save a some of computation.

In fact, if you imagine a sentence that includes a list to be evaluated in short-circuit mode, it can save a whole lot of computation:

We’ll play outside if it’s wet or if it’s dry or if it’s cold or if it’s hot or if there’s a hurricane.

Chances are, we’re going to play outside, and if it’s wet, we save the trouble of evaluating all the subsequent possibilities.

Now, for computers, there are some downsides to doing this.  For instance, it’s expected that in order to save time and in order to keep everything consistent, these operations need to happen sequentially.  A && B && C is different than B && C && A, even if the operations don’t have any side effects.  If there are side effects of the computations, the situation is even worse, since in one case maybe you get the side effects of A and B, and in the other you get the side effects of B and C.

If you’re not a programmer, you can skip the part about side effects without any side effects, I think.

What we’re missing is a systematic way of thinking about short-circuit operations that can happen in any order, and can happen either sequentially or out of sequence or concurrently.  It’s not that there isn’t special built-in machinery to do this in particular languages, but for a polyglot like me, there’s very little overlap between one way of thinking about it and another.

The funny thing is, English has a great many ways of designating a list as a short-circuit concurrency operation:

• any
• all
• none
• one
• some
• more
• fewer

If you’re going to the store and I give you a list, I can gesture at the list with any of these words to let you know when you can quit.  ”Any” of the items means you can stop when you find the first one.  ”All” means you can get them in any order, but you need to get all of them.

We should be able to do the same thing, specifying a kind of concurrency and a kind of short-circuiting in programs with the same kind of shorthand.  Imagine I have a list of operations to perform, but I only care that at least six of them happen.  Or I know that if any of them fail, I can stop all of them.  Or if any of them succeed I can stop all of them.

I think that’s a level at which a programmer (at least the kind of programmer I am, which is to say one with more hubris and laziness than usual) should interact with a language’s underlying concurrency model.

Larry Wall put this idea into Perl 6, though I’m not convinced the semantics are exactly right.  For instance, I’m not sure if I should generally be saying:

someMethod(any(1,2,3))

or

any(someMethod(1), someMethod(2), someMethod(3))

The former looks terse at first glance, but requires a lot of bookkeeping inside of someMethod that might be avoided, particularly in languages that don’t have the notion of a Junction (that’s what he calls this kind of construct) baked in.  The latter looks verbose at first glance, but one can imagine cases where it would be useful to evaluate several different methods and/or put some syntactic sugar around the actual call.

I can also imagine a kind of chaining of these terms together in a way that creates a massively concurrent operation that can return quite quickly in the best-case scenario:

if any(all(none(1,0,0), all(1,1,1), one(1,1,1)), any(1,0,1))

then someMethod()

This could use the same truth-logic as usual boolean algebra, but could also short-circuit efficiently in a way that would be more difficult (or require more sophisticated machinery) if those same calls were the usual ands and ors that we would use in such code.

I don’t think the machinery for this is too complicated.  It would, of course, matter how the underlying concurrency was managed.  In something like Go or Erlang, it would probably be quite fast, and in something that required a heavier process for each unit of concurrency, it would probably only be worthwhile in the case of heavy computations that could benefit from the short-circuiting.

Last, but not least, I can imagine mixing this together with a bit of map-reduce.  So, if I do something like:

all(someMethod(“foo”), someMethod(“bar”))

I can write these methods to also stash a result somewhere (nasty side-effect, that) but only use it if the computations complete successfully according to the all operator (e.g. none of them return false and all of them return).

When I started college, there were a series of peer counselling sessions, structured to gently introduce the (possibly sheltered) 17- and 18-year-olds to some of the more jarring differences between a (possibly sheltered) high school classroom, and life at college.  The session I remember most vividly was run by what is now called the Queer Students and Allies (QSA).

It was next door too our suite, in the RA’s living room, and twelve or fifteen of us sat around in a circle on the floor with a couple older students leading a discussion group on a pretty wide range of topics.  Each of the topics seemed tailored to gently prod some of the more heteronormative ideals of the first-years.  Perhaps the most thought-provoking point in the discussion was when the peer counselors asked us to go around in a circle and say, “Hi I’m so-and-so, and I’m gay.”

I think the idea was to provide a safe environment where two things could happen: people who wanted to say it in the worst way could say so in a context that felt pretty safe (after all, everyone’s doing it…); and people who didn’t want to say it could see what it felt like anyway.  We duly went around the room, until one kid just wouldn’t say it.  Instead he said, “Hi, I’m David, and I’m not going to say that.”

He was the only one.

He was me.

I’ve thought about that day a lot of times since then.  That summer I went home and smugly told the story to a friend at church, reveling in my steadfastness and righteousness.  Like a Pharisee.

Hi, I’m David, and I’m gay.

I’m sorry I didn’t say it that day.  I’m sorry I subsequently bragged about it.  And I’m especially sorry to have made it harder to say for the people who really needed to.  I’m older now, and I suppose the stakes are lower: I’m not worried that some of the people reading this will only read that one sentence:

Hi, I’m David, and I’m gay.

After going around in a circle, the peer counselors asked, “What did that feel like?”  Almost twenty years later, I’m proud to say, I felt like an ass.  I felt like an ass when I didn’t say it, and I felt like an ass when I bragged about it, and I feel like an ass admitting that I thought it made me a good Christian.  So, in addition to saying

Hi I’m David and I’m gay.

I have one more thing to say: if you believe in God, and you’re gay, well, God loves your gay self, too.  And we’re not talking about a love-the-sinner-hate-the-sin kind of love, we’re talking about loving part and parcel.  And you know what, everyone (gay or straight or neither or both) who believes in God finds that last part hard to take sometimes, so just get over yourself.

Yeah, I said it, God loves you.  And I’m sorry it’s so controversial.

At a family vacation some years back, I dubbed the lot of you the Outer Banks Cosmological Society.  This all happened inside my head, and in a conversation with Maggie, so don’t feel bad if you didn’t already know you were a member.  It’s a loose association anyhow.

Those conversations, which I’ve had with pretty much all of you a time or two, I have come to think of as Ad Hoc Meetings.  This blog, for the most part, is the Proceedings of those Meetings.

You get my drift.  I’m the Editor of a Prestigious Journal, not just a Schlub With a Blog.

For most my life, and most the ten or so years I’ve had a website, this is the sort of thing I wouldn’t mention to people without winking, because, let’s face it, it’s a funny way to look at the world.  But I think most of us do it a little bit, and I think we should all do it more.

So, welcome to the Outer Banks Cosmological Society.

That is all.