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
> ->! for imperative functions, as in “this function may mutate the given
> -> 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
For more options, visit https://groups.google.com/d/optout.