Hacker News Reader

Comment by notacoward | Hacker News Reader

Is this satire? The original four-line snippet is pretty darn clear in terms of intent, run-time cost, and potential errors or side effects. Slicing it into continuations so you can overload assignment, or vice versa, is making one mistake to enable another.

> thinking about sequences of assignments as chains of function applications can be illuminating.

"I love how this painting expresses the artist's existential dread. Please date me."

> you can use this approach to pack more into a single line of Python

If you think that's a worthy goal, then instant no-hire.

View on HN

Not satire. The article focuses on how, rather than why, and uses the standard technique of starting with simple examples to illustrate the concept.

If all lists had two elements in them, for loops wouldn't be particularly helpful. Similarly, continuations don't make the simple example mentioned any better, but they're useful in more complex situations.

It does mention two non-trivial applications at the end: implementing list comprehensions in a language that doesn't have them (which are pretty useful!), and probabilistic programming.

    Many people seem to write DSLs these days. My goal 
    here was simply to encourage people who might not 
    typically work in a functional style to think about 
    how continuations might be useful in the design of 
    their languages, even if it seems their language is 
    imperative.

And since you quote a line a few after that paragraph, it's not like you didn't give yourself the opportunity to read it.

He's not trying to do very simple math. He's teaching fundamental DSL design techniques.

Continuations are a powerful thing to know, but, for promoting DSLs, I hope no one thinks they have to wrangle continuations to implement DSLs.

One way, if you're using Racket (or another Scheme or descendant), is to translate your DSL to normal syntax in Racket much like you'd write manually (and you can use imperative or only pure-functional features, your choice).

For example, were I implementing the language used by the first example in the article, I might say each assignment establishes a lexical scope, and simply translate the source syntax to nested `let` form syntax:

    (let ((a (/ 1 (+ 1 7))))
      (let ((b (* 2 (+ a (sqrt a)))))
        (let ((c (/ (atan b) (+ 1 c))))
          (+ c (* 2 d)))))

