Le vendredi 5 mai 2017 19:10:12 UTC+2, Matthias Felleisen a écrit : > > 1. (define/contract (foo input) (-> blah (listof integer?)) …) > > > > This has a O(n²) cost. > > I assume input is also a list. Then Racket’s define/contract is NOT O(n²) > because the recursion of foo is considered INSIDE the boundary. You have to > jump through hoops to get define/contract to check recursive calls. (If it > does so now, it’s a bug.)
Well I feel silly, now :) . I didn't know that define/contract had this behaviour. I understand much better the "sense of false security" you mentioned earlier! Thanks for making this clear. > > 4. (define/contract (foo input) (-> blah (listof integer?)) …) > > where the contract check stops when it encounters an already-checked value. > > [What’s the diff to 1?] The difference would be that a partial check would be performed at each recursion step, stopping when data which has already been validated by the same contract is encountered. But that's wishful thinking for now. > > [… stuff about nanopass …] > > Have you considered using nano-pass specific types? Leif and I did for a > brief time, but we moved on to other things. (We had a private exchange on > that one.) Yes, I am using customised variants and structure types, which offer the features I need. Typed Racket is still used to perform the actual type-checking, as these variants & structures translate down to regular unions and structs, with a few adjustments. The run-time checks are only performed for things which cannot be easily expressed by the type system, and cannot be guaranteed by macro-enforced discipline/design patterns. -- 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.
