On 11 April 2018 at 06:48:49, Matthias Felleisen ([email protected]) wrote: > 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"
I think this would be quite helpful. We can then easily enforce invariants like “the client-supplied function doesn’t mutate the given argument”. (Is there an existing way to enforce this?) On the other hand, I still like returning #<void> for such imperative functions, because: (1) functionality-wise the returned value would be redundant; (2) for fluent DSLs, it could be ambiguous which input argument should be returned, and the best choice may depend on how the API is used in the client code. -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
