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 Clojure/JVM. Each of those would cause a compilation error for the
other, I believe.
e.g. java.lang.Long and java.util.Date don't exist in ClojureScript, and
are the kinds of things you would want to conditionally compile on for
Clojure/JVM.
Andy
On Thu, Mar 7, 2013 at 5:44 AM, Jonathan Fischer Friberg <
odysso...@gmail.com> wrote:
> 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-dialect [& {:keys [clojurescript]}] clojurescript)
>
> Alternatively, we could have a def, say *clojure-dialect*, then:
> (defmacro case-dialect [& {:as m}] (get m *clojure-dialect*))
>
> (although the dialect should probably be part of *clojure-version* ... you
> get the idea)
>
> Jonathan
>
>
> On Thu, Mar 7, 2013 at 10:04 AM, Akhil Wali <akhil.wali...@gmail.com>wrote:
>
>> 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 is simple; when the reader parses a sexpr, and if there's a
>> feature expression,then only use the part that's relevant to the current
>> Clojure dialect.
>> The only complication with this scheme is that all information in
>> *clojure-version* is related to the version numbers only; however, this
>> could be changed easily.
>>
>>
>>
>> On Thu, Mar 7, 2013 at 7:46 AM, Brent Millare <brent.mill...@gmail.com>wrote:
>>
>>> +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 evaluation. Evaluation happens from the
>>> tag function.
>>>
>>> On Wednesday, March 6, 2013 8:24:15 PM UTC-5, Brian Goslinga wrote:
>>>>
>>>> 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 [<feature expression> <value>]. Using a reader literal
>>>> is simple, compatible with EDN, and allows for the feature expressions to
>>>> be backported to an older version of Clojure using a library.
>>>
>>> --
>>> --
>>> 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/groups/opt_out.
>>>
>>>
>>>
>>
>>
>>
>> --
>> Akhil Wali
>>
>> # http://github.com/darth10 <https://github.com/darth10>
>> # http://darth10.github.com
>>
>> --
>> --
>> 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/groups/opt_out.
>>
>>
>>
>
> --
> --
> 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/groups/opt_out.
>
>
>
--
--
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/groups/opt_out.