Or (since there wasn't any non-assignment code in between the assignments), how you might normally write it manually in Racket:

    (let* ((a (/ 1 (+ 1 7)))
           (b (* 2 (+ a (sqrt a))))
           (c (/ (atan b) (+ 1 c))))
      (+ c (* 2 d)))

To get to that target syntax, I might have my parser produce intermediate syntax as a kind of abstract syntax tree, such as:

    (block
      (assignment a (/ 1 (+ 1 7)))
      (assignment b (* 2 (+ a (sqrt a))))
      (assignment c (/ (atan b) (+ 1 c)))
      (return (+ c (* 2 d))))

Which, in this case, is a simple translation of syntax objects to the nested `let`s or `let*` examples above.

Of course, for a real-world DSL, you might have very different semantics than in the simple example, but the above translation method still likely applies.

You might start your language implementation by typing examples in your language, then the equivalents in Racket, then the intermediate parse trees of your examples... and then Racket `syntax-parse` or `syntax-case` generalizations your parse tree syntax to the Racket syntax.

The examples you made might then be test cases for your translation.

And if your DSL is embeddable in Racket code, you probably don't need the parser at all -- you might just need a `define-syntax`, with `syntax-parse`, `syntax-case`, or arbitrary code to do the translation.

Sure, agreed. "Fundamental technique" wouldn't imply "necessary technique" in my vernacular. The CPS mindset is sure down there in fundamentals town, though, with respect to thinking about evaluation, etc.

I do want to add that Lisp metaprogramming does one big trick for DSL design in that it works at the syntactic level and ignores binding. Thus all the tricks around hygenics and anaphoria etc.

Since ignoring binding means that you only deal with the call graph implicitly through working with the AS tree, you get an opportunity to pareto your way through tougher DSL nuggets.

What do you mean by "ignoring binding"? That doesn't sound right. Binding is one of the things I think about the most when building DSLs in Common Lisp.

Yes, the user has to since the system ignores it. A lisp macro operates, generally, over the abstract syntax tree as opposed to the "abstract binding tree" where alpha equivalences have already been factored out.

Or, concretely, a lisp macro distinguishes between syntax `(my-let (x 3) x)` and `(my-let (y 3) y)` even though they are, under implied semantics, identical. In that way, lisp macros have little to say about binding.

I still don't understand; probably because I'm not proficient in the mathematical underpinning of this.

The way I see it, a (Common) Lisp macro can, but does not have to, distinguish between the two forms you've shown. Assuming `my-let' is the macro, from it's POV, `x' is a value. A reasonable implementation of "let" won't care about that value beyond it being a symbol comparable to other symbols by `eq'. This way, `(my-let (x 3) x)' and `(my-let (y 3) y)' will expand to effectively the same code - and after the compiler gets rid of symbol names altogether, the resulting code will be actually the same.

The syntactic approach subsumes the more semantic approach where the graph structure is made explicit. So, yeah, you can "compile" list structures to the binding graph and indeed you must.

Having more granular distinctions always helps in that it's easy to "forget" how things are different. It's also more primitive in that you have to actually do that step. It also leads to opportunities to do "wrong" things like anaphoric macros.

This is essentially a tradeoff where more power is offered to the author of the macro and less to the reader.

To make another comparison, we can take it one step further: a macro preprocessor which had access to the actual character stream can elect to do things not possible in lisp macros—e.g., distinguish on indentation or something to that effect—but also can recover all of the lisp macro techniques by merely parsing the character stream.

---

The heart of all of this, popping the stack up to my original comment, is that for lots of macros you don't really need to care at all about binding structure—or at least only minimally—and thus you can get lots of practical work done doing "just" syntactic transforms.

Once you are really working over a complex call graph—which is common in more complex DSLs like probabilistic programming languages—then CPS becomes really important as you want a way to split call graphs into pieces and a practical way of doing that is (value + continuation).

Worth noting, CPS transformations are a popular technique in more sophisticated lispy macro transforms, too.

> a macro preprocessor which had access to the actual character stream can elect to do things not possible in lisp macros—e.g., distinguish on indentation or something to that effect—but also can recover all of the lisp macro techniques by merely parsing the character stream.

Common Lisp has the mechanism called "reader macros" that can do that. It's a separate mechanism, because it works at "read time", which is much earlier than the "macroexpansion time" when the regular macros are processed.

Yep, "macros" can operate at any point during the compilation/interpretation process to transform the inputs. Generally speaking, the earlier on the more simplistic the structures and the less inferential products available. Also, the greater flexibility and power. Later on, early stages of compilation/interpretation will strip away information, simplify products, add inferential information, etc. These pieces can be made available to macro systems staged later on.

Lisp's most famous macros exist somewhat early in the compilation process, where trees have been parsed but variables aren't interpreted and the data structures are still simple.

BTW, Racket syntax transformations work with Racket syntax objects [1], which is one way to do the indentation sensitivity you mention. Racket also has something called `#lang` for conveniently using arbitrary parsers, and a way to embed use of arbitrary readers for chunks of code within normal Racket code.

[1] https://docs.racket-lang.org/reference/stxops.html

> thinking about sequences of assignments as chains of function applications can be illuminating

I think it's mind-bogglingly fascinating because it shines a bright spotlight on the deep connection between imperative and functional computing. If you don't think that's interesting, you're probably not somebody I would want to work for.

One of the particular insights I gained reading SICP long time ago is that local variables are equivalent to function parameters. That is (using CL syntax):

  (let ((a 3)
        (b 2))
    (some code using a b))

Is equivalent to:

  (funcall (lambda (a b)
             (some code using a b))
           3
           2)

This is the basis of translating imperative loops into tail recursions.

You can go even further by currying the second one and then you're writing a Haskell compiler ;-)

I remember reading something on building a functional state machine that wound up being the equivalent of imperative programming, registers, etc.

Yep, two sides of the same coin. If you can find the reference I'd like to read it.

I think it’s more of a lark to play with some ideas. I’m sure Dan can take his Oscar and get hired somewhere.

Three Oscars actually!

Funnily enough, even the very nice 2008 post linked at the bottom On writing Python one-liners (http://blog.sigfpe.com/2008/09/on-writing-python-one-liners....), which opens with “You can think of what follows as the demonstration that you really don't want to” and ends with “But you probably don't want to do that”, has comments like “Have fun debugging! I'll stick with "normal" code thank you.”

Seeing the classic middlebrow dismissal shitting on Dan Piponi is a special kind of entertainment.

> Is this satire?

> "I love how this painting expresses the artist's existential dread. Please date me."

> ...instant no-hire.

Instant no-interview.

> The original four-line snippet is pretty darn clear in terms of intent, run-time cost, and potential errors or side effects.

I think this is sort of an inherent problem of simple examples. CPS is pretty awesome, but it's not really worth it until you get into "Cheney on the MTA" problems with recursion and/or parallelism, but to show that in a simple tutorial would probably confuse a lot of people.

> then instant no-hire

Classic HN brag: _I_ have the ability to not hire you!

Technically, everyone has that ability.

Man, this place is way too fucking full of trolls.

Reply on news.ycombinator.com