Re: Problem with installation of swank-clojure without elpa...
advice on `slime-read-interactive-arg' is used to add clojure to `slime-lisp-implementations', and set up classpath each time slime starts. This advice is not loaded by default. Other .emacs files use ELPA, which loads the advice for them. Without ELPA it's necessary to load the advice using `ad-activate' after (require 'swank-clojure) On Apr 6, 2:23 am, Preecha P yum...@gmail.com wrote: Tried that, not working. It gave me Wrong type argument: stringp, 126 error in mini buffer. I don't think that's the problem, most '.emacs I saw on internet doesn't use that. On Apr 5, 9:43 pm, ubolonton ubolon...@gmail.com wrote: Maybe you forgot this (ad-activate 'slime-read-interactive-args) -- 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: Set as function
On Tue, Apr 6, 2010 at 07:16, Alex Osborne a...@meshy.org wrote: Mark Engelberg mark.engelb...@gmail.com writes: filter works just as well with a function that returns true and false, so that's not a particularly good example. Calling the set as if it is a fn is a short-hand for get, that is retrieving an element from the set. Why would you want to do this, when to look it up you need to know what element is? Since you asked: canonicalization. I've wanted this on occasion (in Java) when canonicalizing (i.e. interning) values. The obvious alternative is to use a map where each such value maps to itself. This is no real bother. So, I'm happy that Clojure sets behave as they do. Being able to use a set as a predicate directly is very handy. // ben -- 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: Set as function
B Smith-Mannschott bsmith.o...@gmail.com writes: Calling the set as if it is a fn is a short-hand for get, that is retrieving an element from the set. Why would you want to do this, when to look it up you need to know what element is? Since you asked: canonicalization. I've wanted this on occasion (in Java) when canonicalizing (i.e. interning) values. Yep, that's exactly what I meant by interning. The obvious alternative is to use a map where each such value maps to itself. This is no real bother. So, I'm happy that Clojure sets behave as they do. Being able to use a set as a predicate directly is very handy. Indeed, under the hood Clojure's hash sets are in fact just a hash map which maps elements to themselves. -- 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
On 3 Apr 2010, at 10:40, Per Vognsen wrote: 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. Right. But then, frequencies and distances are *not* numbers. That's the whole point of dimensional analysis. If frequencies and distances were numbers, you could add a distance and a frequency. But even if you don't care about dimension checks in arithmetic, if distances were just numbers plus a metadata tag, the sum of two distances would just be a number. I don't see much use in such an overly lightweight dimension system. BTW, there's a unit library for Clojure that takes care of all that, but at the cost of using generic multimethods for arithmetic that add some overhead. For more details, have a look at this blog post: http://onclojure.com/2010/03/23/computing-with-units-and-dimensions/ Konrad. -- 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: defprotocol's support for variadic arguments seems broken
On Apr 6, 8:16 am, Zach Tellman ztell...@gmail.com wrote: Possibly this fall out from the latest commit requiring an explicit 'this' reference (ba6cc3b), I haven't checked any versions but the most recent. user (defprotocol Protocol (f [a b c])) Protocol user (def p (reify Protocol (f [a b c] [a b c]))) #'user/p user (f p :a :b :c) [#user$reify__1503 user$reify__1...@31e2ad :a :c] Did protocols ever support variadic arguments? It seems to me that in this case gets treated as a regular symbol and a gets bound to the object itself, b to :a, to :b and c to :c, which would explain the weird output. -- 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: Trying to set emacs for some clojure coding
Finally i did it. Installed with ELPA clojure-mode and swank-clojure. But slime couldn't find the swank-clojure.jar so I downloaded it and setted the classpath in .emacs to the directory where I stored it along with clojure.jar and clojure-contrib.jar the emacs line is: (setq swank-clojure-extra- classpaths (list /home/user/.clojure)) On Wed, Mar 31, 2010 at 6:29 PM, Stefan Kamphausen ska2...@googlemail.com wrote: Hi, On 31 Mrz., 13:52, Pelayo Ramón pela...@gmail.com wrote: just to add one more to the list... Note however, that this is what worked *for me* and it means going against the grain. So if there is anything wrong with that setup don't ask the authors of the fine software used, go and blame me ;-) Uh, and Clojure 1.1 only. With that being said, here goes. http://www.skamphausen.de/cgi-bin/ska/My_Clojure_Setup Btw: im using ubuntu 9.10 and emacs23 Same for me... Cheers, Stefan -- 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: Mutually-referencing structures
On Mon, Apr 5, 2010 at 4:54 PM, Douglas Philips d...@mac.com wrote:
Immutability is orthogonal to reference-ness.
There is nothing wrong with having immutable cyclic graphs of values.
There is something wrong with immutable cyclic data structures: an undefined
(or unexpected) behaviour on update because of identity and state being
conflated again.
Let say one can write:
(def john-doe {:name John Doe :email j...@doe.com :account {:owner
#cyclic reference to the root map :balance 1000}})
Then you want to add 10$ to John's account:
(update-in john-doe [:account :balance] + 10)
The resulting data structure is:
{:name John Doe :email j...@doe.com :account {:owner #cyclic reference
to the root map :balance 1010}}
but what would #cyclic reference to the root map point to? to the previous
value of john-doe! So if we expands the reference:
{:name John Doe :email j...@doe.com :account {:owner {:name John Doe
:email j...@doe.com :account {:owner #cyclic reference to the root map
:balance 1000}} :balance 1010}}
This is not exactly the expected result. The result is confusing because the
cyclic reference must be to the identity of the user account not to its
actual value.
The same problem arises even when you update a non-nested field:
(assoc john-doe :email john@corp.com)
The resulting value would be:
{:name John Doe :email john@corp.com :account {:owner {:name John
Doe :email j...@doe.com :account {:owner #cyclic reference to the root
map :balance 1000}} :balance 1000}}
You really need an indirection level to properly handle cyclic data
structures.
hth,
Christophe
--
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: Mutually-referencing structures
On Apr 6, 8:09 am, Christophe Grand christo...@cgrand.net wrote:
Let say one can write:
(def john-doe {:name John Doe :email j...@doe.com :account {:owner
#cyclic reference to the root map :balance 1000}})
At this point the cyclic structure is a consistent value. As long as
updates create new values that match the domain invariants, why should
any subsequent value cause a problem?
Then you want to add 10$ to John's account:
(update-in john-doe [:account :balance] + 10)
If that is what you update, then of course you will get ...
The resulting data structure is:
{:name John Doe :email j...@doe.com :account {:owner #cyclic reference
to the OLD root map :balance 1010}}
But how is this unique to cyclic structures? I can always mistakenly
create values and update them to end up with a structure that
incorrectly combines old and new values.
(def john-doe {zip-code: 12345 state: {name: CA}})
(update-in john-doe [:zip-code] + 5000)
;; new zip code, invalid old state
Maintaining domain invariants is the programmers responsibility,
whether or not there are cyclic references. Why wouldn't the same
facility that lets you create consistent mutual references in the
original John Doe value, also allow you to create consistent mutual
references in a consistent new (updated) John Doe value?
--
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: Mutually-referencing structures
On 2010 Apr 6, at 9:09 AM, Christophe Grand wrote:
On Mon, Apr 5, 2010 at 4:54 PM, Douglas Philips d...@mac.com wrote:
Immutability is orthogonal to reference-ness.
There is nothing wrong with having immutable cyclic graphs of
values.
There is something wrong with immutable cyclic data structures: an
undefined (or unexpected) behaviour on update because of identity
and state being conflated again.
... details elided ...
This is not exactly the expected result. The result is confusing
because the cyclic reference must be to the identity of the user
account not to its actual value.
(def john-doe {:name John Doe :email j...@doe.com})
(def account {:identity john-doe :balance 100} )
(assoc john-doe :email john.doe at gee mail.com)
Now the account contains old/obsolete data and no cycles are needed to
cause that.
Doesn't seem that cycles are the problem...
-Doug
--
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: Mutually-referencing structures
The question of the OP was also a practical one : is either Clojure
or functional not a good match?
Honestly, I don't know the answer for sure, because:
* there is still no (widely known ?) utilities to manipulate things
easily. There were attemps like the one by Jeffrey Streizhem in
clojure contrib, (dataset / datalog), but who's using it for real ?
* The STM is indeed easy to work with, by using the metaphore of the
database (and i think it is the right way of doing things. functions,
and macros to generate some of those functions can help managing the
necessary level of indirection).
* BUT : isn't the real problem that one will not content
[him/her]/self with playing with in-memory data ? One will want to
make the data persistent (outside-of-process, aka
storage-persistance). And with this kind of problem, one will have a
graph of identities containing references to other identities (the
needed level(s) of indirection). How does one painlessly store/unstore
those graphs to databases ?
Not to say: how does one totally reliably move data from the STM
to/from an RDBMS ? Currently, the trick is to send things to an
agent, but this does not provide all the required guarantees ...
So from the practical point of view, I'm not sure (alas) if clojure
has -yet- the expected YES! answer ...
2010/4/6 Douglas Philips d...@mac.com:
On 2010 Apr 6, at 9:09 AM, Christophe Grand wrote:
On Mon, Apr 5, 2010 at 4:54 PM, Douglas Philips d...@mac.com wrote:
Immutability is orthogonal to reference-ness.
There is nothing wrong with having immutable cyclic graphs of values.
There is something wrong with immutable cyclic data structures: an
undefined (or unexpected) behaviour on update because of identity and state
being conflated again.
... details elided ...
This is not exactly the expected result. The result is confusing because
the cyclic reference must be to the identity of the user account not to its
actual value.
(def john-doe {:name John Doe :email j...@doe.com})
(def account {:identity john-doe :balance 100} )
(assoc john-doe :email john.doe at gee mail.com)
Now the account contains old/obsolete data and no cycles are needed to cause
that.
Doesn't seem that cycles are the problem...
-Doug
--
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: Mutually-referencing structures
On Tue, Apr 6, 2010 at 3:41 PM, Sophie itsme...@hotmail.com wrote:
On Apr 6, 8:09 am, Christophe Grand christo...@cgrand.net wrote:
Let say one can write:
(def john-doe {:name John Doe :email j...@doe.com :account {:owner
#cyclic reference to the root map :balance 1000}})
At this point the cyclic structure is a consistent value.
True.
Then you want to add 10$ to John's account:
(update-in john-doe [:account :balance] + 10)
If that is what you update, then of course you will get ...
The resulting data structure is:
{:name John Doe :email j...@doe.com :account {:owner #cyclic
reference
to the OLD root map :balance 1010}}
But how is this unique to cyclic structures?
If your structures aren't cyclic the newly updated value can't accidentally
contain references to its previous self.
I can always mistakenly
create values and update them to end up with a structure that
incorrectly combines old and new values.
Sure.
Maintaining domain invariants is the programmers responsibility,
whether or not there are cyclic references. Why wouldn't the same
facility that lets you create consistent mutual references in the
original John Doe value, also allow you to create consistent mutual
references in a consistent new (updated) John Doe value?
What if you also want an history or a log in your data structure, pointing
to previous value? Then you wouldn't want these references to be updated by
the mechanism which create consistent mutual references. So you would put a
marker on it to say it is static.
At the end you have a complex system which walks the data-structure and
tracks all mutual references to update them all at once (except those which
are marked as static). This is nearly the description of the Clojure STM
except that with the STM you mark the references which need to be updated
all at once not those which don't.
--
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: Mutually-referencing structures
On Tue, Apr 6, 2010 at 3:43 PM, Douglas Philips d...@mac.com wrote:
(def john-doe {:name John Doe :email j...@doe.com})
(def account {:identity john-doe :balance 100} )
(assoc john-doe :email john.doe at gee mail.com)
Now the account contains old/obsolete data and no cycles are needed to
cause that.
Doesn't seem that cycles are the problem...
The cycles are gone but the identity john-doe aand its curren-state are
still conflated so you get the same problem:
(def account {:identity john-doe :balance 100} )
(assoc john-doe :email john.doe at gee mail.com)
On the first line you define a reference between the current value of
account and the current value of john-doe, so it is to be expected that
(assoc john-doe :email john.doe at gee mail.com) won't give the expected
result since you didn't provided the system with enough knowledge.
(def account {:identity #'john-doe :balance 100} )
(def john-doe (assoc john-doe :email john.doe at gee mail.com))
; or (alter-var-root #'john-doe assoc :email john.doe at gee mail.com)
there account points to the updated john-doe
Of course, one should not abuse vars, and the above code should at least be
rewritten with refs:
(def account (ref {:identity john-doe :balance 100}) )
(def john-doe (ref {:name John Doe :email j...@doe.com}))
(dosync (alter john-doe assoc :email john.doe at gee mail.com))
Really, to me the problem isn't creating cyclic data-structures but updating
them: the system must know which mutual references are to the identity (and
should be updated) and which are not. You have to give this information to
the system one way or the other, the system can't guess.
Btw, to some extent, one can create cyclic data-structures in Clojure (only
lazyseqs though -- unless you implement your own map or use lazy-map etc.) :
user= (defn cyclic-seq [coll] (let [s (promise)] @(deliver s (lazy-cat coll
@s
user= (let [s (cyclic-seq [1 2 3])] (identical? (seq s) (seq (drop 3 s
true
Christophe
--
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: Mutually-referencing structures
On Tue, Apr 6, 2010 at 9:59 PM, Christophe Grand christo...@cgrand.net wrote: Btw, to some extent, one can create cyclic data-structures in Clojure (only lazyseqs though -- unless you implement your own map or use lazy-map etc.) : user= (defn cyclic-seq [coll] (let [s (promise)] @(deliver s (lazy-cat coll @s user= (let [s (cyclic-seq [1 2 3])] (identical? (seq s) (seq (drop 3 s true I've already mentioned it a few times in passing, but my letrec macro uses promises and some simple-minded code walking to abstract away this kind of thing. The included example code is a pair of mutually cyclic lazy-seqs. http://gist.github.com/336461 -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.
Re: Mutually-referencing structures
On 2010 Apr 6, at 10:59 AM, Christophe Grand wrote: The cycles are gone but the identity john-doe aand its curren-state are still conflated so you get the same problem: Thus, since simple trees have the exact same issues, circularity is not the problem. Really, to me the problem isn't creating cyclic data-structures but updating them: the system must know which mutual references are to the identity (and should be updated) and which are not. You have to give this information to the system one way or the other, the system can't guess. To rephrase what you've said: the system must know which references are to the identity and which are not. Clojure already has that covered, but it won't do it for you behind your back. :) And this is not unique to circularity and it is not caused by circularity. There is an issue that you cannot create immutable mutual references, but that is a -separate- issue. Btw, to some extent, one can create cyclic data-structures in Clojure... I think Per was showing something similar. Please don't blame circularity for identity/value problems. ;) -Doug -- 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: Mutually-referencing structures
On Tue, Apr 6, 2010 at 10:43 PM, Douglas Philips d...@mac.com wrote: On 2010 Apr 6, at 10:59 AM, Christophe Grand wrote: The cycles are gone but the identity john-doe aand its curren-state are still conflated so you get the same problem: Thus, since simple trees have the exact same issues, circularity is not the problem. I agree. The deeper problem there is identity-value conflation rather than circularity. As for the general problem of manipulating immutable cyclic data structures, it admittedly requires techniques not usually taught even in advanced courses on functional programming. A good paper to read is Cycle Therapy: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.64.2027 -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.
let's all link to the getting started pages!
People getting started with Clojure have struggled to find an up-to- date source for information on getting their editor of choice up and running. This is unfortunate, since there is good support in a bunch of different editors. The Getting Started page on Assembla (http://www.assembla.com/wiki/show/clojure/Getting_Started ) should ameliorate this problem. A bunch of people have contributed or tested instructions for Netbeans/Enclojure, Eclipse/ Counterclockwise, IDEA/La Clojure, Emacs, Vim, and Leiningen. Now we just need to make this page more google-findable. If you have a blog/twitter/whatever-the-kids-use-these-days, please link out to the Assembla page, especially if you written up your own getting started instructions. Also, if you think the instructions suck please let me know how to make them better. Big thanks to everyone who wrote or tested the setup instructions, and to the unsung heroes who implemented the editor support modes. Thanks, Stu -- 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: Trying to set emacs for some clojure coding
2010/4/6 Pelayo Ramón pela...@gmail.com: Installed with ELPA clojure-mode and swank-clojure. But slime couldn't find the swank-clojure.jar so I downloaded it and setted the classpath in .emacs to the directory where I stored it along with clojure.jar and clojure-contrib.jar the emacs line is: (setq swank-clojure-extra- classpaths (list /home/user/.clojure)) If you have any idea or inkling why swank-clojure wasn't able to automatically download the jars please let me know; I'd like to get it fixed. -Phil -- 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: let's all link to the getting started pages!
Done ! * Replaced ccw install instructions with a link to Eclipse/Counterclockwise page ! * Added an Related projects link in the counterclockwise home page Thanks again Stuart for having done such a great work ! -- Laurent 2010/4/6 Stuart Halloway stuart.hallo...@gmail.com: People getting started with Clojure have struggled to find an up-to-date source for information on getting their editor of choice up and running. This is unfortunate, since there is good support in a bunch of different editors. The Getting Started page on Assembla (http://www.assembla.com/wiki/show/clojure/Getting_Started) should ameliorate this problem. A bunch of people have contributed or tested instructions for Netbeans/Enclojure, Eclipse/Counterclockwise, IDEA/La Clojure, Emacs, Vim, and Leiningen. Now we just need to make this page more google-findable. If you have a blog/twitter/whatever-the-kids-use-these-days, please link out to the Assembla page, especially if you written up your own getting started instructions. Also, if you think the instructions suck please let me know how to make them better. Big thanks to everyone who wrote or tested the setup instructions, and to the unsung heroes who implemented the editor support modes. Thanks, Stu -- 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: let's all link to the getting started pages!
On Tue, Apr 6, 2010 at 4:55 PM, Stuart Halloway stuart.hallo...@gmail.com wrote: People getting started with Clojure have struggled to find an up-to-date source for information on getting their editor of choice up and running. This is unfortunate, since there is good support in a bunch of different editors. The Getting Started page on Assembla (http://www.assembla.com/wiki/show/clojure/Getting_Started) should ameliorate this problem. A bunch of people have contributed or tested instructions for Netbeans/Enclojure, Eclipse/Counterclockwise, IDEA/La Clojure, Emacs, Vim, and Leiningen. Now we just need to make this page more google-findable. If you have a blog/twitter/whatever-the-kids-use-these-days, please link out to the Assembla page, especially if you written up your own getting started instructions. Google's top hit for clojure getting started is http://clojure.org/getting_started -- should that page be replaced or at least simplified and include a prominent link to the assembla page? --Chouser http://joyofclojure.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
Re: let's all link to the getting started pages!
Google's top hit for clojure getting started is http://clojure.org/getting_started -- should that page be replaced or at least simplified and include a prominent link to the assembla page? --Chouser http://joyofclojure.com/ Yes. The page is now somewhat simplified and has a link to the assembla page under the Editing section. -- 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: defprotocol's support for variadic arguments seems broken
You're right, that does explain it. I assumed that variadic arguments were supported, but maybe I was wrong. Can anyone confirm whether or not this was ever intended to work? On Apr 6, 2:32 am, Jarkko Oranen chous...@gmail.com wrote: On Apr 6, 8:16 am, Zach Tellman ztell...@gmail.com wrote: Possibly this fall out from the latest commit requiring an explicit 'this' reference (ba6cc3b), I haven't checked any versions but the most recent. user (defprotocol Protocol (f [a b c])) Protocol user (def p (reify Protocol (f [a b c] [a b c]))) #'user/p user (f p :a :b :c) [#user$reify__1503 user$reify__1...@31e2ad :a :c] Did protocols ever support variadic arguments? It seems to me that in this case gets treated as a regular symbol and a gets bound to the object itself, b to :a, to :b and c to :c, which would explain the weird output. -- 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 and emacs. again.
my bad. I didn't find swank-clojure on ELPA and tried to install it manually. now it works. thanks. On Apr 3, 6:20 am, Phil Hagelberg p...@hagelb.org wrote: On Fri, Apr 2, 2010 at 12:19 PM, jney jeansebastien@gmail.com wrote: I'm a newbie in clojure and inemacstoo. I got this message error while launching Slime : Debugger entered--Lisp error: (file-error Searching for program No such file or directory lisp) Slime is configured to use Common Lisp rather than Clojure. Otherwise, is there some recent documentation for install clojure environment onemacs. All documentation i found look outdated. Did you try the instructions in Swank Clojure's README? They should automatically configure things for Clojure: http://github.com/technomancy/swank-clojure -Phil -- 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: Problem with installation of swank-clojure without elpa...
Well, as I said in previous post, I got stringp error with advice on slime-read-interative-args. My guess is that there is something wrong in (aput 'slime-lisp-implementations 'clojure (list (swank-clojure-cmd) :init 'swank-clojure-init))) in swank- clojure.el I think I might try to look at it again later. Thanks for comment. On Apr 6, 1:13 pm, ubolonton ubolon...@gmail.com wrote: advice on `slime-read-interactive-arg' is used to add clojure to `slime-lisp-implementations', and set up classpath each time slime starts. This advice is not loaded by default. Other .emacs files use ELPA, which loads the advice for them. Without ELPA it's necessary to load the advice using `ad-activate' after (require 'swank-clojure) On Apr 6, 2:23 am, Preecha P yum...@gmail.com wrote: Tried that, not working. It gave me Wrong type argument: stringp, 126 error in mini buffer. I don't think that's the problem, most '.emacs I saw on internet doesn't use that. On Apr 5, 9:43 pm, ubolonton ubolon...@gmail.com wrote: Maybe you forgot this (ad-activate 'slime-read-interactive-args) -- 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.
A syntax question: positional keyword
Please don't misunderstand this post - it is not asking for a change of syntax, just trying to understand something. Clojure has chosen positional parameters (just like for Lisp, C, C++, Java, Ruby, Python, Prolog, ...) Smalltalk composes a full method name from a prefix-name + named parameters. [obj] prefix key1: x key2: y key3: z The [obj] part above is an artifact of the single-dispatch model, and is irrelevant to this discussion, so I'll leave it out from here on. Importantly, the method name here is a composite: #prefix:key1:key2:key3 This leads to remarkably readable function calls: 1. (schedule project: p1 after: p2 before: p3 priority: 7) ;; calls schedule:project:after:before:priority vs. 2. (schedule p1 p2 p3 7) Note that 1. in no way requires arbitrary ordering of keywords, maps, de-structuring, etc. The positions are still fixed, just keyword- prefixed. It's like taking the Clojure parameter list (defn schedule [project before after priority] ) and requiring those parameter names (or a formal version thereof which is meant to be part of the interface) at the calling sites. An only-slightly-strained analogy would be only allowing %1 %2 for formal parameters in all function bodies (defn schedule [%1 %2 %3] ( stuff with %1 %2 ...)) or (deftype Person [name age]) and then requiring (1 joe) instead of (:name joe) Just curious - what folks think of fixed-positional-keyword params - whether it was considered for Clojure Thanks! -- 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: Set as function
On Apr 6, 12:16 am, Alex Osborne a...@meshy.org wrote: Calling the set as if it is a fn is a short-hand for get, that is retrieving an element from the set. Why would you want to do this, when to look it up you need to know what element is? Sets are based on value-equality not reference-equality. Thus you can have an object in the set that is equal to your lookup key but not identical. Got it, thanks. -- 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: A syntax question: positional keyword
On Apr 7, 12:25 am, Sophie itsme...@hotmail.com wrote: Just curious - what folks think of fixed-positional-keyword params - whether it was considered for Clojure I don't know for certain whether Rich ever considered smalltalk-style parameters, but I doubt it. I do like them, though; in Objective-C and Smalltalk. They're extremely readable and natural in an object-oriented language (or a message-oriented one, anyway). However, I don't think they are a very good fit for a Lisp. Expressing positionally fixed keyword parameters in terns of lists, symbols and keywords feels clunky and unnatural to me, but the greater problem is that they also make some very common functional patterns cumbersome: most notably function application (ie. apply), composition, and higher-order functions. -- 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: let's all link to the getting started pages!
Can we scavenge or link to the stuff in wikibooks: http://en.wikibooks.org/wiki/Clojure_Programming/Getting_Started In particular, getting started simply by installing clojure onto the system (irrespective of the various dev environment configs). Being able to have co-workers simply run sudo port install clojure +rlwrap and then have clj available as a command has been very handy in getting them to play with the language. On Apr 6, 8:55 am, Stuart Halloway stuart.hallo...@gmail.com wrote: People getting started with Clojure have struggled to find an up-to- date source for information on getting their editor of choice up and running. This is unfortunate, since there is good support in a bunch of different editors. The Getting Started page on Assembla (http://www.assembla.com/wiki/show/clojure/Getting_Started ) should ameliorate this problem. A bunch of people have contributed or tested instructions for Netbeans/Enclojure, Eclipse/ Counterclockwise, IDEA/La Clojure, Emacs, Vim, and Leiningen. Now we just need to make this page more google-findable. If you have a blog/twitter/whatever-the-kids-use-these-days, please link out to the Assembla page, especially if you written up your own getting started instructions. Also, if you think the instructions suck please let me know how to make them better. Big thanks to everyone who wrote or tested the setup instructions, and to the unsung heroes who implemented the editor support modes. Thanks, Stu -- 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: A syntax question: positional keyword
Have you seen destructuring of rest args in the current master branch?
(defn foo [ {:keys [a b c]}] [a b c])
(foo :a 1 :c 3)
= [1 nil 3]
With this last bit of sugar in place I am extremely happy with
Clojure's arg handling.
Please don't misunderstand this post - it is not asking for a change
of syntax, just trying to understand something.
Clojure has chosen positional parameters (just like for Lisp, C, C++,
Java, Ruby, Python, Prolog, ...)
Smalltalk composes a full method name from a prefix-name + named
parameters.
[obj] prefix key1: x key2: y key3: z
The [obj] part above is an artifact of the single-dispatch model, and
is irrelevant to this discussion, so I'll leave it out from here on.
Importantly, the method name here is a composite:
#prefix:key1:key2:key3
This leads to remarkably readable function calls:
1. (schedule project: p1 after: p2 before: p3 priority: 7)
;; calls schedule:project:after:before:priority
vs.
2. (schedule p1 p2 p3 7)
Note that 1. in no way requires arbitrary ordering of keywords, maps,
de-structuring, etc. The positions are still fixed, just keyword-
prefixed. It's like taking the Clojure parameter list
(defn schedule
[project before after priority] )
and requiring those parameter names (or a formal version thereof which
is meant to be part of the interface) at the calling sites.
An only-slightly-strained analogy would be only allowing %1 %2 for
formal parameters in all function bodies
(defn schedule [%1 %2 %3]
( stuff with %1 %2 ...))
or
(deftype Person [name age])
and then requiring
(1 joe) instead of (:name joe)
Just curious
- what folks think of fixed-positional-keyword params
- whether it was considered for Clojure
Thanks!
--
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: A syntax question: positional keyword
On Apr 6, 4:46 pm, Jarkko Oranen chous...@gmail.com wrote: problem is that they also make some very common functional patterns cumbersome: most notably function application (ie. apply), composition, and higher-order functions. I don't think it should be either-or (and positional would be needed anyway to call out to Java friends). So your functional patterns could still be done positionally, since the first-class function arguments f g are not named anyway: (let [f ..., g ..., x ...] (apply f g x) (comp f g)) The arg-lists in the defn would distinguish ;; positional-keyword calls needed ;; function name is a composite ;; one defn could create more than one function name (defn schedule [project: p before: b after: a priority: i] ...) from ;; existing defn calling code could even be unchanged ;; no keywords (defn apply (f args* argseq) ...) -- 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: A syntax question: positional keyword
On Apr 6, 5:23 pm, Stuart Halloway stuart.hallo...@gmail.com wrote:
Have you seen destructuring of rest args in the current master branch?
(defn foo [ {:keys [a b c]}] [a b c])
(foo :a 1 :c 3)
= [1 nil 3]
With this last bit of sugar in place I am extremely happy with
Clojure's arg handling.
Hmmm. Looks nice, but if these are optional, any-order keys
- is there a run-time cost to construct / deconstruct / lookup?
- how do I use foo in apply, comp, and friends?
Thanks!
--
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: A syntax question: positional keyword
Don't you think
- fixed-order named parameters
could (should?) be a separate issue from
- optional, any-order, named parameters
?
;; :x :y are fixed order, named, while :a :b are optional, named
(defn foo [:x :y {:keys [a b]] [x, y, a, b])
(foo :x 1 :y 2)
= [1 2 nil nil]
(foo :x 1 :a 2)
= error
(foo :x 1 :a 3 :y 2)
= error
(foo :x 1 :y 2 :b 3)
= [1 2 nil 3]
Note that
(defn foo
([:x {:keys [y]] [x nil])
([:x :y][x y]))
would create 2 function symbols e.g. foo:x and foo:x:y
--
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: Mutually-referencing structures
On Apr 6, 2010, at 9:01 AM, Laurent PETIT wrote: * BUT : isn't the real problem that one will not content [him/her]/self with playing with in-memory data ? One will want to make the data persistent (outside-of-process, aka storage-persistance). And with this kind of problem, one will have a graph of identities containing references to other identities (the needed level(s) of indirection). How does one painlessly store/unstore those graphs to databases ? XML with ID/IDREFs seems the obvious choice. -- 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: A syntax question: positional keyword
On Apr 6, 2010, at 6:08 PM, Sophie wrote: Don't you think - fixed-order named parameters could (should?) be a separate issue from - optional, any-order, named parameters ? I don't see the advantage of fixed-order named parameters over keyword parameters. Note that you can require certain keyword parameters simply by throwing an exception when they're omitted. -- 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: A syntax question: positional keyword
See: http://richhickey.github.com/clojure-contrib/def-api.html#clojure.contrib.def/defnk On Apr 6, 2:25 pm, Sophie itsme...@hotmail.com wrote: Please don't misunderstand this post - it is not asking for a change of syntax, just trying to understand something. Clojure has chosen positional parameters (just like for Lisp, C, C++, Java, Ruby, Python, Prolog, ...) Smalltalk composes a full method name from a prefix-name + named parameters. [obj] prefix key1: x key2: y key3: z The [obj] part above is an artifact of the single-dispatch model, and is irrelevant to this discussion, so I'll leave it out from here on. Importantly, the method name here is a composite: #prefix:key1:key2:key3 This leads to remarkably readable function calls: 1. (schedule project: p1 after: p2 before: p3 priority: 7) ;; calls schedule:project:after:before:priority vs. 2. (schedule p1 p2 p3 7) Note that 1. in no way requires arbitrary ordering of keywords, maps, de-structuring, etc. The positions are still fixed, just keyword- prefixed. It's like taking the Clojure parameter list (defn schedule [project before after priority] ) and requiring those parameter names (or a formal version thereof which is meant to be part of the interface) at the calling sites. An only-slightly-strained analogy would be only allowing %1 %2 for formal parameters in all function bodies (defn schedule [%1 %2 %3] ( stuff with %1 %2 ...)) or (deftype Person [name age]) and then requiring (1 joe) instead of (:name joe) Just curious - what folks think of fixed-positional-keyword params - whether it was considered for Clojure Thanks! -- 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: let's all link to the getting started pages!
will do! = angol = -|-^...@^_^, =|+^_^X++~_~,@- The only thing worse than a hopeless romantic is a hopeful one Magbasa bago Mamuna. Mag-isip bago mambatikos Without Truth there is no Justice, Without Justice, there is Tyranny Semper fi Proof of Desire is Pursuit www.onthe8spot.com http://www.facebook.com/giancarlo.angulo http://twitter.com/Neoryder On Tue, Apr 6, 2010 at 11:55 PM, Stuart Halloway stuart.hallo...@gmail.comwrote: People getting started with Clojure have struggled to find an up-to-date source for information on getting their editor of choice up and running. This is unfortunate, since there is good support in a bunch of different editors. The Getting Started page on Assembla ( http://www.assembla.com/wiki/show/clojure/Getting_Started) should ameliorate this problem. A bunch of people have contributed or tested instructions for Netbeans/Enclojure, Eclipse/Counterclockwise, IDEA/La Clojure, Emacs, Vim, and Leiningen. Now we just need to make this page more google-findable. If you have a blog/twitter/whatever-the-kids-use-these-days, please link out to the Assembla page, especially if you written up your own getting started instructions. Also, if you think the instructions suck please let me know how to make them better. Big thanks to everyone who wrote or tested the setup instructions, and to the unsung heroes who implemented the editor support modes. Thanks, Stu -- 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.comclojure%2bunsubscr...@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: Mutually-referencing structures
I would really love to see (clearly by someone much smarter than I :) an insightful summary of these kinds of concept-heavy discussions, stickied or FAQd or even book'd somewhere. -- 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: A syntax question: positional keyword
On Apr 6, 7:03 pm, ataggart alex.tagg...@gmail.com wrote: See: http://richhickey.github.com/clojure-contrib/def-api.html#clojure.con... Ah, thank you (all). Will this be in 1.2? Is run-time cost expected to be minor, and will passing unrecognized keys be an error? -- 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: (newbie) How to access a Java class's field?
Gregg Williams greg...@innerpaths.net writes: I'm currently stuck on how to translate aNode.setPaint(Color.RED); The interop syntax is described here: http://clojure.org/java_interop Color.RED is a static field, so we use the Classname/staticField syntax, so Color/RED. Combining that with (.instanceMember instance ...) for aNode.setPaint(...) gives us: (.setPaint aNode Color/RED) -- 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.
