The dynamically scoped global context made me happy. No other language except Common Lisp has that as far as I know. I am excited to use this.

Currying makes sense in Haskell/ML, but with very few exceptions, it just doesn’t fit in to Clojure. The obvious argument is that Clojure, like many other languages, chooses a syntax that prefers variadics to the exclusion of currying by default.

More importantly, currying encourages patterns that should be avoided. For example, functional combinators and monadic interfaces thread a context argument in the rightmost position. For one thing, these patterns produce unprintable/opaque closures, which deeply hinders debugging. That’s a shame in a language that ships with a pretty printer for - and encourages use of - a common, closed, syntactic data structure (EDN). For another thing, Clojure is impure, so you can just have effects, rather than introduce the extra complexity of monads which make it much easier to accidentally produce lazy or duplicated effects (since the monadic values are reified, the implicit linearity of imperative constructs is lost). Instead of combinators or monads, just write a direct-style, effectful interpreter for some EDN-encoded value, pass a context map as the first argument, if you need to.

Never mind the fact that currying introduces lots of anonymous values, which can easily lead to the sort of confusion that you’d want a type checker to alleviate!

I’m experimenting with something new for my new startup. I’m calling it “fractional” remote: Everybody is encouraged to work from home Wednesday through Friday. Open to better names for this too.

So far, we’re all really enjoying the balance.

• You get to connect with everybody Monday/Tuesday.
• All meetings are scheduled for those two in office days, which is more than flexible enough to enable that kind of collaboration, which is often necessary.
• You get a solid three days of productive time to do independent work.
• Remote workers aren’t considered second-class, since everybody is a “remote” worker.
• Fewer days commuting means that my hiring pool is a bit larger, as people can stomach a longer commute for two days rather than five.
• You don’t miss out on important discussions because nobody is in the office when you aren’t.
• All important communications are likely to recorded electronically, since remote communication days dominate the calendar.

BTW, if you’re in (or near!) Seattle. I’m hiring :) Contact details in profile.

I was expecting this to be about creating a secure string type, but forcing the lifetime to be ’static is much more clever! Fun.

the initial request is rigid and does not include a field that could be used to request that new servers modify their response without breaking compatibility with existing servers

we needed to find a side channel which existing servers would ignore but could be used to safely communicate with newer servers.

Folks: Always put version numbers in your protocols and file formats. Oh, and while you’re add it, prefer extensible records too.

Discussions of infinity hints at why it’s nonsensical to say that the axiom of choice is “right” or “wrong”. It’s either depending on context. It’s related to the closed vs open world assumption. The reality is that, in practice, you have alternating layers of closed systems and open systems. Axioms such as that of choice, or the law of the excluded middle, are useful in closed contexts and invalid in open, extensible contexts. Use the tools that are applicable to your situation.

This post is great! This has helped me clarify my thinking about a few things:

You just can’t do without being able to break your program into pieces.

I’ve found that “pure” code wants to be broken up in to smaller and smaller pieces. This often comes at a performance cost for both call overhead and duplicate work, but that performance is often easy to recover with bulk pure operations, at some risk of repeating yourself.

However, imperative code is often dramatically clearer as big linear blocks of code. More and more, I’m just inlining procedural functions at their call sites with few if any ill effects, and usually benefits. Similarly, instead of extracting procedures, I’m now frequently creating intermediate maps or parallel arrays, and then looping over them.

The one big reason I still break up imperative pieces is for open-dispatch. However, even that can usually be separated along functional and imperative lines: the functional code operates on open union types, but return values of a closed sum type to communicate desires to a central imperative procedure.

Functional code wants to be composed. Imperative code wants to be parameterized.

runST operator lets you create computations that use highly aliasable state

This is why I’m a monad detractor. Once you get in to a sufficiently complex monad, your right back where you started with imperative programming. Only now, you have the added complexity that everything is effectively “quoted” by default, so you can accidentally “metaprogram” your way in to a mess, re-ordering sub-procedures and the like. The type system won’t tell you that should have bound an intermediate result to a variable, rather than splice in a chain of first-class statements.

I don’t doubt that reasoning about imperative programs in Haskell is easier than in say Ruby, but I think that’s more related to the amount of aliased state by default, more than anything else.

Removing any one of the three difficulties makes things easier […snip…] a) State + procedure calls b) State + aliasing c) Aliasing + procedures

I’m designing a language that embraces immutability, but has statements and imperative constructs. Some core design elements aim directly at spending as much time in these two-out-of-three-difficulties sweet-spots as much as possible.

The main thing that values are deeply immutable and acyclic. They are strictly separated from variables (of various kinds) that are mutable containers of such values. Cycles must be achieved via indirecting through a symbol or ID. Stateful objects may employ internal mutability for performance, but then must perform copy-in/copy-out to preserve the value illusion.

