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 racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
