Re: holding types or units in metadata vs pattern matching
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.ClassCastException: java.lang.Double (NO_SOURCE_FILE:0)
user=> (with-meta (float 42.0) {:foo 42})
java.lang.ClassCastException: java.lang.Float (NO_SOURCE_FILE:0)
I haven't thought through all the implications, but it seems like
Clojure could support externalized metadata for these sort of types
with an identity-based weak-key hash table.
Anyway, the way things stand, your best kept is probably to wrap your
data in some data structure. It could be as simple as [:frequency x]
or {:tag :frequency, :value x}.
-Per
On Sat, Apr 3, 2010 at 5:47 AM, strattonbrazil wrote:
> What's the best way to keep track of what kind of value something is?
> For example, if I have a hash of floats and I want to go through each
> one and see if a given key-value, which happens to be a float, if it's
> a distance or a frequency? Or if something is a struct or a specific
> struct? I'm somewhat familiar with the pattern matching done in Scala
> and couldn't find similar documentation in Clojure.
>
> I would think there's some way to filter out values that are a certain
> struct, but I'd also like to attach information to primitives like
> floats. Should I wrap my primitives in structs or do I need
> metadata?
>
> --
> 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
>
> To unsubscribe, reply using "remove me" as the subject.
>
--
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
Re: holding types or units in metadata vs pattern matching
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 pass them directly to core arithmetic
functions like + and * but would need to perform manual wrapping and
unwrapping.
The analogous case in Haskell is newtypes. Newtypes are used when you
want an isomorphic but nevertheless non-equal version of an existing
data type. So in your example you might have a Frequency and Distance
newtype. Generally you want most of the implemented interfaces (type
classes) to be inherited from the underlying types without having to
implement them by manually unwrapping the operands, forwarding them,
and rewrapping of the results. This is done by newtype deriving. If
you write newtype Frequency = Frequency Integer deriving (Show, Eq,
Ord, Num), you will inherit the behavior for displaying an integer as
a string, equality checking, linear ordering, and integral arithmetic
operations. But you could also leave the Show out and implement it
yourself, probably deferring to the wrapped type's Show instance as
part of your implementation.
I think you could achieve something similar with protocols. There
would be a (defnewtype frequency Protocol1 Protocol2 ... ProtocolN),
which would implement the named protocols for each Frequency instance
by deferring to the wrapped value. This wouldn't be possible for all
protocols but only those with implemented newtype derivers. For
example, the newtype deriver for the arithmetic protocol's addition
function might unwrap the operands, call addition on these now
unwrapped values, and then rewrap the results in the newtype wrapper.
(Clojure's arithmetic tower isn't expressible via protocol-style
single dispatch, so this is vastly simplified, but you get the idea.)
-Per
On Sat, Apr 3, 2010 at 3:18 PM, Per Vognsen wrote:
> 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.ClassCastException: java.lang.Double (NO_SOURCE_FILE:0)
> user=> (with-meta (float 42.0) {:foo 42})
> java.lang.ClassCastException: java.lang.Float (NO_SOURCE_FILE:0)
>
> I haven't thought through all the implications, but it seems like
> Clojure could support externalized metadata for these sort of types
> with an identity-based weak-key hash table.
>
> Anyway, the way things stand, your best kept is probably to wrap your
> data in some data structure. It could be as simple as [:frequency x]
> or {:tag :frequency, :value x}.
>
> -Per
>
> On Sat, Apr 3, 2010 at 5:47 AM, strattonbrazil
> wrote:
>> What's the best way to keep track of what kind of value something is?
>> For example, if I have a hash of floats and I want to go through each
>> one and see if a given key-value, which happens to be a float, if it's
>> a distance or a frequency? Or if something is a struct or a specific
>> struct? I'm somewhat familiar with the pattern matching done in Scala
>> and couldn't find similar documentation in Clojure.
>>
>> I would think there's some way to filter out values that are a certain
>> struct, but I'd also like to attach information to primitives like
>> floats. Should I wrap my primitives in structs or do I need
>> metadata?
>>
>> --
>> 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
>>
>> To unsubscribe, reply using "remove me" as the subject.
>>
>
--
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
Re: eclipse/counterclockwise/maven question
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 this in pom.xml so that Eclipse choose 1.5 during the import? AFAIR, 1.4 is the default for Maven's javac-plugin. If you add the snippet described in http://maven.apache.org/general.html#Compiling-J2SE-5 to the pom.xml, the specified version will be used; Eclipse (via m2eclipse or "mvn eclipse:eclipse") picks this up correctly. Regards, --Chris -- 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 To unsubscribe, reply using "remove me" as the subject.
Re: holding types or units in metadata vs pattern matching
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? > For example, if I have a hash of floats and I want to go through each > one and see if a given key-value, which happens to be a float, if it's > a distance or a frequency? Or if something is a struct or a specific > struct? I'm somewhat familiar with the pattern matching done in Scala > and couldn't find similar documentation in Clojure. > > I would think there's some way to filter out values that are a certain > struct, but I'd also like to attach information to primitives like > floats. Should I wrap my primitives in structs or do I need > metadata? -- 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 To unsubscribe, reply using "remove me" as the subject.
Re: Clojure Added to "Casting SPELs" Site
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 exposition, which is beyond the intent of this tutorial. Using defs, and changing the values of these global variables by re-deffing is definitely ugly, but it also is very simple. As I mentioned, I hope I can create a proper Clojure tutorial sometime in the future with cleaner Clojure code. On Apr 1, 11:43 am, Daniel Werner wrote: > Hi Conrad, > > thanks for putting this tutorial up. "CastingSPELs" was actually one > of the documents that inspired me to start learning Lisp, so I'm happy > to see it may help others get started with Clojure. > > Adding to the corrections: The Addendum (page 8) seems to have > remained CL-centric (defparameter, dotted lists, cons cells). It also > mentions "esoteric commands" neccessary for text processing, which is > clearly not the case with Clojure's c.c.str-utils / c.c.string. > > On Apr 1, 2:38 am, Conrad wrote: > > > in the tooth (There's a new one in my upcoming book for Common Lisp > >http://nostarch.com/lisp.htmthat's more up to date, but it's pretty > > Is there any chance you're going to release this book for Clojure in > the future? :-) > > -- > Daniel -- 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 To unsubscribe, reply using "remove me" as the subject.
Statically scoped first-class labels with dynamic extent
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 was inspired by E's implementation of revocable capabilities. IMO, revocable capabilities is one of the most convincing demonstrations of the cross-cutting power of stateful side effects. Of course, that is also what makes them so dangerous. -Per -- 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 To unsubscribe, reply using "remove me" as the subject.
STM and Garbage Collection
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 collection? Are there special issues related to garbage collection I need to be concerned with when using Seqs? Sincerely, Dave Smith -- 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 To unsubscribe, reply using "remove me" as the subject.
Re: STM and Garbage Collection
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 those bits that weren't modified between the two versions, and certainly have to stay in memory, because they belong in "new" too. As for the bits of "old" that point to this shared part, if nothing *else* points to them, then there's no reason for them not to be GC'd apart from the references that *your* code might hold on them. On Apr 3, 3:13 pm, "David R. Smith" wrote: > 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 collection? Are > there special issues related to garbage collection I need to be > concerned with when using Seqs? > > Sincerely, > > Dave Smith -- 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 To unsubscribe, reply using "remove me" as the subject.
Re: STM and Garbage Collection
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 form of laziness, it's _always_ true in functional programs. If your purely functional language is strict, you can engineer your GC algorithm to take advantage of it as Joe Armstrong did for Erlang: One pass real-time generational mark-sweep garbage collection: http://citeseer.ist.psu.edu/armstrong95one.html Clojure isn't purely functional but it is sufficiently pure to play along well with standard generational schemes. As persistent data structures go, it's possible to have a data structure that is physically constituted from pieces in generation 0 and pieces in generation N without triggering the card-marking write barrier and forcing the generation 0 pieces to be hoisted into generation N. -Per On Sun, Apr 4, 2010 at 7:53 AM, verec wrote: > 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 those bits that weren't modified between the > two versions, and certainly have to stay in memory, because they > belong in "new" too. As for the bits of "old" that point to this > shared part, if nothing *else* points to them, then there's no reason > for them not to be GC'd apart from the references that *your* code > might hold on them. > > On Apr 3, 3:13 pm, "David R. Smith" wrote: >> 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 collection? Are >> there special issues related to garbage collection I need to be >> concerned with when using Seqs? >> >> Sincerely, >> >> Dave Smith > > -- > 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 > > To unsubscribe, reply using "remove me" as the subject. > -- 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
Re: STM and Garbage Collection
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 wrote: > 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 collection? Are > there special issues related to garbage collection I need to be > concerned with when using Seqs? > > Sincerely, > > Dave Smith > > -- > 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 > > To unsubscribe, reply using "remove me" as the subject. > -- 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
Re: Would it be possible to make a "dumped" clojure, a la dumped emacs?
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 about his > experience running clojure on Android is that it tends to be slow in > general because introspection is expensive in Dalvik. So while you > can sprinkle typehints throughout your own code, you really don't want > to do that to the core, and hence startup remains expensive. I could > easily be wrong about that, though. > > On Mar 23, 4:11 pm, Michael Kohl wrote: >> I thought there are some issues re the Dalvik VM and Clojure? Does >> anyone have experience with this? > > -- > 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 > > To unsubscribe from this group, send email to > clojure+unsubscribegooglegroups.com or reply to this email with the words > "REMOVE ME" as the subject. > -- 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