A) A reduction in aliasing of mutable state across procedure calls is achieved in two ways: 1) defaulting stateful constructs to be second-class. You need to use explicit syntactic constructs to reify them as objects, like address-of (&) in C or Go; quite unlike Java or Ruby, etc. 2) state has structured lifetime. First-class procedures can close over state, but they will throw if the procedure is executed outside the dynamic extent of that state. If you want to share state more widely, you need to allocate it explicitly from higher up in the process tree.

B/C) Procedures interact with stateful aliasing less frequently with deeply immutable values and explicit mutable aliasing. While call-by-value is standard now, it’s less useful when you have pervasive aliasing in order to pass large values or values of dynamic size or type. In Go for example, you get much more milage from call-by-value behavior than Java, but still frequently create pointers in order to escape the overhead of excessive copying. Not a problem with deeply immutable values.

Slightly (greatly?) less provocative title: “S-Expressions are not ASTs”.

With respect to specific points, Clojure and Racket have good solutions for many of these things.

RE #1: Annotations can be handled generically. Take a look at Clojure’s metadata facilities: https://clojure.org/reference/metadata

RE #2 cons: Clojure’s data structures are abstract (defined in terms of interfaces) and extensible (there is a tagged-literal type). Check out EDN: https://github.com/edn-format/edn - or more general these resources: https://clojure.org/reference/data_structures and https://clojure.org/reference/reader

RE #2 compiler internals: The ClojureScript compiler uses an AST made out of recursive maps. Works quite nicely. “tools.analyzer” does this too. Check out the readme: https://github.com/clojure/tools.analyzer

RE #2 & #3 special backquote: Racket does exactly this with “syntax objects”. Racket’s syntax objects only capture lexical origin and scope nesting information, but you can go even further with this. For example, MetaOCaml, Terra, or other staging systems can capture full lexical closures attached to first-class, user-level syntax fragments. See http://okmij.org/ftp/ML/MetaOCaml.html and http://terralang.org

There’s no reason you couldn’t invent some new type that has the type system rules you want. The reason functions are typically handled structurally is because it’s typically what you want and you can recover nominal typing if you need it. Just wrap a structurally typed thing in a nominally typed container. For example, instead of a function, use an interface/class with a method.

This is a pretty good summary of the problem and solution space known so far. However, despite mentioning Julia, you didn’t mention the fact that Julia has a user extensible promotion system!

It’s a little ad-hoc, since it’s built on top of arbitrary parameter combinations + a fallback case that does the promotion. So users can add rules where types don’t match. However, you could look at that community a bit to see what the fallout has been from offering this functionality.

As for your unsolved problem about enforcing the lattice: That is indeed a hard problem! I saw these “verified” classes in Idris. The idea is that types as proofs are members of the class, so that you can require proofs of the lattice properties. As a dynamic typing fan myself, I find that approach a little heavy handed for most users. However, the same idea could be applied more gently. For example, you could provide a library of properties that are readily usable with a “generative testing” framework.

This makes me appreciate zero values in Go. Instead of having to write a builder, I’d just declare a variable and set fields on it. I realize Rust insists on explicit initialization, but you could at least approximate that here: just write a function that returns a struct and set fields on that. What’s the advantage of the with_whatever methods?

At what point does the type become rich enough that it might as well just be the implementation?

Or to be less facetious: When do we start seeing mainstream languages with integrated relational and constraint programming?

Types let you represent how much information you have. If you want to deal with “arbitrary JSON which might be missing information at various points” there’s a type for that called Json and it supports automatic merges. If you want to inspect that type and learn small bits of information about it you have types for that as well, for instance

isTopLevelObject :: Json -> Maybe (Map Text Json)
isTopLevelArray :: Json -> Maybe [Json]
isString :: Json -> Maybe String

This “attempt to move up the information hierarchy to something more strict but possibly fail” is a very general pattern that usually goes by the name of “parsing”. In a program that uses types well you are constantly “parsing” your way to more information and typically should do so incrementally. If you “parse” all the way to a “concretion” then you’re asserting that your program is strict/brittle. That might be right… but if it’s not then you’ve just made a design mistake.

ADTs are too heavily used. Row types are clearly a win for many sorts of systems letting types flow more freely when the time is right.

That said, typed languages contain within them pretty much all gradations of untyped languages as well if you want to use those. This is the pragmatic heart of Harper’s much maligned “dynamic types are monotypes” argument.

If you find (static) type information is never useful then you shouldn’t use a statically typed language. If you find it’s sometimes useful then you should use one and build types which represent your uncertainty. All of the “dynamic language tricks” will be available to you to use atop those “uncertain” types.

