Unfortunately you can only attach metadata to types that implement the
IObj interface. That excludes native Java types like Integer and
Float:
user=> (with-meta 42 {:foo 42})
java.lang.ClassCastException: java.lang.Integer (NO_SOURCE_FILE:0)
user=> (with-meta 42.0 {:foo 42})
java.lang.ClassCastExc
By the way, I wanted to emphasize that I don't think this would be an
ideal use of metadata even if your use case was supported. But the
reason metadata is so tempting is that you want frequencies and
distances to be treatable as numbers and so on. If you wrap them up
like I suggested, you couldn't
Hi,
On 01.04.2010, at 20:00, Stuart Halloway wrote:
> (2) When I import the project, the package explorer shows JRE System Library
> J2SE 1.4. The Clojure REPL then bombs needing Java 1.5 features. I can edit
> the project properties after the import, but shouldn't there be some way to
> say t
One approach to consider is using clojure.contrib.types, which
provides general and abstract data types. If you're familiar with
pattern matching from Scala, you'll feel right at home.
On Apr 2, 6:47 pm, strattonbrazil wrote:
> What's the best way to keep track of what kind of value something is
FYI, I've implemented most of the corrections suggested on this
thread. I kept the many defs- I thought at first I'd rewrite this part
of the code to use atoms instead, but then I realized that's also a
suboptimal solution and would already require me to write in a bunch
of Clojure-specific exposit
Lazy data flow via sequences is a superior substitute for imperative
control flow. But sometimes unrestrained control flow is convenient.
Here's a proof of concept that provides statically scoped first-class
labels with dynamic extent:
http://gist.github.com/354676
The lexically scoped atom trick
Hi All,
I'm sold on the virtues of immutable data, but the notion of
"persistent in-memory data structures" sounds kind of like a euphemism
for a garbage collection leak.
Could someone point me to a reference explaining how persistent
transactional memory works in the context of garbage collectio
The two issues are orthogonal.
Even if Clojure had been going for full copies to preserve
immutability, the reason why the "old" copy would leak is only because
your code would hold a reference to it.
With structural sharing, those bits of "old" that are still retained
in "new" are precisely thos
They are not completely orthogonal. In fact they work well together.
One of the core assumptions in generational garbage collection is that
data in higher generations rarely grow pointers to data in lower
generations. This is often true in imperative programs. But absent
implicit mutation in the f
You talk of transactions, "persistent in-memory" and garbage
collection. Are you sure you understand what persistence means here?
It's a matter of efficient structural sharing of data structures
rather than persistence in the database sense.
-Per
On Sat, Apr 3, 2010 at 9:13 PM, David R. Smith wr
I wonder what is the current state of Clojure @ Android?
Is 1.1 running without modifications?
If someone is running it, could you share your build.xml and/or any tips?
Thank you,
Boris
On Tue, Mar 23, 2010 at 4:24 PM, Alex Coventry wrote:
> My impression from reading Remco van 't Veer's posts
11 matches
Mail list logo
