is there a way to alias it to a function local name such as my_handy_function = <the above> I agree, though of course a single function call is a trivial examp

is there a way to alias it to a function local name such as my_handy_function = <the above> I agree, though of course a single function call is a trivial example. It would be nice if we made more use of intermediate variables for exposition to simplify complicated expressions more generally, too. But somehow this sort of idea rarely seems to get promoted whenever long lines come up in discussion. :-( You need a better editor. That is a solved problem. I respectfully disagree. Current editors, even the most flexible, rarely do more than automatically sorting out line breaks and indentation, and rarely provide more viewing options than collapsing blocks and jumping around to one cross reference or another. I am challenging the assumption that even the same symbols in the same order are necessarily appropriate in different contexts. I think there is a parallel here with the idea that a variable or function name can be relatively short if it’s only used locally with the full context available, but it might be better to use a longer, more detailed name or to add full qualifiers like which package/module/scope the entity lives in if it’s going to be used more widely. This is a simple case of adaptation that many programmers would apply instinctively, but it illustrates the basic principle that using the same name/representation for an idea regardless of context isn’t always helpful. Break it up into functions. But at the moment, breaking something into functions for ease of presentation typically equates to breaking something into functions to establish an independent scope, to allow wider reuse, or for other non-presentational reasons. For example, most languages offer no way to break down a moderately long pipeline algorithm into stages without separating each stage into its own function, complete with manually passing all of the context in and passing all of the results back. If many stages depend on much the same general context for that algorithm and the stages don’t make much sense outside of the algorithm as a whole, might we not consider some sort of lightweight, presentational way to split things up for better readability, without implying all the side effects and maintenance overheads of full functional decomposition?