Ok, here is an obvious follow-on idea:
Let the file suffix correspond to the tagged literal with which the
file contents are interpreted.
so foo.clj would get read as #clj
and so forth. (non-official releases would use namespace-qualified
suffixes, though the "/" would have to get munged appror
I think there are 2 big ideas of relevant to this problem.
1. Tagged literals
2. Compiler-as-a-service
Tagged literals do not have the drawbacks of metadata, or of macros.
They are ideal for indicating the semantics of a piece of data. If a
piece of data needs to be tagged as representing clojur
I agree with all of that.
If you are extracting and writing jvm, py, clr, cljs interop as a means to
enable portability, then you are effectively writing extensions to the core
clojure platform libs.
I.e providing a base, in a similar way that, for example, clojure.string
extends common strin
I have no idea what, if anything, Clojure the language(s) *should* do
about this issue, but I can explain the reasoning behind CLJX.
CLJX uses the reader to statically analyze toplevel forms in a file
and generate new ones according to declarative rewrite rules.
The motivating use case was to make
I posed this question briefly in this post here:
https://groups.google.com/d/msg/clojure/K65Va0rCCls/Ow5bAJ_YTGIJ. In this
real world example of porting Korma over to ClojureCLR, I encountered the
following things:
- One namespace which handled JDBC interaction needed to be rewritten
c
Vinzent writes:
>> I'd still prefer a more general plain-macro version for conditional
>> compilation with arbitrary tests instead of hardcoded platform and
>> version keys.
>
> I agree, although nothing prevents us from something like :condition
> (some-expr) being evaluating for such complex ca
>
> But my own programs already use :platform and :version metadata
> with completely different semantics. (Well, no, they don't, but it could
>
> be.)
>
That's not a problem, since the same is true for :doc, :macro, :arglists,
etc, etc. Also, meta on expressions is probably not used so often.
Timothy Baldridge writes:
> I'm starting to like the hybrid approach as well. We could create a
> new version of "require" that's a conditional load:
>
> (cond-require {:platform :jvm :version 7} 'core.platform.jvm.mymodule)
> (cond-require {:platform :clr :version 4.5} 'core.platform.clr.mymodul
I'm starting to like the hybrid approach as well. We could create a
new version of "require" that's a conditional load:
(cond-require {:platform :jvm :version 7} 'core.platform.jvm.mymodule)
(cond-require {:platform :clr :version 4.5} 'core.platform.clr.mymodule)
With a single modification to cor
Vinzent writes:
>> But why would that be better than a reader macro
>> #+:jvm(load "jvm/lib")
>> #+:python (load "python/lib")
>
>
> I don't think it's "better", this two options are rather equivalent.
> The only difference is that #+ would require new reader entities,
> while variant wit
>
> ^{:platform :jvm} (load "jvm/lib")
^{:platform :python} (load "python/lib")
or platform metadata attached to the 'ns' form should be trated as "this
whole file is for this platform". This way, in src/py/blah.clj you'd have
^{:platform :python}
(ns blah)
...
(your code)
...
without relyi
Aaron Cohen writes:
> I think all your concerns can be addressed by carefully using the
> metadata solution?
>
> ^{:platform :jvm} (load "jvm/lib")
> ^{:platform :python} (load "python/lib")
But why would that be better than a reader macro
#+:jvm(load "jvm/lib")
#+:python (load "python/
On Thu, Apr 12, 2012 at 11:31 PM, Dave Sann wrote:
> -1 for metadata
> +1 for file extensions or paths.
>
> I don't think metadata or in-file conditional compilation is the right
> tool for this.
>
> My reasons are as follows
>
> 1. I don't think it is a good idea to mix multi-platform definition
-1 for metadata
+1 for file extensions or paths.
I don't think metadata or in-file conditional compilation is the right tool
for this.
My reasons are as follows
1. I don't think it is a good idea to mix multi-platform definitions in one
file. it gets complicated and confusing very quickly. You
As I remember, Rich Hickey solicited input on this matter in his Conj
'11 Keynote.
Maybe these and other proposals would fit into
http://dev.clojure.org/display/design/Cross-Dialect+Enhancements
kind regards
--
You received this message because you are subscribed to the Google
Groups "Clojure" g
>
> And even if it was, why shouldn't I be allowed to build my clojure
> projects with ant (like clojure itself) or maven?
>
Well, theoretically you could be able to do so, but yes, the problem is
more fundamental and probably should be solved on a language level rather
than one a tooling's one
Vinzent writes:
>> Such a feature shouldn't depend on a specific tool, it should be part
>> of the language.
>
> Yeah, you're right - I haven't thought about the fact that leiningen
> isn't available on the platforms other than jvm and js.
And even if it was, why shouldn't I be allowed to build
>
> Such a feature shouldn't depend on a specific tool, it should be part of
> the language.
Yeah, you're right - I haven't thought about the fact that leiningen isn't
available on the platforms other than jvm and js.
Given that reader macros are already used for this purpose extensively in
th
Vinzent writes:
>> I don't think that's too practical. The reader sees the metadata
>> only after it already started to read the form it should then ignore,
>> if the platform doesn't match.
>>
> As I understand it happens before compilation (lein plugin extracts
> the appropriate forms and then
>
> I don't think that's too practical. The reader sees the metadata only
> after it already started to read the form it should then ignore, if the
> platform doesn't match.
>
As I understand it happens before compilation (lein plugin extracts the
appropriate forms and then compiles it), so it
>
> What we need is even more defined then that, however, Consider this
> snippet from core.match:
>
> (ns clojure.core.match
> (:refer-clojure :exclude [compile])
> (:require [clojure.set :as set])
> (:import [java.io Writer]))
>
> how do we use metadata to restrict/include java.io.Writer v
Vinzent writes:
> First thing which comes to mind is to use metadata for this purpose.
> Something like
>
> (defn ^{:platform :jvm} to-string [x] ...)
I don't think that's too practical. The reader sees the metadata only
after it already started to read the form it should then ignore, if the
pl
>> First thing which comes to mind is to use metadata for this purpose.
>> Something like
>>
>> (defn ^{:platform :jvm} to-string [x] ...)
>
What we need is even more defined then that, however, Consider this
snippet from core.match:
(ns clojure.core.match
(:refer-clojure :exclude [compile])
>
> First thing which comes to mind is to use metadata for this purpose.
> Something like
>
> (defn ^{:platform :jvm} to-string [x] ...)
>
You might be interested in https://github.com/lynaghk/cljx , which already
does this sort of thing.
--
You received this message because you are subscrib
+1 for meta-data...it fits the glove perfectly ;-)
On 12/04/12 18:52, Vinzent wrote:
First thing which comes to mind is to use metadata for this purpose.
Something like
(defn ^{:platform :jvm} to-string [x] ...)
This doesn't force the user to create a separate file for each
platform (althou
First thing which comes to mind is to use metadata for this purpose.
Something like
(defn ^{:platform :jvm} to-string [x] ...)
This doesn't force the user to create a separate file for each platform
(although it's still possible to do so) and feels very naturally for
clojure.
Another option i
I've been thinking lately how to seamlessly merge clojure-py and
clojure-jvm code in the same packages. This is something I know has
been discussed in the past, but I'm just looking for
ideas/brainstorming on how we can solve this problem.
Let's begin by explaining the problem. Let's assume that m
27 matches
Mail list logo
