6 ms·

Feature Macros, an Alternative to Feature Expressions in Clojure

80 points by wooby 12y ago

mklappstuhl 12y ago
Does this also affect the #_ discard macro? And what about anonymous functions like `#(+ 5 %)`? Since those are reader macros I assume yes?
- michaniskin 12y ago
  The Feature Macros proposal is only adding macros and vars to Clojure---the reader isn't modified at all. Since all of the things you mentioned are reader macros (as you pointed out), Feature Macros never even see them, so they won't be affected in any way. (Reader macros are expanded before regular macros are, so regular macros don't see things like `#(...)`, they see `(fn [] ...)`.)
  - _halgari 12y ago
    The great point made in the README is that we can't generate feature expressions. With feature macros we can have macros that generate cross-platform code. That's big in my mind. That hasn't been a problem with reader macros in the past since you don't need to generate `#(...)` if you have `(fn [] ...)`.
    - brandonbloom 12y ago
      See my comment here: https://news.ycombinator.com/item?id=8924227 https://news.ycombinator.com/item?id=8924227 I don't understand when I would ever want to generate a feature expression. The goal is to generate platform-specialized code. You never have to generate code that generates platform-specialized code!
_halgari 12y ago
a clean and simple approach to the problem, +1
pandeiro 12y ago
tldr: git clone git://github.com/feature-expressions/clojurescript cd clojurescript/feature-macros-demo make deps make demo
brandonbloom 12y ago
Many of the most useful applications of feature expressions simply will not work as macros. You'd need to create one new feature-cond enabled macro for each other macro use case. Feature expressions, on the other hand, are a general solution that can be used at the call site without having to reinvent every macro that may ever need platform-conditional behavior, like your ns+ macro. Consider the proposed +clj form in the body of an extend-protocol or a deftype: (defmacro +clj "Form is evaluated only in the JVM." [form] (when (= :clj *host*) form)) (deftype Foo SomeCommonProtocol (aMethod [blah blah] ...) (+clj JvmOnlyInterface (someMethod [blah] ...) ) ) Of course, this does not work. The deftype macro gets the +clj form unmodified and must handle it on its own. At best, you could have a syntax-quote style wrapper form: (feature-quote (deftype Foo SomeCommonProtocol (aMethod [blah blah] ...) (+clj JvmOnlyInterface (someMethod [blah] ...) ) )) However, this is essentially what Feature Expressions are anyway. Only broken, since macros don't only operate on syntax/edn, they can operate on any compile-phase value, like dates and times or the output of any tagged literal handler. Without being part of the phase before the macro expander, you can't prevent platform specific types from reaching the macro body. The reality is that Clojure, in the tradition of most lisps, has rigid read/compile/run phase separation where each phase has a varied evaluation strategy, but the phases run interleaved. Unlike say something like Mathematica, which does not run the reader interleaved with the evaluator - and the evaluator uses normal-order rather than applicative-order! Without such a uniform evaluation strategy (nevermind Mathematica's evaluator's other problems) it simply doesn't make sense to fight so hard against beefing up the read phase. Related: I've written before about how I don't think that this impacts tooling as badly as you guys thing it does. I just don't understand why you guys are so against feature expressions, nor do I think you've succeeded in proposing a desirable alternative.
- wooby 12y ago
  What's wrong with: (deftype Foo SomeCommonProtocol (aMethod [blah blah] ...)) (+clj (extend-type Foo JvmOnlyInterface (someMethod [blah] ...))) Can you come up with another example you consider intractable?
sgrove 12y ago
I was just talking about the potential problems of FX last night - very interesting to see such an impressive and simple alternative approach. I'm not sure what the drawbacks are, but looking forward to seeing the discussion that grows from this.
- mklappstuhl 12y ago
  I'm curious what problems came up in your conversation?
ICWiener 12y ago
I am looking at one of the examples: https://github.com/feature-macros/clojurescript/blob/feature-macros/feature-macros-demo/src/demo/util.clj https://github.com/feature-macros/clojurescript/blob/feature... But if I run Clojure on the JVM, the following fails: (def host nil) (defn foo [] (when (= :cljs host) (gstring/format "something"))) ... the error being that there is no "gstring" namespace. Since the proposed solution with macros would produce such code (I am right?), how does it solve the issue of namespaces that only exist in a specific platform?
- michaniskin 12y ago
  I think the `case-host` macro is what you're looking for: https://github.com/feature-macros/clojurescript/blob/feature-macros/feature-macros-demo/boot-shim.clj#L13-L15 https://github.com/feature-macros/clojurescript/blob/feature...
  - ICWiener 12y ago
    Ok, thanks. So unlike Common Lisp, symbol resolution does not occur at read time.
jballanc 12y ago
It seems to me that Feature Macros will be trivially implementable as a library once Feature Expressions land: #+clj (def *host* :clj) #+cljs (def *host* :cljs)
- michaniskin 12y ago
  They're trivially implementable without feature expressions, as we demonstrated with our 20 lines of code.
  - smrtinsert 12y ago
    Except on Windows due to Boots current lack of support.
    - wooby 12y ago
      The proposal is not dependent on boot, only our demonstration of it is.
  - jballanc 12y ago
    Right, but if feature expressions are part of "Clojure the language" then feature macros can be implemented as a library. The reverse wouldn't work. Ergo, as attractive as I find feature macros, I think this argues that feature expressions are more "fundamental" and therefore deserving to be part of the core language.
smrtinsert 12y ago
I do like the idea of keeping them regular forms as it feels more future proof than cljx style expressions.

80 points by wooby 12y ago

Does this also affect the #_ discard macro? And what about anonymous functions like `#(+ 5 %)`? Since those are reader macros I assume yes?

michaniskin 12y ago
The Feature Macros proposal is only adding macros and vars to Clojure---the reader isn't modified at all. Since all of the things you mentioned are reader macros (as you pointed out), Feature Macros never even see them, so they won't be affected in any way. (Reader macros are expanded before regular macros are, so regular macros don't see things like `#(...)`, they see `(fn [] ...)`.)
- _halgari 12y ago
  The great point made in the README is that we can't generate feature expressions. With feature macros we can have macros that generate cross-platform code. That's big in my mind. That hasn't been a problem with reader macros in the past since you don't need to generate `#(...)` if you have `(fn [] ...)`.
  - brandonbloom 12y ago
    See my comment here: https://news.ycombinator.com/item?id=8924227 https://news.ycombinator.com/item?id=8924227 I don't understand when I would ever want to generate a feature expression. The goal is to generate platform-specialized code. You never have to generate code that generates platform-specialized code!

_halgari 12y ago

a clean and simple approach to the problem, +1

pandeiro 12y ago

tldr: git clone git://github.com/feature-expressions/clojurescript cd clojurescript/feature-macros-demo make deps make demo

brandonbloom 12y ago

Many of the most useful applications of feature expressions simply will not work as macros. You'd need to create one new feature-cond enabled macro for each other macro use case. Feature expressions, on the other hand, are a general solution that can be used at the call site without having to reinvent every macro that may ever need platform-conditional behavior, like your ns+ macro. Consider the proposed +clj form in the body of an extend-protocol or a deftype: (defmacro +clj "Form is evaluated only in the JVM." [form] (when (= :clj *host*) form)) (deftype Foo SomeCommonProtocol (aMethod [blah blah] ...) (+clj JvmOnlyInterface (someMethod [blah] ...) ) ) Of course, this does not work. The deftype macro gets the +clj form unmodified and must handle it on its own. At best, you could have a syntax-quote style wrapper form: (feature-quote (deftype Foo SomeCommonProtocol (aMethod [blah blah] ...) (+clj JvmOnlyInterface (someMethod [blah] ...) ) )) However, this is essentially what Feature Expressions are anyway. Only broken, since macros don't only operate on syntax/edn, they can operate on any compile-phase value, like dates and times or the output of any tagged literal handler. Without being part of the phase before the macro expander, you can't prevent platform specific types from reaching the macro body. The reality is that Clojure, in the tradition of most lisps, has rigid read/compile/run phase separation where each phase has a varied evaluation strategy, but the phases run interleaved. Unlike say something like Mathematica, which does not run the reader interleaved with the evaluator - and the evaluator uses normal-order rather than applicative-order! Without such a uniform evaluation strategy (nevermind Mathematica's evaluator's other problems) it simply doesn't make sense to fight so hard against beefing up the read phase. Related: I've written before about how I don't think that this impacts tooling as badly as you guys thing it does. I just don't understand why you guys are so against feature expressions, nor do I think you've succeeded in proposing a desirable alternative.

wooby 12y ago
What's wrong with: (deftype Foo SomeCommonProtocol (aMethod [blah blah] ...)) (+clj (extend-type Foo JvmOnlyInterface (someMethod [blah] ...))) Can you come up with another example you consider intractable?

sgrove 12y ago

I was just talking about the potential problems of FX last night - very interesting to see such an impressive and simple alternative approach. I'm not sure what the drawbacks are, but looking forward to seeing the discussion that grows from this.

mklappstuhl 12y ago
I'm curious what problems came up in your conversation?

ICWiener 12y ago

I am looking at one of the examples: https://github.com/feature-macros/clojurescript/blob/feature-macros/feature-macros-demo/src/demo/util.clj https://github.com/feature-macros/clojurescript/blob/feature... But if I run Clojure on the JVM, the following fails: (def host nil) (defn foo [] (when (= :cljs host) (gstring/format "something"))) ... the error being that there is no "gstring" namespace. Since the proposed solution with macros would produce such code (I am right?), how does it solve the issue of namespaces that only exist in a specific platform?

michaniskin 12y ago
I think the `case-host` macro is what you're looking for: https://github.com/feature-macros/clojurescript/blob/feature-macros/feature-macros-demo/boot-shim.clj#L13-L15 https://github.com/feature-macros/clojurescript/blob/feature...
- ICWiener 12y ago
  Ok, thanks. So unlike Common Lisp, symbol resolution does not occur at read time.

jballanc 12y ago

It seems to me that Feature Macros will be trivially implementable as a library once Feature Expressions land: #+clj (def *host* :clj) #+cljs (def *host* :cljs)

michaniskin 12y ago
They're trivially implementable without feature expressions, as we demonstrated with our 20 lines of code.
- smrtinsert 12y ago
  Except on Windows due to Boots current lack of support.
  - wooby 12y ago
    The proposal is not dependent on boot, only our demonstration of it is.
- jballanc 12y ago
  Right, but if feature expressions are part of "Clojure the language" then feature macros can be implemented as a library. The reverse wouldn't work. Ergo, as attractive as I find feature macros, I think this argues that feature expressions are more "fundamental" and therefore deserving to be part of the core language.

smrtinsert 12y ago

I do like the idea of keeping them regular forms as it feels more future proof than cljx style expressions.