On 11 April 2018 at 06:48:49, Matthias Felleisen (matth...@felleisen.org) 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 racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
