Clojure on Wikipedia
Hi, No doubt many individuals interested in Clojure are aware of its Wikipedia entry, though I just now found it. It's a pretty terse page, including only a single paragraph of actual content (its history page is longer...) and could probably stand some elaboration. E.g., Clojure's STM and other concurrent programming support features are not mentioned at all. Perhaps someone with enough depth of understanding could flesh out this entry? Randall Schulz --~--~-~--~~~---~--~~ 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 To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
RE: vs. Erlang
http://lambda-the-ultimate.org/node/2865#comment-42428 maybe an approach which would be a not-very-big-diff-to-Clojure to get distributed computing. --~--~-~--~~~---~--~~ 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 To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Clojure Poll 09/2008
On Tue, Sep 16, 2008 at 7:13 PM, Allen Rohner <[EMAIL PROTECTED]> wrote: > > There is one weakness with the comment macro; the Reader has to be > happy with the body of the comment. Including things like # in the > comment body can upset the reader and cause your file to not compile. Yeah, that counts. Thanks! - J. --~--~-~--~~~---~--~~ 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 To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Clojure Poll 09/2008
> > 2) Balanced-boundary (non-EOL-terminated) comments. Whether the syntax > > is #| ... |# (á là Common Lisp) or /* ... */ (C- and Java-like) or > > something else, I don't much care, but I think both line-terminated and > > balanced comments are called for. Likewise, whether balanced-boundary > > comments nest or not is not a key concern of mine, though it might be > > nice if they did, for a change. > > Are you aware of the (comment ...) macro? Is there any benefit to balanced > comments that the macro doesn't provide? There is one weakness with the comment macro; the Reader has to be happy with the body of the comment. Including things like # in the comment body can upset the reader and cause your file to not compile. Allen --~--~-~--~~~---~--~~ 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 To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Clojure Poll 09/2008
On Tue, Sep 16, 2008 at 4:45 PM, Randall R Schulz <[EMAIL PROTECTED]> wrote: > I'd like to add: > > 2) Balanced-boundary (non-EOL-terminated) comments. Whether the syntax > is #| ... |# (á là Common Lisp) or /* ... */ (C- and Java-like) or > something else, I don't much care, but I think both line-terminated and > balanced comments are called for. Likewise, whether balanced-boundary > comments nest or not is not a key concern of mine, though it might be > nice if they did, for a change. Are you aware of the (comment ...) macro? Is there any benefit to balanced comments that the macro doesn't provide? - J. --~--~-~--~~~---~--~~ 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 To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Generate exposers for ancestral fields
On Sep 16, 2008, at 1:06 PM, Rich Hickey wrote:
>
>
>
> On Sep 16, 11:12 am, Matt Revelle <[EMAIL PROTECTED]> wrote:
>> Rich,
>>
>> Should I send in a CA and add ancestry verification and error
>> handling
>> or is this an unacceptable change?
>>
>
> I'm amenable to the idea, but I haven't looked at the specifics,
> holding off on changes pre-release. Please do send in a CA if you
> intend to submit patches. I wonder why specifying the ancestor class
> should be necessary, isn't it just a matter of finding the field in
> the hierarchy?
>
> Thanks,
>
> Rich
>
Specifying the ancestor class isn't necessary, I was unsure if
searching the class hierarchy would be appropriate when defining a
class. After thinking about it more, seems fine. I'll go ahead and
send in a CA and submit a new patch.
-Matt
>>
>> On Sep 15, 12:22 am, Matt Revelle <[EMAIL PROTECTED]> wrote:
>>
>>> I modifed clojure/genclass to support adding exposer methods for
>>> protected fields in classes higher up the hierarchy than the
>>> superclass. Interfaces should also be supported too.
>>
>>> The patch can be found
>>> here:http://clojure.googlegroups.com/web/genclass_exposers.diff
>>
>>> An example with the new syntax:
>>
>>> (gen-and-load-class 'motive.visual.TestSimpleGame
>>> :extends com.jme.app.SimpleGame
>>> :exposes '{[com.jme.app.BaseSimpleGame rootNode]
>>> {:get getRootNode :set setRootNode}})
>>
>>> The original exposes format is supported too, which defaults to the
>>> superclass. There's currently no check done to verify that the
>>> class/
>>> interface specified as the home of the field is a part of the
>>> hierarchy of the new class. I'll likely add that and clean things
>>> up
>>> a bit after I get some sleep and feedback.
>>
>>> -Matt
> >
--~--~-~--~~~---~--~~
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
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
porting Practical Common Lisp examples to Clojure
Hi all, I am porting [1] the Practical Common Lisp examples [2] to Clojure, and blogging notes [3] as I go. Feedback of all kinds is most welcome, and I hope that some folks here will find this useful. Cheers, Stuart [1] http://github.com/stuarthalloway/practical-cl-clojure [2] http://gigamonkeys.com/book/ [3] http://blog.thinkrelevance.com/2008/9/16/pcl-clojure --~--~-~--~~~---~--~~ 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 To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Clojure Poll 09/2008
On Wednesday 10 September 2008 13:39, Randall R Schulz wrote: > On Wednesday 10 September 2008 11:40, Rich Hickey wrote: > > As we rapidly approach 500 members on the group (!) I thought it > > would be a good time to conduct another poll: > > > > > > What are you doing with Clojure? > > Tinkering. Contemplating an extensibility mechanism for my theorem > prover. > > > What 3 features would you most like to see added next? > > The only thing that would really help unblock me is: > > 1) Programmable reader macros á là Common Lisp. I'd like to add: 2) Balanced-boundary (non-EOL-terminated) comments. Whether the syntax is #| ... |# (á là Common Lisp) or /* ... */ (C- and Java-like) or something else, I don't much care, but I think both line-terminated and balanced comments are called for. Likewise, whether balanced-boundary comments nest or not is not a key concern of mine, though it might be nice if they did, for a change. Randall Schulz --~--~-~--~~~---~--~~ 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 To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Clojure Poll 09/2008
On Tue, Sep 16, 2008 at 4:49 AM, Alexander Kjeldaas <[EMAIL PROTECTED]> wrote: > > 2. Clojure states that it has good support for list comprehensions. > Maybe I'm misunderstanding list comprehensions, but I'm not completely > happy. I want a way to have destructuring work on the sequence, not > on the individual element. In CL you have (loop for i in '(1 2 3) ...) > as well as (loop for i on '(1 2 3) ...). How is the one-liner to > create a lazy sliding window over a sequence in Clojure? There are many functions that operate on sequences which are not built into Clojure's "for" macro. Perhaps you want partition: user=> (partition 3 1 (range 5)) ((0 1 2) (1 2 3) (2 3 4)) This could then be destructured with for if you want: user=> (for [[a b c] (partition 3 1 (range 5))] (- c a)) (2 2 2) > 3. The Clojure coding style sets a bad precedent wrt commenting. > Using Clojure professionally means you need comments. The > (comment ...) form, although theoretically elegant just doesn't look > good. There is not a single comment in boot.clj. Is this a > coincidence? Besides (comment ...) there is also ; and documentation strings stored as meta-data attached to function vars. boot.clj has all but the first of these. --Chouser --~--~-~--~~~---~--~~ 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 To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: A question about ns-resolve
On Sep 16, 7:41 am, Rich Hickey <[EMAIL PROTECTED]> wrote: > On Sep 16, 12:26 am, Feng <[EMAIL PROTECTED]> wrote: > > > Hi, > > > It appears that ns-resolve only resolves alias qualified symbol in > > current clojure/*ns*, but not in the namespace passed as argument. > > Fixed - thanks for the report. > > > I tried to make some change in Compiler.java > > Please send in a CA before submitting any patches - thanks. > I'll do that when I'm capable to contribute patches formally. thanks for the fix. - Feng > Rich --~--~-~--~~~---~--~~ 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 To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Generate exposers for ancestral fields
On Sep 16, 11:12 am, Matt Revelle <[EMAIL PROTECTED]> wrote:
> Rich,
>
> Should I send in a CA and add ancestry verification and error handling
> or is this an unacceptable change?
>
I'm amenable to the idea, but I haven't looked at the specifics,
holding off on changes pre-release. Please do send in a CA if you
intend to submit patches. I wonder why specifying the ancestor class
should be necessary, isn't it just a matter of finding the field in
the hierarchy?
Thanks,
Rich
>
> On Sep 15, 12:22 am, Matt Revelle <[EMAIL PROTECTED]> wrote:
>
> > I modifed clojure/genclass to support adding exposer methods for
> > protected fields in classes higher up the hierarchy than the
> > superclass. Interfaces should also be supported too.
>
> > The patch can be found
> > here:http://clojure.googlegroups.com/web/genclass_exposers.diff
>
> > An example with the new syntax:
>
> > (gen-and-load-class 'motive.visual.TestSimpleGame
> > :extends com.jme.app.SimpleGame
> > :exposes '{[com.jme.app.BaseSimpleGame rootNode]
> > {:get getRootNode :set setRootNode}})
>
> > The original exposes format is supported too, which defaults to the
> > superclass. There's currently no check done to verify that the class/
> > interface specified as the home of the field is a part of the
> > hierarchy of the new class. I'll likely add that and clean things up
> > a bit after I get some sleep and feedback.
>
> > -Matt
--~--~-~--~~~---~--~~
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
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
Re: Generate exposers for ancestral fields
Rich,
Should I send in a CA and add ancestry verification and error handling
or is this an unacceptable change?
-Matt
On Sep 15, 12:22 am, Matt Revelle <[EMAIL PROTECTED]> wrote:
> I modifed clojure/genclass to support adding exposer methods for
> protected fields in classes higher up the hierarchy than the
> superclass. Interfaces should also be supported too.
>
> The patch can be found
> here:http://clojure.googlegroups.com/web/genclass_exposers.diff
>
> An example with the new syntax:
>
> (gen-and-load-class 'motive.visual.TestSimpleGame
> :extends com.jme.app.SimpleGame
> :exposes '{[com.jme.app.BaseSimpleGame rootNode]
> {:get getRootNode :set setRootNode}})
>
> The original exposes format is supported too, which defaults to the
> superclass. There's currently no check done to verify that the class/
> interface specified as the home of the field is a part of the
> hierarchy of the new class. I'll likely add that and clean things up
> a bit after I get some sleep and feedback.
>
> -Matt
--~--~-~--~~~---~--~~
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
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
Re: 20080916 Release
On Sep 16, 10:15 am, Randall R Schulz <[EMAIL PROTECTED]> wrote: > On Tuesday 16 September 2008 07:00, Rich Hickey wrote: > > >http://sourceforge.net/project/showfiles.php?group_id=137961 > > > Added: validators for vars/refs/agents, delay/force, isa-based > > multimethods and a la carte hierarchies, require/use/load, namespace > > aliases and many more functions and fixes. > > Wow. I thought I was following everything that transpired here, but much > of that seems out of the blue to me. > > Has the documentation been updated to reflect these additions and > changes? > Some of the enhancements were discussed here: http://groups.google.com/group/clojure/msg/64e14b845a5e8905 http://groups.google.com/group/clojure/browse_frm/thread/bf552753ea0b6e20/f053d73f83e5b3d4 The API page has been updated. I'll be providing some more prose docs for multimethods and lib, and correcting older docs and examples to reflect the present usage, as time permits over the next few days. > Anyway, it looks fascinating, especially the multimethod enhancements. > My brain still wants to think in an object-oriented manner after so > many years of C++ and Java. > > > Special thanks to Chas Emerick, Graham Fawcett, Stephen C. Gilardi, > > Chris Houser and Stuart Sierra for their contributions, and to > > everyone here for your suggestions and bug reports. > > And to you, Rich. > You're welcome! Rich --~--~-~--~~~---~--~~ 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 To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: 20080916 Release
On Sep 16, 7:00 pm, Rich Hickey <[EMAIL PROTECTED]> wrote: > http://sourceforge.net/project/showfiles.php?group_id=137961 > > Added: validators for vars/refs/agents, delay/force, isa-based > multimethods and a la carte hierarchies, require/use/load, namespace > aliases and many more functions and fixes. > > Special thanks to Chas Emerick, Graham Fawcett, Stephen C. Gilardi, > Chris Houser and Stuart Sierra for their contributions, and to > everyone here for your suggestions and bug reports. > > More details at: > > http://clojure.blogspot.com/2008/09/20080916-release.html > > Rich Very cool. :) Thanks Rich and the all Clojure contributors. This is truly a fantastic language and it keeps getting better. I love using it. Parth --~--~-~--~~~---~--~~ 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 To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Access to overloaded java method in org.jscience.physics.amount.Amount
On Sep 16, 9:48 am, markm <[EMAIL PROTECTED]> wrote: > On Sep 16, 7:51 am, Rich Hickey <[EMAIL PROTECTED]> wrote: > > ... > > > The workaround I came up with fails to filter the bridge method in > > org.jscience.physics.amount.Amount. I'm still looking into this issue. > > >http://groups.google.com/group/jvm-languages/browse_frm/thread/a64c75... > > > Rich > > Below is the source code from Amount.divide and Amount.times for the > long and double parameter versions. Other than the obvious > substitution of variable and operator names, the times and > divide methods are structurally equivalent. The times > and divide method have one difference: the divide method makes > use of local variables and -- as do both double methods -- > the times method directly assigns the result of calculation > into the m._minimum and m._maximum fields. > > Could this difference be triggering the jdk/vm 1.6 into treating the > the 'times' methods > differently from the the > 'divide' method? > No. The problem relates to times being inherited from GroupMultiplicative. I understand what is happening, just trying to find a workaround that will work for this case and not break on others (e.g. StringBuilder) Rich --~--~-~--~~~---~--~~ 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 To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: 20080916 Release
On Tuesday 16 September 2008 07:00, Rich Hickey wrote: > http://sourceforge.net/project/showfiles.php?group_id=137961 > > Added: validators for vars/refs/agents, delay/force, isa-based > multimethods and a la carte hierarchies, require/use/load, namespace > aliases and many more functions and fixes. Wow. I thought I was following everything that transpired here, but much of that seems out of the blue to me. Has the documentation been updated to reflect these additions and changes? Anyway, it looks fascinating, especially the multimethod enhancements. My brain still wants to think in an object-oriented manner after so many years of C++ and Java. > Special thanks to Chas Emerick, Graham Fawcett, Stephen C. Gilardi, > Chris Houser and Stuart Sierra for their contributions, and to > everyone here for your suggestions and bug reports. And to you, Rich. > More details at: > > http://clojure.blogspot.com/2008/09/20080916-release.html > > Rich Randall Schulz --~--~-~--~~~---~--~~ 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 To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Access to overloaded java method in org.jscience.physics.amount.Amount
On Sep 16, 7:51 am, Rich Hickey <[EMAIL PROTECTED]> wrote:
...
> The workaround I came up with fails to filter the bridge method in
> org.jscience.physics.amount.Amount. I'm still looking into this issue.
>
> http://groups.google.com/group/jvm-languages/browse_frm/thread/a64c75...
>
> Rich
Below is the source code from Amount.divide and Amount.times for the
long and double parameter versions. Other than the obvious
substitution of variable and operator names, the times and
divide methods are structurally equivalent. The times
and divide method have one difference: the divide method makes
use of local variables and -- as do both double methods --
the times method directly assigns the result of calculation
into the m._minimum and m._maximum fields.
===Java code excerpt from Amount.java
public Amount times(double factor) {
Amount m = Amount.newInstance(_unit);
double min = (factor > 0) ? _minimum * factor : _maximum *
factor;
double max = (factor > 0) ? _maximum * factor : _minimum *
factor;
m._isExact = false;
m._minimum = (min < 0) ? min * INCREMENT : min * DECREMENT;
m._maximum = (max < 0) ? max * DECREMENT : max * INCREMENT;
return m;
}
public Amount divide(double divisor) {
Amount m = Amount.newInstance(_unit);
double min = (divisor > 0) ? _minimum / divisor : _maximum /
divisor;
double max = (divisor > 0) ? _maximum / divisor : _minimum /
divisor;
m._isExact = false;
m._minimum = (min < 0) ? min * INCREMENT : min * DECREMENT;
m._maximum = (max < 0) ? max * DECREMENT : max * INCREMENT;
return m;
}
public Amount times(long factor) {
Amount m = Amount.newInstance(_unit);
if (this._isExact) {
long productLong = _exactValue * factor;
double productDouble = ((double) _exactValue) * factor;
if (productLong == productDouble)
return m.setExact(productLong);
}
m._isExact = false;
m._minimum = (factor > 0) ? _minimum * factor : _maximum *
factor;
m._maximum = (factor > 0) ? _maximum * factor : _minimum *
factor;
return m;
}
public Amount divide(long divisor) {
Amount m = Amount.newInstance(_unit);
if (this._isExact) {
long quotientLong = _exactValue / divisor;
double quotientDouble = ((double) _exactValue) / divisor;
if (quotientLong == quotientDouble)
return m.setExact(quotientLong);
}
double min = (divisor > 0) ? _minimum / divisor : _maximum /
divisor;
double max = (divisor > 0) ? _maximum / divisor : _minimum /
divisor;
m._isExact = false;
m._minimum = (min < 0) ? min * INCREMENT : min * DECREMENT;
m._maximum = (max < 0) ? max * DECREMENT : max * INCREMENT;
return m;
}
=
Could this difference be triggering the jdk/vm 1.6 into treating the
the 'times' methods
differently from the the
'divide' method?
Mark
--~--~-~--~~~---~--~~
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
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
20080916 Release
http://sourceforge.net/project/showfiles.php?group_id=137961 Added: validators for vars/refs/agents, delay/force, isa-based multimethods and a la carte hierarchies, require/use/load, namespace aliases and many more functions and fixes. Special thanks to Chas Emerick, Graham Fawcett, Stephen C. Gilardi, Chris Houser and Stuart Sierra for their contributions, and to everyone here for your suggestions and bug reports. More details at: http://clojure.blogspot.com/2008/09/20080916-release.html Rich --~--~-~--~~~---~--~~ 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 To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Clojure Poll 09/2008
On Sep 10, 8:40 pm, Rich Hickey <[EMAIL PROTECTED]> wrote: > As we rapidly approach 500 members on the group (!) I thought it would > be a good time to conduct another poll: > > What are you doing with Clojure? > I'm doing useless stuff with Clojure. > What 3 features would you most like to see added next? > >From my 2 hour experience with Clojure I want these features: 1. Better error messages with helpful suggestions and a pointer to a "wiki" for each error. The wiki should have a reddit-system with the most "popular" problems related to an error. A snapshot of the error- wiki could be included in Clojure. 2. Clojure states that it has good support for list comprehensions. Maybe I'm misunderstanding list comprehensions, but I'm not completely happy. I want a way to have destructuring work on the sequence, not on the individual element. In CL you have (loop for i in '(1 2 3) ...) as well as (loop for i on '(1 2 3) ...). How is the one-liner to create a lazy sliding window over a sequence in Clojure? 3. The Clojure coding style sets a bad precedent wrt commenting. Using Clojure professionally means you need comments. The (comment ...) form, although theoretically elegant just doesn't look good. There is not a single comment in boot.clj. Is this a coincidence? 4. Preconditions/postconditions/invariants. I like them, and I don't see them in Clojure. 5. Please document that "everybody" is using the svn/git versions of the code and that you are wasting your time if you download the distribution and try to get it to work in emacs. People using Clojure will have no problems using the svn version, but it is annoying to have to figure it out by searching through Google Groups. Alexander --~--~-~--~~~---~--~~ 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 To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
