Alexis says that (-> vector? exact-integer? any/c void?)
is better than (-> vector? exact-integer? any/c vector?) because the former clearly signals the imperative nature of the function inside of the spec while the latter could be either a read-only or a RW function. Perhaps the real problem is one of the contract/type system. We have seen effect systems over and over again, though usually they try to express complicated invariants and have them checked at compile time. What if contract and type systems came with two arrows: ->! for imperative functions, as in “this function may mutate the given argument” -> for ‘pure’ functions, as in “this function promises not to mutate the given argument" but only in that they mutate a given argument. Then we could have both a ‘signal’ in the type/contract signature AND the “useful thing is returned” from Smalltalk (as Neil correctly reminds us). Of course, following my usual Laffer-curve-for-types argument, we should explore the usefulness of this idea with an inspection of existing code and other pragmatic explorations. ;; - - - [[ I think the idea of a fluent interface is a good one, but it doesn’t depend on OO and/or ‘self’ returns at all. We create fluently embedded DSLs in Racket all the time, and never touch either one of them. ]] -- 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.