Thanks @sorawee I can confirm that also on Windows Shift+Alt+Right-Arrow automatically select all the text until the corresponding closing parentheses. Quite handy :slightly_smiling_face:

@badkins Your suggestion means you have to copy every keyword argument, something I want to avoid. Take serve/servlet, for example, it has too many kwargs for that to be convenient.

@sorawee Your last example is exactly what I meant, thanks.

I’ve found myself wanting this many times in the past, and wondered why it was so inconvenient. It is a silly thing to want, I must admit. I’ve always ended up refraining from wrapping those kinds of functions, and I don’t think the code suffered as a result.

Sure, makes sense when the number of keyword arguments is greater than N.

Something I’m curious about: It seems like in the Racket slack, continuations are a frequently-mentioned topic, and something which end-user-programmers (for lack of a better description) routinely use. I’m not familiar with any other language (though, I’m not really familiar with any other LISP) where they’re so prolific - usually continuations seem to be behind-the-scenes magic used by language and some library implementors.

Is that an accurate perception on my part? If so, why might that be?

Roughly speaking, the continuation feature is like functional goto, so it’s the same reason why people try to avoid goto: it makes code harder to understand.

Also, some implementations have poor continuation performance, causing memory leak, etc.

I don’t think Racket end-user programmers frequently use continuations. Continuations tend to be more behind the scenes, still.

The goto analogy is reasonable, both on the negative side (you can write confusing code) and the positive side. To elaborate a little on the positive side: compiling Racket to machine code, not C or other block-structured languages, gets a lot of benefit from a powerful and pervasive goto — jump to anywhere, instead of jumping only within functions. Similarly, first class control is helpful as a compilation target for higher-level constructs.

Another possible analogy is to laziness in Haskell. You can point to uses of laziness, but probably the bigger effect in Haskell has been to keep the language more purely functional. Similarly, a commitment to tail evaluation and first-class continuations tends to steer Racket design in a particular direction. (And just like laziness can sometimes just be a pain, having first-class control is sometimes just a pain, such as when you’re trying to compile letrec.)

I suspect continuations are something that comes up disproportionately often in various contexts because they’re difficult. People ask questions about them, document edge cases related to them, and make little experiments to build their familiarity with them.

But they also come up because they are pretty effective in a pinch for a variety of problems. If someone’s committed to using a particular style of programming, but the control flow or side effect model they want isn’t idiomatic for Racket, it’s often possible to get it to work anyway with the use of continuations. Even when the most practical advice is “refactor your code,” it’s fun to be able to say, “yes, in fact you can make that work that way,” and it showcases one of the ways Racket lets people create and program in their own dream languages.

One common use of the continuation feature is let/ec. It’s essentially a return in other mainstream languages.

(let/ec return (for/fold ([total 0]) ([x (in-range 10)]) (define x (read)) (when (eq? x 'end) (return total)) (+ x total)))

This program accepts 10 numbers from stdin and then sum them all, but if users input end, the summing ends immediately.

So, overall, continuations probably aren’t used a lot more. Maybe a bit, because the overall design of Racket perhaps steers people towards them a bit more, but it’s probably more that the Racket slack isn’t a representative sample of normal Racket discussions.

Is that accurate to what everyone was saying?

Also, thanks for the feedback :slightly_smiling_face: