Thanks for the pointers, Ambrose, and thanks for core.typed! James
On Thursday, 24 April 2014 17:24:21 UTC-4, Ambrose Bonnaire-Sergeant wrote: > > I haven't tried anything like this. > > The most obvious pitfall is core.typed currently loads lazily and collects > type annotations only after check-ns. > > There's a bunch of tools for manipulating types in the checker. > > Thanks, > Ambrose > > > On Thu, Apr 24, 2014 at 11:18 PM, James MacAulay > <jmac...@gmail.com<javascript:> > > wrote: > >> I'm interested in exploring the use of the types provided by core.typed >> to guide function behavior at runtime. Specifically, I'd like to wrap >> existing functions such that the resulting functions behave in different >> ways depending on the type signatures of each original function. >> >> I'm imagining a setup where I have macros that get type information from >> core.typed at the time of macro-expansion, and either: >> >> * decide entirely at macro-expansion time how a function should be >> wrapped based on its type, or >> * somehow make the type information available at runtime, leaving the >> analysis of the types to runtime functions. >> >> As an example of the kind of decision I'd like to make based on types, I >> might look at `clojure.core/map` and say "I'll wrap `map` such that its >> first argument will be transformed in some particular way because the >> argument is a function, and the rest of the arguments will be transformed >> in some other way because they are collections." The reason I want to have >> type information for this is that I want the transformations to be >> dependent on the actual semantics of the original function, which is hinted >> at by the types. For example I can take the fact that an argument's type is >> some sort of collection and infer that the function is probably processing >> its contents; in that case I would want to transform the argument in a >> different way than if its type were `Any`, in which case I could conclude >> that even if the argument ends up being a collection at runtime, the >> original function must not be relying on that fact. >> >> Does anyone see any obvious pitfalls with this kind of thing? Any tips >> from the crowd? I'm not sure exactly the best way of actually "analyzing" >> the type signatures, but I'm hoping that I might find some tools for that >> in core.typed. >> >> Thanks for any help you can give! >> >> Cheers, >> James >> >> -- >> You received this message because you are subscribed to the Google >> Groups "Clojure" group. >> To post to this group, send email to clo...@googlegroups.com<javascript:> >> Note that posts from new members are moderated - please be patient with >> your first post. >> To unsubscribe from this group, send email to >> clojure+u...@googlegroups.com <javascript:> >> 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+u...@googlegroups.com <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > > -- 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.
