Feature Macros, an Alternative to Feature Expressions in Clojure

https://github.com/feature-macros/clojurescript/tree/feature-macros/feature-macros-demo

by wooby • 12 years ago

80 32 12 years ago

mklappstuhl2• 12 years ago

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

michaniskin5• 12 years 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 [] ...)`.)

_halgari2• 12 years 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 [] ...)`.

_halgari2• 12 years ago

a clean and simple approach to the problem, +1

pandeiro• 12 years ago

tldr:

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

brandonbloom6• 12 years 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.

wooby5• 12 years 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?

swannodette• 12 years ago

That's not equivalent to inline protocol implementation in both Clojure or ClojureScript. The point still stands, the proposal runs afoul of macro composition issues. This isn't to pass judgement on the proposal, but this is a tradeoff that is downplayed.

brandonbloom6• 12 years ago

Your change is invalid. I picked my example very carefully: You can not extend an interface to an object after the type has been created. That only works with protocols.

That said, there are countless examples. I already mentioned the proposed ns+ form, but there are a couple more in the design spec here: http://dev.clojure.org/display/design/Feature+Expressions

I'm not going to bother constructing more concrete examples, since it's trivial to do and each and everyone will have case-specific solutions that will seem "nicer" than feature expressions. But that's just it: It will be a case-by-case solution, rather than a general solution. Case-by-case application-centric solutions are preferable for the platform abstractions of your major subsystems, but often you just want to hack it and feature-macros simply don't offer the flexibility you need.

clojurian2• 12 years ago

wow much high horse, so snippy, much snark

Given you find the lack of "standard in-memory representation for tagged literals" [1] a problem, I'm wondering why you are so set on adding yet another feature with the same problem and don't understand why some might also be looking for an alternative.

[1] http://dev.clojure.org/display/design/Representing+EDN

brandonbloom6• 12 years ago

I didn't intend to be snippy or snarky, and I don't really think I was. I was simply pointing out the problems with this proposal, which has been proposed numerous times by numerous folks, but such proposals never addresses the tradeoffs. If you're willing to chat off-list about my communication style, I'm happy to make tone corrections in the future.

As for the "Representing EDN" design doc that I wrote. You're right to note similarity between tagged literals and feature expressions, however, I don't believe that they warrant the same tradeoff. One stated design goal of EDN is for intermediate processors to be able to handle self-describing data. They can already do that by defining a default tagged reader function. All I'm proposing there is that there be a single standard "uninterpreted" type, so that multiple intermediate processors can cooperate in handling self-describing data in the absence of special purpose tagged readers. Otherwise, each reader would need to perform an eager walk of each object to replace unknown types, and, by that point, they have no way of knowing what types they need to look for to replace in general.

By contrast, Clojure's reader already loses information necessary to represent Clojure source code as opposed to EDN data. The EDN data model is not rich enough on its own to represent code.

sgrove• 12 years 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.

mklappstuhl2• 12 years ago

I'm curious what problems came up in your conversation?

ICWiener2• 12 years ago

I am looking at one of the examples:

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?

michaniskin5• 12 years ago

I think the `case-host` macro is what you're looking for: https://github.com/feature-macros/clojurescript/blob/feature...

ICWiener2• 12 years ago

Ok, thanks. So unlike Common Lisp, symbol resolution does not occur at read time.

jballanc2• 12 years 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)

michaniskin5• 12 years ago

They're trivially implementable without feature expressions, as we demonstrated with our 20 lines of code.

smrtinsert2• 12 years ago

Except on Windows due to Boots current lack of support.

jballanc2• 12 years 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.

smrtinsert2• 12 years ago

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

Feature Macros, an Alternative to Feature Expressions in Clojure

Related Stories