Re: Strictly tagged clojure
That might be a nice feature, but it would be quite different from what we did. We kept our extension (almost) entirely additive, so that old code will have unchanged behavior in strict mode, and strict code will continue to compile and run correctly when compiled with a version of clojure with no support for this strict mode. Your proposed feature would create function declarations that are uncompilable in any existing version of clojure, which I doubt anyone would find acceptable anytime soon. On Saturday, August 8, 2015 at 4:44:02 AM UTC-7, Shantanu Kumar wrote: > > This is a very useful enhancement indeed. I wonder if it is feasible (or > if it makes sense) to extend this to have type based overloading: > > (defn foo > ([^TypeA a] ..) > ([^TypeB b] ..)) > > Shantanu > > On Friday, 7 August 2015 11:40:42 UTC+5:30, Alex Miller wrote: >> >> Hey Reid, >> >> I've forwarded this over to Rich and Stu to take a look at. >> >> Alex >> >> On Thursday, August 6, 2015 at 11:46:09 AM UTC-5, Reid McKenzie wrote: >>> >>> Hello all, >>> >>> Alan Malloy and I recently implemented[1] and contributed[2] an opt-in >>> strict tags mode to Alexander Yakushev's Skummet compiler. To >>> summarize the linked blog post and merge request, we created the >>> `clojure.core/*strict-tags*` dynamic var which may either be set by >>> users at the namespace level a la `clojure.core/*warn-on-reflection*` >>> or set on a per-fn basis with the `^:strict` metadata annotation. When >>> in strict mode, type hints are interpreted not as optional and late >>> checked hints (the Clojure default) but as eagerly checked static >>> types on tagged locals and expressions. >>> >>> The effect of these changes is to greatly reduce the number of >>> checkcast instructions emitted when performing tagged interop should >>> users opt into using strict mode and accept the requisite >>> responsibility for managing their types. >>> >>> While the odds that these changes will be accepted as-is are slim, we >>> think they represent a valuable addition to the language and so >>> present them for your consideration. >>> >>> - Reid >>> >>> [1] - http://blog.factual.com/strictly-tagged-clojure >>> [2] - https://github.com/alexander-yakushev/clojure/pull/1 >>> >>> -- 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.
Re: Strictly tagged clojure
This is a very useful enhancement indeed. I wonder if it is feasible (or if it makes sense) to extend this to have type based overloading: (defn foo ([^TypeA a] ..) ([^TypeB b] ..)) Shantanu On Friday, 7 August 2015 11:40:42 UTC+5:30, Alex Miller wrote: > > Hey Reid, > > I've forwarded this over to Rich and Stu to take a look at. > > Alex > > On Thursday, August 6, 2015 at 11:46:09 AM UTC-5, Reid McKenzie wrote: >> >> Hello all, >> >> Alan Malloy and I recently implemented[1] and contributed[2] an opt-in >> strict tags mode to Alexander Yakushev's Skummet compiler. To >> summarize the linked blog post and merge request, we created the >> `clojure.core/*strict-tags*` dynamic var which may either be set by >> users at the namespace level a la `clojure.core/*warn-on-reflection*` >> or set on a per-fn basis with the `^:strict` metadata annotation. When >> in strict mode, type hints are interpreted not as optional and late >> checked hints (the Clojure default) but as eagerly checked static >> types on tagged locals and expressions. >> >> The effect of these changes is to greatly reduce the number of >> checkcast instructions emitted when performing tagged interop should >> users opt into using strict mode and accept the requisite >> responsibility for managing their types. >> >> While the odds that these changes will be accepted as-is are slim, we >> think they represent a valuable addition to the language and so >> present them for your consideration. >> >> - Reid >> >> [1] - http://blog.factual.com/strictly-tagged-clojure >> [2] - https://github.com/alexander-yakushev/clojure/pull/1 >> >> -- 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.
Re: Strictly tagged clojure
Hey Reid, I've forwarded this over to Rich and Stu to take a look at. Alex On Thursday, August 6, 2015 at 11:46:09 AM UTC-5, Reid McKenzie wrote: > > Hello all, > > Alan Malloy and I recently implemented[1] and contributed[2] an opt-in > strict tags mode to Alexander Yakushev's Skummet compiler. To > summarize the linked blog post and merge request, we created the > `clojure.core/*strict-tags*` dynamic var which may either be set by > users at the namespace level a la `clojure.core/*warn-on-reflection*` > or set on a per-fn basis with the `^:strict` metadata annotation. When > in strict mode, type hints are interpreted not as optional and late > checked hints (the Clojure default) but as eagerly checked static > types on tagged locals and expressions. > > The effect of these changes is to greatly reduce the number of > checkcast instructions emitted when performing tagged interop should > users opt into using strict mode and accept the requisite > responsibility for managing their types. > > While the odds that these changes will be accepted as-is are slim, we > think they represent a valuable addition to the language and so > present them for your consideration. > > - Reid > > [1] - http://blog.factual.com/strictly-tagged-clojure > [2] - https://github.com/alexander-yakushev/clojure/pull/1 > > -- 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.
Strictly tagged clojure
Hello all, Alan Malloy and I recently implemented[1] and contributed[2] an opt-in strict tags mode to Alexander Yakushev's Skummet compiler. To summarize the linked blog post and merge request, we created the `clojure.core/*strict-tags*` dynamic var which may either be set by users at the namespace level a la `clojure.core/*warn-on-reflection*` or set on a per-fn basis with the `^:strict` metadata annotation. When in strict mode, type hints are interpreted not as optional and late checked hints (the Clojure default) but as eagerly checked static types on tagged locals and expressions. The effect of these changes is to greatly reduce the number of checkcast instructions emitted when performing tagged interop should users opt into using strict mode and accept the requisite responsibility for managing their types. While the odds that these changes will be accepted as-is are slim, we think they represent a valuable addition to the language and so present them for your consideration. - Reid [1] - http://blog.factual.com/strictly-tagged-clojure [2] - https://github.com/alexander-yakushev/clojure/pull/1 -- 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.
