>From what I understand, the reader will call the tag function, thus being
executed at read time and not compile time.
On Thursday, March 7, 2013 4:04:15 AM UTC-5, Akhil Wali wrote:
>
> IMHO features expressions should be evaluated at read-time only.
> Putting it off till the compilation phase on
The macro doesn't have that problem - as long as the code is inside the
macro.
I.e. this works (in clojure):
(case-dialect :clojurescript some.class/PROP)
But this doesn't:
(defn get-PROP [] some.class/PROP)
(case-dialect :clojurescript (get-PROP))
If I'm not mistaken, the proposed expressions
Class names are read in as symbols
On Mar 7, 2013 7:10 AM, "Andy Fingerhut" wrote:
> I may be wrong, but I think this, and anything else that tries to solve
> this problem after read time, will fail for one of the primary uses of
> feature macros: Java packages/namespaces that exist for Clojure/J
I have not read all of the discussions about this topic, so I
apologize if it has already been discussed, but I was wondering why
there does not seem to be any discussion about the openness of such a
system. As far as I know, CL-style feature expressions are closed in
the same sense that a cond for
I may be wrong, but I think this, and anything else that tries to solve
this problem after read time, will fail for one of the primary uses of
feature macros: Java packages/namespaces that exist for Clojure/JVM but not
ClojureScript, and JavaScript namespaces that exist for ClojureScript but
not Cl
Isn't it possible to solve this with a simple macro?
(case-dialect
:clojure (... clojure code ...)
:clojurescript (... clojurescript code ...))
Then, in jvm clojure, it could be implemented as:
(defmacro case-dialect [& {:keys [clojure]}] clojure)
and in clojurescript:
(defmacro case-diale
IMHO features expressions should be evaluated at read-time only.
Putting it off till the compilation phase only complicates things.
So I'm actually favoring a preprocessing step like here -
http://dev.clojure.org/display/design/Feature+Expressions?focusedCommentId=6390066#comment-6390066
The idea
+1
Isn't is possible to accomplish all these efforts using tagged
literals? https://github.com/miner/wilkins
This way the facilities for read-time code generation can be customized and
any reader that supports tagged-literals will support this. All of this is
data provided as arguments, no eva
Do we really need new syntax for feature expressions? Although it would be
more ugly than CL's feature expressions, we could use a reader literal. For
example #feature [ ]. Using a reader literal is
simple, compatible with EDN, and allows for the feature expressions to be
backported to an older
> I believe protocols can entirely alleviate the need for feature expressions.
How do you figure that?
One major incompatibility between Clojure and ClojureScript currently is that
the protocols don't match up. If you want a deftype form that is 90% the same,
but has a conditional switch for a
I believe protocols can entirely alleviate the need for feature expressions.
On Saturday, February 16, 2013 5:28:59 PM UTC+1, Mimmo Cosenza wrote:
>
> Hi all,
> the more I learn cli/cljs the more I find myself in looking for libraries
> running on both sides of a clojurean web app. hiccup/valip,
11 matches
Mail list logo
