> On Apr 10, 2018, at 14:00, David Storrs <david.sto...@gmail.com> > wrote: > > Aside from I/O, I can't think of too many cases where (void) is the > intuitively correct or most useful return value, but it is extremely > common throughout the built-in Racket functions. I'm not sure where > you're drawing the lines on 'API design' vs 'comprehensive > guidelines', but I'd sure like it if the guideline "Always return > something useful unless there's a really good reason not to" got > included.
There is definitely a school of thought that buys into the idea of returning “the thing being operated on” rather than returning nothing for side-effectful functions. I think this is most characterized by so-called “fluent interfaces”, a way of encoding DSLs into object-oriented languages. As far as I can tell, this was style has been around for a very long time, but it was really forced into mainstream usage by the runaway success of jQuery in the mid to late aughts. The advantage of fluent interfaces is significant if you have an API that involves frequent object creation and mutation. It makes it possible to program in a more expression-oriented style, similar to the way the GoF builder pattern is useful in C++/Java-style OO languages. However, it has a cost of imprecision: it’s not always clear which thing is the most obvious to return, and it masks when functions exist solely for side-effects. For an example of the first problem, consider the jQuery $.append function: $('.foo').append($('<p>Hello!</p>')) Which element does this return? Does it return the set of elements produced by $('.foo'), or does it return the new element created by $('<p>Hello!</p>')? Both answers are useful, and indeed, jQuery actually includes a separate $.appendTo function that does the exact same thing as $.append but flips the arguments around, mostly to make the method chaining work out more nicely in certain situations. This is an awkward thing for an API designer to worry about; it is confusing for a library to provide the exact same function that just happens to return a different one of its arguments. The other problem with always returning something is that returning #<void> is extremely meaningful: it means the function’s only purpose is to perform a side-effect. When contracts (or, in a statically typed language, types) are used precisely, they can be quite communicative without having to read anything but the signatures alone. When given a Racket function with the following signature: (-> vector? exact-integer? any/c void?) ...it’s pretty likely that function is vector-set!. But now imagine the same function returned the mutated vector: (-> vector? exact-integer? any/c vector?) Now it’s much less immediately clear that this function is intended to be used to perform a side-effect, and I might misinterpret it as returning a new vector instead of updating the existing one. You might argue that the benefit in chaining outweighs the cost of signature clarity, but I think Racket mostly eschews that idea because Racket is a language with a functional bent. It discourages using mutability where immutable structures will do, and of course, useful functions on immutable data cannot return #<void>. Therefore, it’s both (1) rare for idiomatic Racket to use lots of functions that produce #<void>, so they wouldn’t benefit much from threading arguments through, and (2) especially important that side-effectful functions are called out as such as efficiently as possible. Racket makes it easy to use the same value twice without forcing library authors to arbitrarily pick certain arguments to thread through side-effectful functions. Internal definition contexts are available almost everywhere, and there is a plethora of local binding forms. Ultimately, the choice to return #<void> instead of some input argument probably doesn’t dramatically help or harm the language (it would still be Racket if it aligned with the other school of thought), but I happen to like the choice Racket makes. Alexis : https://en.wikipedia.org/wiki/Fluent_interface : http://api.jquery.com/append/ : http://api.jquery.com/appendTo/ -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.