What is it about inference rules, regular expressions, and BNF grammars that allow us to understand them perfectly well, even with the syntactical variance? If simple syntactic differences can cause confusion with overlines and substitution, shouldn’t their expression be re-thought entirely? For instance, would the example that mixes overlines and substitution not be clearer if two for-all quantifiers (∀) were used?

Just use try! instead of try. It returns nil only if receiver is nil, otherwise it raises NoMethodError.

“Law of Demeter” is a strange cult which I’ve seen followed only by rubyists. How introducing Payment#client_address reduces coupling? This is just virtual flattening of tree-like or graph-like data structures. Should I define method for each property for each sub-object of Payment? Payment and Client are data classes, they shouldn’t be even viewed from OOP viewpoint.

I once worked on project where everyone tried to enforce “Law of Demeter” on traversing json in Javascript (more precisely, Coffeescript, and backend was in Ruby).

As a certified PL amateur, this is very impressive.

Most async implementations end up bifurcating code into async/non-async flavors (much like const in C++), or require a specialized VM with different callstack semantics. I’m a big fan of async/await overall, but it still sometimes felt like something the compiler should help me more with. What’s more, I can’t imagine using async/await without a dynamic type system: you have to keep a clear mind on whether you’re dealing with a value, or the thunk returning a value. As the paper mentions, most async/await implementations are kind of one-off in the sense they’re hardwired into the language, rather than being building blocks.

Also, I love the phrase “islands of abstraction” to concisely describe the phenomenon that occurs when you need duplicate versions of functions for different contexts, be they monadic, async, const, etc.

Immutability. (…) This means you’ll tend to program with values, not side-effects. As such, programming languages which make it practical to program with immutable data structures are more REPL-friendly.

Top-level definitions. Working at the REPL consists of (re-)defining data and behaviour globally.

These two points are in furious contradiction, since redefining top-level definitions is pretty much the ultimate side effect. Every other top-level function can see this “action at a distance”.

Let me be perfectly clear: ML and Haskell allow you to program using Lisp’s “every definition is subject to revision” style. Just stuff all your top-level definitions into mutable cells. The reason why it’s not done as frequently as in Lisp-land is because, perhaps, perhaps, this is actually a bad idea.

Context should go away for Go 2

I (mostly) agree with this overall thesis, but wish to add some more ahem context.

idea that context should carry a map of meaningless objects to meaningless objects

It’s actually a pretty clever idea. Coupled with unexported types and the fact that contexts are not enumerable, it lets you hide some context keys to prevent people from reading from that.

type foo struct{}
var fooKey = &foo{}

function WithFoo(ctx context.Context, s string) context.Context {
  return context.WithValue(ctx, fooKey, s)
}

function GetFoo(ctx context.Context) string {
  return ctx.Value(fooKey).(string)
}

The exported WithFoo/GetFoo functions are just examples. If you don’t export anything, your context key can safely pass through other people’s code and they will never be able to access your private context data.

it’s prone to name collisions.

This is impossible if you use the pattern I showed.

That’s the only problem the “context” package really solves (or attempts to solve)

It’s also generally useful for any thing you might use dynamic scope or thread locals for in languages that support those. Yes, I know it’s technically lexical, but it tends to be used in a dynamically-scoped way.

For example: Threading request id or current user all the way through for logging contexts.

Go 2 should explicitly address the cancelation problem

I agree with that. I’m a fan of Martin Sustrik’s structured concurrency idea, but I’m not sure how it would work out when retrofitted in to Go. Explicit termination of subprocesses, a la Erlang, is the way to go.

Context is like a virus

Yup. It’s also true of any side effects, or indeed any dynamically scoped constructs, such as panic/defer/recover. Go already mandates a stack-frame associated context object for panics, debugging, etc. Maybe it should just give up and expose the current lexical and/or dynamic context to all functions implicitly?

Turned my machine into a space heater, but worth it!

Truly stunning detail, but the bill runs high. Some folks have been working on breakthroughs, but we still have a ways to go before it will replace triangles and texture maps.

I’ve through the blog post, the associated proposal, some of the draft specs, and a bunch of other stuff.

Nowhere do I see anything that motivates this. Why is this feature being added? What problem does it solve? Why is the leading underscore convention insufficient? The draft specs suggests that there is significant new complexity added to various core algorithms in the object system, but it feels unjustified.

Is it just assumed that “encapsulation” is good and therefore necessary? Is it further assumed that enforced encapsulation is a requirement? Is there speculation that JavaScript may be eventually object-capability secure? Is that even a feasible goal? Would it even be useful in the absence of process abstractions? Feels like more skyscrapers on foundations for sandcastles.