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 form is closed by comparison with a
protocol : you cannot add in a new form without touching the original
source code.
I would like the final system to offer the possibility for a library
author to document the host-specific functionality that has to be
present, and to allow for that functionality to be provided
externally, just as I can extend a protocol to make my new record work
with existing code.
I guess that would kind of boil down to what vemv was saying :
conceptually, this would be the same as isolating all of your
platform-specific code inside a protocol and passing an instance of
that protocol to all of your functions, though I am pretty sure there
is a better way to implement this, as it should definitely be a
compile-time replacement instead of a runtime invocation.
Why not take some inspiration from internationalization à la NIB file?
This is kind of the same issue. Say I could write my clojure code for
the JVM normally:
(defn blank? [s] (every? #(Character/isWhitespace %) s))
but with an extra annotation, either through a data literal or a
reader extension. Say:
(defn blank? [s] (every? #platform #(Character/isWhitespace %) s))
To produce a clojurescript version, for example, I could run some tool
that traverses the code and finds all the forms annotated with
#platform, creates a "translation file" if it does not already exist
(adds entries if it does) which would basically be a map of the forms
as they are in the code to the forms as they should be for the new
platform. This file could for example contain a map like :
{"#(Character/isWhitespace %)" (throw)}
As this file would be platform specific, the default value of
"(throw)" would obviously be the platform-specific version. If I
wanted it to work for clojurescript, I could go into that file and
change the file to look like
{"#(Character/isWhitespace %)" #(gstring/isEmpty %)}
Tools such as kibit could be used to automatically find most of the
places where a platform-specific form is used and generate that
sort-of-NIB file.
The map could contain more information (such as source file and such),
but presumably if you have two identical platform-specific forms in
your code their translation should also be identical.
On 7 March 2013 16:10, 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 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
>>> # 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.
>
>
--
--
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.
