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
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
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
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
Class names are read in as symbols
On Mar 7, 2013 7:10 AM, Andy Fingerhut andy.finger...@gmail.com 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
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
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 only
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
+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
I personally think the CL feature expression approach is satisfactory.
The more I think about it, the less I think that the CL Feature Expression
approach is satisfactory as is.
I'm now reasonably convinced that, horror of horrors, we should look to the C
preprocessor for inspiration.
CL's
Honestly, writing clear understandable code is hard enough already.
I have voiced this opinion before in other discussions on this topic - but my
view is that inline feature expressions should be used very sparingly. And
preferably, there should also be other options for portability - e.g.
,
enliven/encofus, just to name few of them.
Is there a kind of agreement on which approach to follow to solve the
features expression problem. I already used the leon-cljsbuild workaround
(i.e. :crossovers option) and cljx feature approach.
I just read about feature expression problem
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, c2,
enliven/encofus, just to name few of them.
Is there a kind of agreement on which approach to follow to solve the features
expression problem. I
on which approach to follow to solve the
features expression problem. I already used the leon-cljsbuild workaround
(i.e. :crossovers option) and cljx feature approach.
I just read about feature expression problem here:
http://dev.clojure.org/display/design/Feature+Expressions
The last
of agreement on which approach to follow to solve the
features expression problem. I already used the leon-cljsbuild workaround
(i.e. :crossovers option) and cljx feature approach.
I just read about feature expression problem here:
http://dev.clojure.org/display/design/Feature+Expressions
mimmo.cose...@gmail.comwrote:
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, c2,
enliven/encofus, just to name few of them.
Is there a kind of agreement on which approach to follow to solve the
features
of agreement on which approach to follow to solve the
features expression problem. I already used the leon-cljsbuild workaround
(i.e. :crossovers option) and cljx feature approach.
I just read about feature expression problem here:
http://dev.clojure.org/display/design/Feature+Expressions
17 matches
Mail list logo
