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.
