> On May 5, 2017, at 10:05 AM, Dupéron Georges <jahvascriptman...@gmail.com> > wrote: > > Le vendredi 5 mai 2017 15:24:40 UTC+2, Matthias Felleisen a écrit : >> See >> https://docs.racket-lang.org/style/Units_of_Code.html#%28part._.Modules_and_their_.Interfaces%29 > > That's a very interesting document, thanks for the reference. Would you > suggest that, in this spirit, types for functions are moved to the top of the > file with the provide forms, instead of being specified alongside each > function?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Yes. There is a broken form of type-out that supports some of this already. I am hoping Sam will get to fixing this eventually. @samth - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > >>> On this topic, I have sometimes written recursive functions with expensive >>> contracts (when recursing down a list, a contract on the whole list will >>> have a total cost of O(n²)). >> >> 2. I consider this a horrible idea and I made sure define/contract does not >> do so. If you feel that unsure about recursive functions, I recommend using >> types. They help you avoid typos at that level. > > I'm using types wherever possible. Unfortunately, TR does not (yet) mix well > with contracts (but I'm aware that there is a pending PR for this). - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Yes. I am hoping Sam will get to fixing and approving this eventually. @samth - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > More importantly, Typed Racket cannot be used to write macro implementations, > for several reasons: I guess I underestimated what kind of code you’re writing. Your concerns are real. > I'm genuinely unsure which aspect of this idea you find horrible? > > * Is it because the contract is specified along the function, with > define/contract-out, instead of being written alongside the provide forms? If > so, separating the contract from the function definition, using a form > similar to TR's (: name type), would allow the contract to be specified next > to the provide form, but still have it applied to recursive function calls > during debugging. > > * Is it because turning off the contract for recursive calls would lower the > safety (i.e. the swim vest analogy)? In my case, the contract on the result > was strong enough to catch the error anyway, and the goal was only to catch > incorrect results as soon as possible, instead of waiting until they cross > the module boundary and are returned to the original caller, so that it is > easier to locate the exact source of the error. > > * Is it because of something else that I missed? > > In conclusion, I do agree that types are a much better option, and I do use > them wherever possible. Unfortunately, there are some cases where types > cannot be used (yet), and in those cases I'd like to get as much help as I > can from contracts when debugging, without imposing a horrendous cost during > normal development (which does not mean tossing all safety aside, but rather > allow errors to be caught at module boundaries instead of detecting them > nearly immediately). These goals do not seem insane to me, and I'm 100% open > to suggestions on how to achieve this :) . The cost and the false sense of security implied by a contract you ran on recursive calls and that you then turned off. I think that developers should write contracts and use them during testing and deployment in the same way. I did this decades ago for embedded realtime software and we’d be all better off if we did so. — Matthias -- 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.
