On Monday, May 9, 2016 at 5:36:53 PM UTC-4, Didier wrote: > > At Clojurewest 2016, Matthias Felleisen gave a great keynote about the > pragmatism of soundness for maintening large code bases. He mentioned that > adding type gradually was useful, but only when the border between typed > land and untyped land is guarded. He mentioned how Racket does that. He > also talked about the cost of doing so, which seem to remain an open > question. > > I'm wondering if any of this has been taken up by somebody in Clojure to > try to do the same? My understanding is typed clojure does not protect the > border between typed and untyped. Therefore, you do not have the guarantee > that your typed code will be correct for all its usage. > I believe that Ambrose (the core developer/maintainer of Typed Clojure) has been focusing on that very topic as of late: CTYP-309: “Export typed vars with contracts to untyped namespaces” <http://dev.clojure.org/jira/browse/CTYP-309>.
> Also, does anyone know exactly what he meant by the cost? Is doing gradual > typing causing slower runtimes, slower compilation, does it hamper the > dynamism, etc. > I expect that dynamically-checked contracts would (at least) cause slower runtimes in the cases of untyped-calling-typed code or typed-calling-untyped code; I think typed-calling-typed code would skip the runtime contract verification. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.