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 
        -> 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 
For more options, visit

Reply via email to