Ah, OK. It'll be interesting to see how this turns out. Andrew Oberstar
On Sat Nov 15 2014 at 9:40:45 AM Daniel Kersten <[email protected]> wrote: > Feature expressions would allow for this by allowing you to define the > function multiple times, once per platform. Something like this (cljx) code: > > #+clj (defn foo [] (println "Clojure implementation") > #+cljs (defn foo [] (js/console.log "ClojureScript implementation") > > On 15 November 2014 14:59, Andrew Oberstar <[email protected]> wrote: > >> I apologize if this is naïve and/or incomplete; I'm very new to Clojure. >> Would a better solution be to use something closer to protocols and >> multimethods, where functions could be "polymorphic" by platform rather >> than polymorphic by arguments? >> >> This would make it open for users to add support for platforms the >> library author didn't support. At a quick glance, it looks like a feature >> expression wouldn't allow for this. >> >> Andrew Oberstar >> >> >> On Sat, Nov 15, 2014, 6:56 AM Daniel Kersten <[email protected]> wrote: >> >>> I didn't ask for feature expressions in the survey, but I've been >>> wishing for a better way for writing cross-target code, especially >>> libraries. >>> >>> I've never quite managed to bring myself to develop with cljx - I love >>> it as a consumer of libraries, but I haven't quite managed to make it wo >>> wellrk in my workflow for my own code, so haven't been using it. >>> I've found it a bit too slow and clunky and don't quite know how it fits >>> with other tools I use: eg, browser repl, figwheel, devcards. >>> I also find it less than desirable to run yet another java process >>> alongside my client nrepl, cljsbuild auto (or figwheel) and server clj >>> application. Its already a heavier weight setup than I'd like. >>> >>> I imagine most of these concerns can be addressed in cljx itself, of >>> course, but as it stands it's not ideal and improvements are needed >>> -somewhere-. If it's part of the reader, though, then I don't need a >>> separate stage. Plus any code invoking the reader would be target aware. >>> >>> On Sat, 15 Nov 2014 12:08 Julien Eluard <[email protected]> wrote: >>> >>>> Hi Colin, >>>> >>>> CLJX definitively does the job but at the price of being very brittle >>>> and having to juggle with paths and classpaths. Also this is a leaky hack >>>> as you have to make all tooling aware of it (editor, nrepl, ..). It usually >>>> sort of work up to the point it doesn't. CLJX does the magic by generating >>>> files and I must be aware of it while I would expect this to disappear with >>>> Feature Expressions. >>>> I would very much like to see something like that standardized and >>>> transparent. >>>> >>>> Some specific answers: >>>> 3. No. This goes much beyond. On the browser you have access to much >>>> more than one would expect being part of a standard librairies. >>>> See [1] for an example. >>>> Also it's not clear how macro could be handled this way. >>>> >>>> 4. Node support (and related scenario) is a real problem. It's not >>>> clear to me how to handle it and if this should be addressed by Feature >>>> Expressions. See [2] for a concrete example. >>>> >>>> >>>> [1] https://github.com/davidsantiago/hickory >>>> [2] https://github.com/davidsantiago/hickory/issues/17 >>>> >>>> Julien >>>> >>>> 2014-11-15 4:09 GMT-03:00 Max Kreminski <[email protected]>: >>>> >>>> On Friday, November 14, 2014 7:22:39 PM UTC-8, Colin Fleming wrote: >>>>> > Hi all, >>>>> > >>>>> > There's a discussion going on right now on clojure-dev ( >>>>> https://groups.google.com/d/topic/clojure-dev/6pnIeXFRwnI/discussion) >>>>> about the Feature Expressions functionality currently slated for Clojure >>>>> 1.7. This was one of the most requested features in the recent state of >>>>> clj/cljs survey, particularly by cljs users. However there seems to be a >>>>> lot of confusion about exactly what the needs are here. I think everyone >>>>> would be very interested in feedback, either here or on the clojure-dev >>>>> thread if you have access, on why this is so important to cljs users. >>>>> Specifically: >>>>> > Is there something specific in the current proposal that is >>>>> especially attractive to you, or is Feature Expressions more a proxy for >>>>> "it should be easier to write cross-platform code"?Is there a strong >>>>> argument for having this in the language, instead of in a tool like CLJX? >>>>> Is this a fundamental failing of CLJX, or is the tooling perhaps just more >>>>> awkward to use than it could be? >>>>> > Could these needs be totally or mostly met by better cross platform >>>>> libraries, like string and date handling?Would more features be useful >>>>> than >>>>> simply "this is CLJS code", i.e. would this be helpful for Node support? >>>>> Is >>>>> there no other way to get that support, i.e. through better libraries or >>>>> macros? >>>>> > I don't know the answers to any of these questions or have strong >>>>> opinions about them since I don't use CLJS or CLJX, but I do write tooling >>>>> that has to support them so I'd really like to understand this better. >>>>> > >>>>> > If any of you are interested in this and will be at the conj, >>>>> there'll be an unsession about Feature Expressions there - please come and >>>>> tell us what you think! >>>>> > Cheers, >>>>> > Colin >>>>> >>>>> I'm primarily a ClojureScript dev but I sometimes work with Clojure on >>>>> the JVM as well. Here's my perspective. >>>>> >>>>> 1. I have no strong feelings about feature expressions in particular; >>>>> I'm just excited to see the core team endorsing anything that will make >>>>> cross-platform development simpler out of the box. >>>>> >>>>> 2. I have no major problems with CLJX (I suppose it's a bit of a hack, >>>>> but it suffices for my purposes) except that of adoption. If I want to >>>>> make >>>>> any of the Clojure core repos CLJS-compatible, I can't use CLJX to write >>>>> shared platform-agnostic code – the core team doesn't allow it. If a >>>>> particular JVM Clojure library's maintainer doesn't like CLJX for whatever >>>>> reason, I can't use that library in my CLJS project without forking it and >>>>> maintaining the fork. At the moment, Clojure and CLJS code are >>>>> incompatible >>>>> by default, which feels like the opposite of how things "should be". >>>>> >>>>> 3. Better cross-platform libraries might get us halfway there but they >>>>> won't completely obviate the need for CLJX, feature expressions, or >>>>> something similar. When trying to write cross-platform exception handling >>>>> code, for instance, I still regularly find myself needing to replace >>>>> instances of "Exception" with "js/Error"; as long as these sorts of >>>>> situations are still coming up I'll always want to have something like >>>>> CLJX >>>>> or feature expressions in my toolbox. >>>>> >>>>> 4. I can't really speak to this point too much, as I've never really >>>>> run into any problems trying to work with e.g. Node vs browser JS. In the >>>>> long term it might make sense to divide the "Clojure platform" into a set >>>>> of specific features (e.g. macros, reified namespaces, clojure.string, >>>>> etc) >>>>> and allow users to test whether each of these features is "present" on any >>>>> given implementation, but whether there exists an actual use-case for this >>>>> is beyond me and it seems totally out of scope for the current discussion >>>>> anyway. >>>>> >>>>> To get on my soapbox for a bit, I think the gap between Clojure and >>>>> CLJS is gradually widening because the language as currently implemented >>>>> makes it difficult to write and maintain cross-platform code. CLJX's >>>>> feature set is all I really need, but right now every member of the >>>>> community has to specifically "opt in" to writing cross-platform code by >>>>> manually setting up CLJX for every project. Couple that with the fact that >>>>> I specifically can't use CLJX when I'm contributing to the core libraries, >>>>> and we wind up with a lot of duplicated effort on both sides of the >>>>> Clojure/CLJS fence. >>>>> >>>>> The sooner we get feature expressions or something equivalent baked >>>>> into core, the better. Only once the core team has blessed a particular >>>>> solution will we see the current situation replaced by the "cross-platform >>>>> by default" scenario I'd prefer. >>>>> >>>>> -- >>>>> Note that posts from new members are moderated - please be patient >>>>> with your first post. >>>>> --- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "ClojureScript" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to [email protected]. >>>>> To post to this group, send email to [email protected]. >>>>> Visit this group at http://groups.google.com/group/clojurescript. >>>>> >>>> -- >>>> Note that posts from new members are moderated - please be patient with >>>> your first post. >>>> --- >>>> You received this message because you are subscribed to the Google >>>> Groups "ClojureScript" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> To post to this group, send email to [email protected]. >>>> Visit this group at http://groups.google.com/group/clojurescript. >>>> >>> -- >>> Note that posts from new members are moderated - please be patient with >>> your first post. >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "ClojureScript" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To post to this group, send email to [email protected]. >>> Visit this group at http://groups.google.com/group/clojurescript. >>> >> -- >> Note that posts from new members are moderated - please be patient with >> your first post. >> --- >> You received this message because you are subscribed to the Google Groups >> "ClojureScript" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To post to this group, send email to [email protected]. >> Visit this group at http://groups.google.com/group/clojurescript. >> > > -- > Note that posts from new members are moderated - please be patient with > your first post. > --- > You received this message because you are subscribed to the Google Groups > "ClojureScript" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/clojurescript. > -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/clojurescript.
