Hacker News Reader

Hacker News

Comment by tristramb | Hacker News Reader

Full thread

tristramb

All programming is just function composition.

This is an idea that I got from studying category theory.

Concatenative programming is just a first step in that direction.

I leave the details an an exercise for the reader.

View on HN

Modern programming is. But look at assembly, which is what actual machines do. And you can write assembly with tons of gotos and not a single function in sight.

Modern machines do. But the dominance of imperative assembly is more about historical momentum and engineering tradeoffs than fundamental necessity. We don't have to go all-in on Von Neumann.

Time to read "Debunking the 'Expensive Procedure Call' Myth, or, Procedure Call Implementations Considered Harmful, or, Lambda: The Ultimate GOTO":

https://dspace.mit.edu/handle/1721.1/5753

The point is there's a closer connection between functions and gotos than you might imagine.

There's really no such thing as a 'function' at the assembler level. There are pure jumps and there are jumps that also perform side effects on a register conventionally called a 'stack pointer' (and on the memory that register points to) but no true 'functions.'

This is roughly the point Steele is making, in addition to his point that the stack pointer side effects are often unnecessary (i.e. tail jumps).

Implementing a stack pointer in hardware is merely a legacy hack: Before people figured out continuations they didn't know any better.

> There's really no such thing as a 'function' at the assembler level.

That's like saying "There's really no such thing as a 'chair' at the quantum level."

If you look at the computer (registers, cache, RAM, storage, etc) as one whole, every assembler instruction is just a function that takes in the state of the computer and returns a new state. Multiple assembler instructions is then using function composition.

Well put. This is what many people seem to miss: the functional perspective is a model.

side effects are quite the thorn in this theories side. hard to describe message passing in purely applicative terms.

Effects are pretty smoothly described by monads; there's an entire well-respected language built on top of that.

One of the problems of the purely applicative approach is that you get a nice algebra for describing your results, including the sequence of effects, but reasoning about the resources spent by the computation becomes harder.

monads were certainly a clever fix for the difficulties otherwise caused by passing around the world as a value.

I might argue that laziness makes haskell something different than purely applicative.

It's not just pure values being passed around. It's a language built atop suspended self-caching invocable thunks getting knotted up and then firing off in chain reaction.

    main = do
      let
        hello = foo world
        world = bar hello
      putStrLn $ show hello
      putStrLn $ show world
     where
       foo v = [v]
       bar v = length v

Reply on news.ycombinator.com