Re: cool compiler-project?

[Nicolas Oury]

There is a size limit on methods on the jVM.

partial-evaluator would be a cool project, I think.

On Thu, Aug 19, 2010 at 6:38 AM, Tim Daly  wrote:
> Could the compiler insert phantom "method bodies" around classes?
> Or does the JVM insist that you can't "lie about the code structure"?
> Am I being too lispish for the JVM? Clearly the JVM needs to look up
> some factoid out of the method body in order to recur so I'm suggesting
> that the whole set of classes get wrapped in a phantom method.
>
> The code that comes out of the compiler does not need to mirror
> the code that went into the compiler. That's the whole point of
> doing compiler optimizations.
>
> Perhaps a literature pointer could make the restriction clear.
>
> Tim Daly
>
> Kevin Downey wrote:
>>
>> only in the cases already handled by recur.
>>
>> jvm's goto instruction only works within method bodies
>>
>> On Wed, Aug 18, 2010 at 6:24 PM, Tim Daly 
>> wrote:
>>
>>>
>>> Write a compiler routine to detect tail recursion.
>>>
>>> It is my (limited) understanding that Java can perform
>>> tail recursion elimination but only under limited
>>> conditions.
>>>
>>> Is there a way to detect tail recursion in Clojure and
>>> dynamically rewrite the code to do real recursion rather
>>> than using recur? Is your solution general enough?
>>>
>>> Mark Derricutt wrote:
>>>

 Or a native dalvik compiler!

 --
 Pull me down under...



 On Thu, Aug 19, 2010 at 10:37 AM, Jules >>> > wrote:

   Or a Clojure to Javascript compiler. So many interesting projects!


 --
 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

>>>
>>> --
>>> 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
>>>
>>
>>
>>
>>
>
> --
> 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

-- 
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: cool compiler-project?

[Tim Daly]

Could the compiler insert phantom "method bodies" around classes?
Or does the JVM insist that you can't "lie about the code structure"?
Am I being too lispish for the JVM? Clearly the JVM needs to look up
some factoid out of the method body in order to recur so I'm suggesting
that the whole set of classes get wrapped in a phantom method.

The code that comes out of the compiler does not need to mirror
the code that went into the compiler. That's the whole point of
doing compiler optimizations.

Perhaps a literature pointer could make the restriction clear.

Tim Daly

Kevin Downey wrote:

only in the cases already handled by recur.

jvm's goto instruction only works within method bodies

On Wed, Aug 18, 2010 at 6:24 PM, Tim Daly  wrote:
  

Write a compiler routine to detect tail recursion.

It is my (limited) understanding that Java can perform
tail recursion elimination but only under limited
conditions.

Is there a way to detect tail recursion in Clojure and
dynamically rewrite the code to do real recursion rather
than using recur? Is your solution general enough?

Mark Derricutt wrote:


Or a native dalvik compiler!

--
Pull me down under...



On Thu, Aug 19, 2010 at 10:37 AM, Jules mailto:julesjac...@gmail.com>> wrote:

   Or a Clojure to Javascript compiler. So many interesting projects!


--
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
  

--
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





  


--
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: What is the reason Lisp code is not written with closing parenthesis on new lines?

[Rayne]

It isn't helpful at all to me. My eyes bleed when I see code written
like that.

It may be helpful to some people, but I don't see the point when I
have an editor that can match parens for me without any real work on
my part. The parens aren't something I feel I need to "maintain",
because between paredit and paren matching, I never have problems with
them.

On Aug 18, 4:09 am, michele  wrote:
> Wouldn't that make it easier to keep track of them.
>
> Example:
>
> (defn myfn-a [a b]
>   (if (zero? b)
>     a
>     (recur
>       (afn (bfn (...)) a)
>       (dec b
>
> (defn myfn-b [a b]
>   (if (zero? b)
>     a
>     (recur
>       (afn (bfn (...)) a)
>       (dec b)
>     )
>   )
> )

-- 
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: cool compiler-project?

[Kevin Downey]

only in the cases already handled by recur.

jvm's goto instruction only works within method bodies

On Wed, Aug 18, 2010 at 6:24 PM, Tim Daly  wrote:
> Write a compiler routine to detect tail recursion.
>
> It is my (limited) understanding that Java can perform
> tail recursion elimination but only under limited
> conditions.
>
> Is there a way to detect tail recursion in Clojure and
> dynamically rewrite the code to do real recursion rather
> than using recur? Is your solution general enough?
>
> Mark Derricutt wrote:
>>
>> Or a native dalvik compiler!
>>
>> --
>> Pull me down under...
>>
>>
>>
>> On Thu, Aug 19, 2010 at 10:37 AM, Jules > > wrote:
>>
>>    Or a Clojure to Javascript compiler. So many interesting projects!
>>
>>
>> --
>> 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
>
> --
> 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



-- 
And what is good, Phaedrus,
And what is not good—
Need we ask anyone to tell us these things?

-- 
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: What is the reason Lisp code is not written with closing parenthesis on new lines?

[Greg]

On Aug 18, 2010, at 7:48 PM, Paul Stadig wrote:
> It may help *you* grasp the meaning more quickly, but the opposite may be 
> true for others. But I guess automatic formatting would totally destroy the 
> ability to talk about line 16 of a particular file.
> 
This is a nifty point and idea.

I think I'd enjoy living in such a world, as it would probably support a more 
harmonious existence amongst coders, somewhat in the same vein as the good that 
comes out of racial-tolerance. Your code may look different than mine, but it's 
still cool because they both compile just the same. ;-)

In such a world it may be better than to speak of expression numbers instead of 
line numbers, but alas, that would require quite a departure from the world of 
editors that we live in today.

- Greg

> I've rarely found these coding style discussions to be productive, and have 
> wondered why source control systems don't just store code in a whitespace 
> normalized format and automatically format the code to your own taste when 
> you check it out, because, let's face it, formatting is semantically 
> irrelevant. It may help *you* grasp the meaning more quickly, but the 
> opposite may be true for others. But I guess automatic formatting would 
> totally destroy the ability to talk about line 16 of a particular file.
> 
> Then I move on to thinking it best for a language designer to just legislate 
> fomatting and make it a compiler error, but that would probably generate more 
> discussion than otherwise, so I've just written the whole thing off as a 
> lose-lose situation. But maybe I'm just getting cumudgenly in my old age.
> 
> I do however firmly believe that each language has a worldview and a culture 
> that coaleces around it, and one is better off either adopting it whole hog, 
> or finding another language that matches better with one's own worldview. 
> Something akin to what Brenton said about choosing a language because it 
> mirrors your thinking, not because of readability concerns. It is a disaster 
> to try to force the idioms of one language to be true in another.
> Paul
> 
> 
> -- 
> 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

-- 
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: What is the reason Lisp code is not written with closing parenthesis on new lines?

[Mike Meyer]

On Wed, 18 Aug 2010 22:48:07 -0400
Paul Stadig  wrote:
> Then I move on to thinking it best for a language designer to just legislate
> fomatting and make it a compiler error, but that would probably generate
> more discussion than otherwise, so I've just written the whole thing off as
> a lose-lose situation. But maybe I'm just getting cumudgenly in my old age.

You could argue that this is the route that ABC/Python took -
formatting, not punctuation, dictates flow control. Broken formatting
generates compiler errors:

python /tmp/break.py 
  File "/tmp/break.py", line 3
print 4
^
IndentationError: unexpected indent


So people argue about putting back the punctuation instead of where
the punctuation goes. Not quite as much, but it still happens.

 http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.

O< ascii ribbon campaign - stop html mail - www.asciiribbon.org

-- 
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: What is the reason Lisp code is not written with closing parenthesis on new lines?

[Cyrus Harmon]

I'm reminded gigamonkey's footnote about when functions get too big:

"A friend of mine was once interviewing an engineer for a programming job and 
asked him a typical interview question: how do you know when a function or 
method is too big? Well, said the candidate, I don't like any method to be 
bigger than my head. You mean you can't keep all the details in your head? No, 
I mean I put my head up against my monitor, and the code shouldn't be bigger 
than my head." [1]

There are many different styles for source code, but my experience with lisp 
suggests that variable indentation (as provided by emacs lisp-mode or 
clojure-mode) and parens-not-on-their-own-line makes for much more readable 
code. core.clj is a good example where the code is generally readable, but I 
shudder to think what it would be like to read the code for doseq or 
destructure if each closing parenthesis were on its own line.

And, as for writing code, I couldn't live without paredit.

To each their own, but let's not go down the route of saying "hey, you're code 
formatting style sucks, but I don't want to start a flame war" :).

Cyrus

1. http://www.gigamonkeys.com/book/practical-a-simple-database.html

On Aug 18, 2010, at 6:24 PM, wwmorgan wrote:

> The Incanter example is confusing for the same reason that the
> Leiningen example from the blog post is confusing, and I don't think
> paren style matters at all. The functions have grown over time,
> they're now too big, and they need to be refactored into several
> smaller functions. The paren style is a red herring. core.clj is
> readable because its functions are short.
> 
> When your code makes you want to outdent, you can take this as a
> signal that your function has gotten too big and needs to be
> refactored.
> 
> - Will Morgan
> 
> On Aug 18, 4:36 pm, Greg  wrote:
>>> Now the question you're asking is, why don't lispers write
>>>  (MyFactory somearg
>>>  )
>>> which makes me cringe.
>> 
>> That's not at all what's being suggested -- you'll find that both in the 
>> OP's code and in the link below, there are many locations where closing 
>> parenthesis are ended on the same line.
>> 
>> Trailing parens are placed only for certain blocks that traditionally would 
>> define a "scope" in another language, and this is convenient for many 
>> reasons, including generic reasons not attached to any specific language. 
>> It's not about carrying over "much loved C style" to Lisp, but to make 
>> actual use of parenthesis for the purpose of clearly outlining the structure 
>> of your code.
>> 
>> Again, the link goes much more into depth on this.
>> 
>> Attached is a screenshot of some code from the wonderful Incanter library. I 
>> think it's a great illustration of how confusing stacking parenthesis can be 
>> (there are many functions in there that are like this).
>> 
>> The readability issue occurs when there's a drop in several indentation 
>> levels after many lines.  This is a problem regardless of what the 
>> indentation width is, but is certainly made worse by a small indentation 
>> width.
>> 
>> - Greg
>> 
>>  Screen shot 2010-08-18 at 1.32.09 PM.png
>> 48KViewDownload
>> 
>> 
>> 
>> On Aug 18, 2010, at 1:17 PM, Tim Daly wrote:
>> 
>>> A more serious answer is that when I code in Java I use the
>>> brace-on-a-line kind of indentation. When I code in Lisp I
>>> never write single-line parens of any kind.
>> 
>>> I find that I think differently in each language.
>> 
>>> My Java code is always a pile of declare-this, do-this, do-this, return
>>> Thus I find that I'm delimiting the scope of my variables, marking my
>>> control flow and branching logic, try/catch logic, class boundaries, etc.
>> 
>>> My Lisp code mixes control flow and data structures in the same syntax.
>>> Thus the idea that parens are some kind of control flow delimiter is
>>> not particularly meaningful.
>> 
>>> To see the alternative case, take a Java program, find every function call
>>> such as:
>>>   MyFactory(somearg);
>>> throw away the ';', and move the paren left to get:
>>>  (MyFactory somearg)
>> 
>>> Now the question you're asking is, why don't lispers write
>>>  (MyFactory somearg
>>>  )
>>> which makes me cringe.
>> 
>>> A second reason is that Lisp allows you to think things that Java
>>> does not. Java has this imperative, object-oriented, hierarchical
>>> style of writing. My lisp code sytle varies to fit the problem.
>>> Sometimes it is imperative, sometimes functional, sometimes OO,
>>> sometimes snobol-like pattern matching, sometimes class-based.
>>> Occasionally I dynamically construct the code and execute it inline.
>>> Or I use macros to create my own problem language and code in that.
>>> And I create my data structures "on the fly" inline to the code.
>> 
>>> Once you really internalize lisp there are no real constraints
>>> on what you think or write. Thus there is no question of "bracing
>>> style" that is meaningful.
>> 
>>> The whole idea of "bracing style" is Java-think. Yo

Re: What is the reason Lisp code is not written with closing parenthesis on new lines?

[Paul Stadig]

I've rarely found these coding style discussions to be productive, and have
wondered why source control systems don't just store code in a whitespace
normalized format and automatically format the code to your own taste when
you check it out, because, let's face it, formatting is semantically
irrelevant. It may help *you* grasp the meaning more quickly, but the
opposite may be true for others. But I guess automatic formatting would
totally destroy the ability to talk about line 16 of a particular file.

Then I move on to thinking it best for a language designer to just legislate
fomatting and make it a compiler error, but that would probably generate
more discussion than otherwise, so I've just written the whole thing off as
a lose-lose situation. But maybe I'm just getting cumudgenly in my old age.

I do however firmly believe that each language has a worldview and a culture
that coaleces around it, and one is better off either adopting it whole hog,
or finding another language that matches better with one's own worldview.
Something akin to what Brenton said about choosing a language because it
mirrors your thinking, not because of readability concerns. It is a disaster
to try to force the idioms of one language to be true in another.

Paul

-- 
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: Today's clojure trick question

[joegallo]

> However, if you do (let [x (java.lang.Boolean/getBoolean "false")] (if
> x :trouble :ok)) you're fine, which obviously isn't helpful in your
> situation.

Boolean.getBoolean() is pretty evil, too.  It was featured in one of
Joshua Bloch's java puzzlers (which might have been borrowed from
somewhere else, I don't know if it was originally his).  Watch out, it
might not do what you think it does. :)

For instance:
System.out.println(Boolean.getBoolean("false"));
System.out.println(Boolean.getBoolean("true"));
System.out.println(Boolean.getBoolean("fred"));

will print false three times.

Joe

-- 
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: cool compiler-project?

[Tim Daly]

Write a compiler routine to detect tail recursion.

It is my (limited) understanding that Java can perform
tail recursion elimination but only under limited
conditions.

Is there a way to detect tail recursion in Clojure and
dynamically rewrite the code to do real recursion rather
than using recur? Is your solution general enough?

Mark Derricutt wrote:

Or a native dalvik compiler!

--
Pull me down under...



On Thu, Aug 19, 2010 at 10:37 AM, Jules > wrote:


Or a Clojure to Javascript compiler. So many interesting projects!


--
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 


--
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: What is the reason Lisp code is not written with closing parenthesis on new lines?

[wwmorgan]

The Incanter example is confusing for the same reason that the
Leiningen example from the blog post is confusing, and I don't think
paren style matters at all. The functions have grown over time,
they're now too big, and they need to be refactored into several
smaller functions. The paren style is a red herring. core.clj is
readable because its functions are short.

When your code makes you want to outdent, you can take this as a
signal that your function has gotten too big and needs to be
refactored.

- Will Morgan

On Aug 18, 4:36 pm, Greg  wrote:
> > Now the question you're asking is, why don't lispers write
> >  (MyFactory somearg
> >  )
> > which makes me cringe.
>
> That's not at all what's being suggested -- you'll find that both in the OP's 
> code and in the link below, there are many locations where closing 
> parenthesis are ended on the same line.
>
> Trailing parens are placed only for certain blocks that traditionally would 
> define a "scope" in another language, and this is convenient for many 
> reasons, including generic reasons not attached to any specific language. 
> It's not about carrying over "much loved C style" to Lisp, but to make actual 
> use of parenthesis for the purpose of clearly outlining the structure of your 
> code.
>
> Again, the link goes much more into depth on this.
>
> Attached is a screenshot of some code from the wonderful Incanter library. I 
> think it's a great illustration of how confusing stacking parenthesis can be 
> (there are many functions in there that are like this).
>
> The readability issue occurs when there's a drop in several indentation 
> levels after many lines.  This is a problem regardless of what the 
> indentation width is, but is certainly made worse by a small indentation 
> width.
>
> - Greg
>
>  Screen shot 2010-08-18 at 1.32.09 PM.png
> 48KViewDownload
>
>
>
> On Aug 18, 2010, at 1:17 PM, Tim Daly wrote:
>
> > A more serious answer is that when I code in Java I use the
> > brace-on-a-line kind of indentation. When I code in Lisp I
> > never write single-line parens of any kind.
>
> > I find that I think differently in each language.
>
> > My Java code is always a pile of declare-this, do-this, do-this, return
> > Thus I find that I'm delimiting the scope of my variables, marking my
> > control flow and branching logic, try/catch logic, class boundaries, etc.
>
> > My Lisp code mixes control flow and data structures in the same syntax.
> > Thus the idea that parens are some kind of control flow delimiter is
> > not particularly meaningful.
>
> > To see the alternative case, take a Java program, find every function call
> > such as:
> >   MyFactory(somearg);
> > throw away the ';', and move the paren left to get:
> >  (MyFactory somearg)
>
> > Now the question you're asking is, why don't lispers write
> >  (MyFactory somearg
> >  )
> > which makes me cringe.
>
> > A second reason is that Lisp allows you to think things that Java
> > does not. Java has this imperative, object-oriented, hierarchical
> > style of writing. My lisp code sytle varies to fit the problem.
> > Sometimes it is imperative, sometimes functional, sometimes OO,
> > sometimes snobol-like pattern matching, sometimes class-based.
> > Occasionally I dynamically construct the code and execute it inline.
> > Or I use macros to create my own problem language and code in that.
> > And I create my data structures "on the fly" inline to the code.
>
> > Once you really internalize lisp there are no real constraints
> > on what you think or write. Thus there is no question of "bracing
> > style" that is meaningful.
>
> > The whole idea of "bracing style" is Java-think. Your language
> > choice has given you an OO-procedural mindset. So when you reach
> > for Lisp you want to see what you have come to expect. People who
> > work with bricks (Java) tend to wonder why they don't find bricks
> > among people who work with modelling clay (Lisp). The answer isn't
> > in the material, it is in your mindset.
>
> > Just by looking at lisp code I can tell what your native language
> > is. Fortran programmers simulate COMMON blocks, C programmers use
> > things as pointers, etc. "You can write Fortran in any language"
> > is a famous quote but "you can't write Lisp in any language". And
> > you can quote me on that. (But only in my obituary :-) )
>
> > In fact, I think that this is going to be the hardest barrier
> > to the adoption of Clojure. "Real Java Programmers" are not going
> > to like the bracing style (or lack thereof) in Clojure.
>
> > Tim Daly
>
> > Greg wrote:
> >> It's almost purely community convention that has been adopted from Lisp.
>
> >> You may be interested in this link:
>
> >>http://gregslepak.posterous.com/on-lisps-readability
>
> >> There is much discussion about this topic there.
>
> >> Cheers,
> >> Greg
>
> >> On Aug 18, 2010, at 2:09 AM, michele wrote:
>
> >>> Wouldn't that make it easier to keep track of them.
>
> >>> Example:
>
> >>> (defn myfn-a [a b]
> >>> (if

Re: cool compiler-project?

[Mark Derricutt]

Or a native dalvik compiler!

-- 
Pull me down under...



On Thu, Aug 19, 2010 at 10:37 AM, Jules  wrote:

> Or a Clojure to Javascript compiler. So many interesting projects!
>

-- 
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: cool compiler-project?

[cej38]

+1 for an optimizer

-- 
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: cool compiler-project?

[Angel Java Lopez]

Hi people!

Related to Clojure to Javascript

http://github.com/richhickey/clojure-contrib/tree/master/clojurescript/

Angel "Java" Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez


On Wed, Aug 18, 2010 at 7:37 PM, Jules  wrote:
> Or a Clojure to Javascript compiler. So many interesting projects!
>
> On Aug 19, 12:36 am, Jules  wrote:
>> > so presumably the Clojure compiler does
>>
>> not include an optimizer.
>>
>> So write an optimizing Clojure compiler! Or do type inference for
>> Clojure. Or partial evaluation. Or a compiler that targets LLVM.
>>
>> On Aug 18, 10:46 pm, ".Bill Smith"  wrote:
>>
>>
>>
>> > While I think Clojure is an impressive achievement, I would not have
>> > thought that the Clojure compiler  (or Lisp compilers in general)
>> > would be interesting for a post-grad student to work on.  After all,
>> > Lisps are known for their simple syntax and grammar, and Clojure
>> > compiles to Java byte codes, so presumably the Clojure compiler does
>> > not include an optimizer.
>>
>> > Bill Smith
>> > Austin, Texas
>>
>> > On Aug 18, 7:35 am, Sreeraj a  wrote:
>>
>> > > Hi,
>> > > I am a post-grad student looking for a cool compiler - project to do.
>> > > I am getting comfortable with clojure and would really like to help
>>
>> > > Ideas anyone?
>> > > or, Is there a to-do list where can i start?
>>
>> > > Cheers
>> > > Sreeraj
>
> --
> 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

-- 
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: What is the reason Lisp code is not written with closing parenthesis on new lines?

[Fogus]

I wrote a post about this very thread.
http://blog.fogus.me/2010/07/12/wadlers-law-extended-to-clojure/

:f

-- 
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: cool compiler-project?

[Jules]

Or a Clojure to Javascript compiler. So many interesting projects!

On Aug 19, 12:36 am, Jules  wrote:
> > so presumably the Clojure compiler does
>
> not include an optimizer.
>
> So write an optimizing Clojure compiler! Or do type inference for
> Clojure. Or partial evaluation. Or a compiler that targets LLVM.
>
> On Aug 18, 10:46 pm, ".Bill Smith"  wrote:
>
>
>
> > While I think Clojure is an impressive achievement, I would not have
> > thought that the Clojure compiler  (or Lisp compilers in general)
> > would be interesting for a post-grad student to work on.  After all,
> > Lisps are known for their simple syntax and grammar, and Clojure
> > compiles to Java byte codes, so presumably the Clojure compiler does
> > not include an optimizer.
>
> > Bill Smith
> > Austin, Texas
>
> > On Aug 18, 7:35 am, Sreeraj a  wrote:
>
> > > Hi,
> > > I am a post-grad student looking for a cool compiler - project to do.
> > > I am getting comfortable with clojure and would really like to help
>
> > > Ideas anyone?
> > > or, Is there a to-do list where can i start?
>
> > > Cheers
> > > Sreeraj

-- 
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: cool compiler-project?

[Jules]

> so presumably the Clojure compiler does
not include an optimizer.

So write an optimizing Clojure compiler! Or do type inference for
Clojure. Or partial evaluation. Or a compiler that targets LLVM.

On Aug 18, 10:46 pm, ".Bill Smith"  wrote:
> While I think Clojure is an impressive achievement, I would not have
> thought that the Clojure compiler  (or Lisp compilers in general)
> would be interesting for a post-grad student to work on.  After all,
> Lisps are known for their simple syntax and grammar, and Clojure
> compiles to Java byte codes, so presumably the Clojure compiler does
> not include an optimizer.
>
> Bill Smith
> Austin, Texas
>
> On Aug 18, 7:35 am, Sreeraj a  wrote:
>
>
>
> > Hi,
> > I am a post-grad student looking for a cool compiler - project to do.
> > I am getting comfortable with clojure and would really like to help
>
> > Ideas anyone?
> > or, Is there a to-do list where can i start?
>
> > Cheers
> > Sreeraj

-- 
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: What is the reason Lisp code is not written with closing parenthesis on new lines?

[Greg]

> Too bad. If you wanted to focus on the trailing-parens (which you clearly did 
> in that article), you should have kept everything else the same between your 
> examples.

Perhaps I should, then I wouldn't have to respond to your emails. :-p

As I've said multiple times now, now indentation width does help readability, 
but adding trailing parenthesis on top of that can increase it further.

>From an information theoretic point of view, it should be obvious. Whereas on 
>the one hand you only have one bit of information to judge what function 
>you're in (just increasing indentation width), on the other you have two bits 
>(indentation width + trailing parenthesis).

> Closing the comments after people started to question you on this wasn't a 
> good move, either (otherwise I'd be commenting there rather than here).

Oh goodie, it seems like it was a good move after all. :-P

- Greg

On Aug 18, 2010, at 1:33 PM, Michael Gardner wrote:

> On Aug 18, 2010, at 2:49 PM, Greg wrote:
> 
>> On Aug 18, 2010, at 12:07 PM, Michael Gardner wrote:
>> 
>>> On Aug 18, 2010, at 1:38 PM, Greg wrote:
>>> 
 http://gregslepak.posterous.com/on-lisps-readability
>>> 
>>> That article is dishonest.
>> 
>> Speaking as the author, I'm a bit offended.
> 
> Too bad. If you wanted to focus on the trailing-parens (which you clearly did 
> in that article), you should have kept everything else the same between your 
> examples.
> 
> If you wanted to comment on indentation as well, you should have (a) given it 
> equal prominence in your discussion, (b) used separate code examples for 
> trailing-parens vs indentation, and/or (c) made a separate post.
> 
> Closing the comments after people started to question you on this wasn't a 
> good move, either (otherwise I'd be commenting there rather than here).
> 
> -- 
> 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

-- 
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: What is the reason Lisp code is not written with closing parenthesis on new lines?

[Greg]

> Yes, I read the link. I'm going to hazard a guess that lisp is not your 
> native language :-)

I consider Lisp to be one of my favorite languages (if not my favorite), and 
I've been coding in it for several years.

It's rather silly to assume something about someone's programming experience 
based on their code style. Sometimes you'd be right, and other times you'd be 
wrong, just as with any sort of stereotyping.

> "Scope" is a very slippery concept in a language like lisp.
> Where it does occur in obvious cases (e.g.  a "let") you'll
> find that lispers universally indent their code, just like everyone else.


This I understand very well (as I mentioned in the post).

It really has no bearing on the central argument though. It's only introduced 
as a guideline as to where you might want to consider trailing your parens.

> That's a very personal issue and I don't think I've ever struggled to 
> understand code based on the outdenting style. 

> 

I think I've said that several times now. :-)

I actually do like the succinctness of stacked parenthesis, but unfortunately 
that style has many shortcomings that I find rather annoying. Again, to each 
his own.

Sincerely,
Greg Slepak

On Aug 18, 2010, at 2:49 PM, Tim Daly wrote:

> 
> 
> Greg wrote:
>>> Now the question you're asking is, why don't lispers write
>>> (MyFactory somearg
>>> )
>>> which makes me cringe.
>>>
>> 
>> That's not at all what's being suggested -- you'll find that both in the 
>> OP's code and in the link below, there are many locations where closing 
>> parenthesis are ended on the same line.
>>  Trailing parens are placed only for certain blocks that traditionally would 
>> define a "scope" in another language, and this is convenient for many 
>> reasons, including generic reasons not attached to any specific language. 
>> It's not about carrying over "much loved C style" to Lisp, but to make 
>> actual use of parenthesis for the purpose of clearly outlining the structure 
>> of your code.
>>  
> In lisp it is functions all the way down. Defining functions
> that introduce "scope" and having them outdent is odd.
> 
> Some of those functions could be macros which introduce
> lexical or dynamic scope. Should functions that are macros
> use outdenting? Maybe some should, such as (with-open-file...)
> but I often have macros that introduce binding blocks yet they
> appear to the user to be a function. (e.g. the MyFactory macro)
> 
> "Scope" is a very slippery concept in a language like lisp.
> Where it does occur in obvious cases (e.g.  a "let") you'll
> find that lispers universally indent their code, just like everyone else.
>> Again, the link goes much more into depth on this.
>>  
> Yes, I read the link. I'm going to hazard a guess that lisp is not your 
> native language :-)
>> Attached is a screenshot of some code from the wonderful Incanter library. I 
>> think it's a great illustration of how confusing stacking parenthesis can be 
>> (there are many functions in there that are like this).
>> 
>> The readability issue occurs when there's a drop in several indentation 
>> levels after many lines.  This is a problem regardless of what the 
>> indentation width is, but is certainly made worse by a small indentation 
>> width.
>>  
> Well, if all else fails, try (pprint your-expression) and see what the 
> canonical version is.
> 
> The modelling clay (lisp) doesn't care, it reflects the shape of your 
> thoughts.
> If you want brick shapes (java), the lisp reader won't care.
> 
> Your claim seems to be that outdented code in brick form is easier to read 
> and understand.
> That's a very personal issue and I don't think I've ever struggled to 
> understand code based
> on the outdenting style. (Factory, Visitor, Facade, etc. DO cause me to 
> stumble :-) )
> 
> I do think it is interesting that most of the code snippets I see posted here 
> in Clojure
> do not tend to use outdenting brace style. And when I look at core.clj I 
> don't see any
> outdenting going on but I find the code highly readable. In fact, I can't 
> find a single
> instance of outdenting anywhere in src/clj/clojure. Rich has obviously 
> discovered
> his inner lisp.
> 
> Anyway, since this is a "religious issue" with no resolution I can only 
> recommend:
> http://www.youtube.com/watch?v=5-OjTPj7K54
> 
> Beware the lightning :-)
> 
> Tim Daly
> 
> 
> 
>> - Greg
>> 
>>  
>> 
>> 
>> On Aug 18, 2010, at 1:17 PM, Tim Daly wrote:
>> 
>>  
>>> A more serious answer is that when I code in Java I use the
>>> brace-on-a-line kind of indentation. When I code in Lisp I
>>> never write single-line parens of any kind.
>>> 
>>> I find that I think differently in each language.
>>> 
>>> My Java code is always a pile of declare-this, do-this, do-this, return
>>> Thus I find that I'm delimiting the scope of my variables, marking my
>>> control flow and branching logic, try/catch logic, class boundaries

Re: What is the reason Lisp code is not written with closing parenthesis on new lines?

[Tim Daly]

Greg wrote:

Now the question you're asking is, why don't lispers write
 (MyFactory somearg
 )
which makes me cringe.



That's not at all what's being suggested -- you'll find that both in the OP's 
code and in the link below, there are many locations where closing parenthesis 
are ended on the same line.
  
Trailing parens are placed only for certain blocks that traditionally would define a "scope" in another language, and this is convenient for many reasons, including generic reasons not attached to any specific language. It's not about carrying over "much loved C style" to Lisp, but to make actual use of parenthesis for the purpose of clearly outlining the structure of your code.
  

In lisp it is functions all the way down. Defining functions
that introduce "scope" and having them outdent is odd.

Some of those functions could be macros which introduce
lexical or dynamic scope. Should functions that are macros
use outdenting? Maybe some should, such as (with-open-file...)
but I often have macros that introduce binding blocks yet they
appear to the user to be a function. (e.g. the MyFactory macro)

"Scope" is a very slippery concept in a language like lisp.
Where it does occur in obvious cases (e.g.  a "let") you'll
find that lispers universally indent their code, just like everyone else.

Again, the link goes much more into depth on this.
  
Yes, I read the link. I'm going to hazard a guess that lisp is not your 
native language :-)

Attached is a screenshot of some code from the wonderful Incanter library. I 
think it's a great illustration of how confusing stacking parenthesis can be 
(there are many functions in there that are like this).

The readability issue occurs when there's a drop in several indentation levels 
after many lines.  This is a problem regardless of what the indentation width 
is, but is certainly made worse by a small indentation width.
  
Well, if all else fails, try (pprint your-expression) and see what the 
canonical version is.


The modelling clay (lisp) doesn't care, it reflects the shape of your 
thoughts.

If you want brick shapes (java), the lisp reader won't care.

Your claim seems to be that outdented code in brick form is easier to 
read and understand.
That's a very personal issue and I don't think I've ever struggled to 
understand code based
on the outdenting style. (Factory, Visitor, Facade, etc. DO cause me to 
stumble :-) )


I do think it is interesting that most of the code snippets I see posted 
here in Clojure
do not tend to use outdenting brace style. And when I look at core.clj I 
don't see any
outdenting going on but I find the code highly readable. In fact, I 
can't find a single
instance of outdenting anywhere in src/clj/clojure. Rich has obviously 
discovered

his inner lisp.

Anyway, since this is a "religious issue" with no resolution I can only 
recommend:

http://www.youtube.com/watch?v=5-OjTPj7K54

Beware the lightning :-)

Tim Daly




- Greg

  




On Aug 18, 2010, at 1:17 PM, Tim Daly wrote:

  

A more serious answer is that when I code in Java I use the
brace-on-a-line kind of indentation. When I code in Lisp I
never write single-line parens of any kind.

I find that I think differently in each language.

My Java code is always a pile of declare-this, do-this, do-this, return
Thus I find that I'm delimiting the scope of my variables, marking my
control flow and branching logic, try/catch logic, class boundaries, etc.

My Lisp code mixes control flow and data structures in the same syntax.
Thus the idea that parens are some kind of control flow delimiter is
not particularly meaningful.

To see the alternative case, take a Java program, find every function call
such as:
  MyFactory(somearg);
throw away the ';', and move the paren left to get:
 (MyFactory somearg)

Now the question you're asking is, why don't lispers write
 (MyFactory somearg
 )
which makes me cringe.

A second reason is that Lisp allows you to think things that Java
does not. Java has this imperative, object-oriented, hierarchical
style of writing. My lisp code sytle varies to fit the problem.
Sometimes it is imperative, sometimes functional, sometimes OO,
sometimes snobol-like pattern matching, sometimes class-based.
Occasionally I dynamically construct the code and execute it inline.
Or I use macros to create my own problem language and code in that.
And I create my data structures "on the fly" inline to the code.

Once you really internalize lisp there are no real constraints
on what you think or write. Thus there is no question of "bracing
style" that is meaningful.

The whole idea of "bracing style" is Java-think. Your language
choice has given you an OO-procedural mindset. So when you reach
for Lisp you want to see what you have come to expect. People who
work with bricks (Java) tend to wonder why they don't find bricks
among people who work with modelling clay (Lisp). The answer isn't
in the

Re: What is the reason Lisp code is not written with closing parenthesis on new lines?

[Sean Corfield]

On Wed, Aug 18, 2010 at 1:36 PM, Greg  wrote:
> Attached is a screenshot of some code from the wonderful Incanter library. I 
> think it's a great illustration of how confusing stacking parenthesis can be 
> (there are many functions in there that are like this).

But the indentation is broken in that code already. If the indentation
were fixed (and the long functions refactored) it would be a lot more
readable. In order to reformat it with trailing parens, you'd have to
fix the basic indentation first anyway...

In the blog post's example, I found the println 'parent' straight away
and the extra vertical whitespace didn't help (sorry but lone closing
parens just create vertical whitespace for me).

I did find the 4 char indents easier to read than the 2 char indents.
I wish CCW respected the "displayed tab width" setting as its
indentation in strict structural mode as I'd rather have 4 spaces than
2 but it seems 2 is pretty much the standard around here?

> The readability issue occurs when there's a drop in several indentation 
> levels after many lines.  This is a problem regardless of what the 
> indentation width is, but is certainly made worse by a small indentation 
> width.

The readability of the attached screenshot is due to broken
indentation and the function being too long, IMO.

(and, for background, I'm far more used to programming in C-style
languages even tho' my Lisp usages dates back to the early 80's - but
I do find I naturally settle into a different style in Lisp to what I
use elsewhere)
-- 
Sean A Corfield -- (904) 302-SEAN
Railo Technologies, Inc. -- http://getrailo.com/
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood

-- 
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: What is the reason Lisp code is not written with closing parenthesis on new lines?

[Joop Kiefte]

Actually, to be honest the short C++ example with lisp bracket style I
find a lot easier to read: I don't need to scan all the page to find
what belongs where...

2010/8/18 Greg :
>> Now the question you're asking is, why don't lispers write
>>  (MyFactory somearg
>>  )
>> which makes me cringe.
>
> That's not at all what's being suggested -- you'll find that both in the OP's 
> code and in the link below, there are many locations where closing 
> parenthesis are ended on the same line.
>
> Trailing parens are placed only for certain blocks that traditionally would 
> define a "scope" in another language, and this is convenient for many 
> reasons, including generic reasons not attached to any specific language. 
> It's not about carrying over "much loved C style" to Lisp, but to make actual 
> use of parenthesis for the purpose of clearly outlining the structure of your 
> code.
>
> Again, the link goes much more into depth on this.
>
> Attached is a screenshot of some code from the wonderful Incanter library. I 
> think it's a great illustration of how confusing stacking parenthesis can be 
> (there are many functions in there that are like this).
>
> The readability issue occurs when there's a drop in several indentation 
> levels after many lines.  This is a problem regardless of what the 
> indentation width is, but is certainly made worse by a small indentation 
> width.
>
> - Greg
>
>
>
> On Aug 18, 2010, at 1:17 PM, Tim Daly wrote:
>
>> A more serious answer is that when I code in Java I use the
>> brace-on-a-line kind of indentation. When I code in Lisp I
>> never write single-line parens of any kind.
>>
>> I find that I think differently in each language.
>>
>> My Java code is always a pile of declare-this, do-this, do-this, return
>> Thus I find that I'm delimiting the scope of my variables, marking my
>> control flow and branching logic, try/catch logic, class boundaries, etc.
>>
>> My Lisp code mixes control flow and data structures in the same syntax.
>> Thus the idea that parens are some kind of control flow delimiter is
>> not particularly meaningful.
>>
>> To see the alternative case, take a Java program, find every function call
>> such as:
>>   MyFactory(somearg);
>> throw away the ';', and move the paren left to get:
>>  (MyFactory somearg)
>>
>> Now the question you're asking is, why don't lispers write
>>  (MyFactory somearg
>>  )
>> which makes me cringe.
>>
>> A second reason is that Lisp allows you to think things that Java
>> does not. Java has this imperative, object-oriented, hierarchical
>> style of writing. My lisp code sytle varies to fit the problem.
>> Sometimes it is imperative, sometimes functional, sometimes OO,
>> sometimes snobol-like pattern matching, sometimes class-based.
>> Occasionally I dynamically construct the code and execute it inline.
>> Or I use macros to create my own problem language and code in that.
>> And I create my data structures "on the fly" inline to the code.
>>
>> Once you really internalize lisp there are no real constraints
>> on what you think or write. Thus there is no question of "bracing
>> style" that is meaningful.
>>
>> The whole idea of "bracing style" is Java-think. Your language
>> choice has given you an OO-procedural mindset. So when you reach
>> for Lisp you want to see what you have come to expect. People who
>> work with bricks (Java) tend to wonder why they don't find bricks
>> among people who work with modelling clay (Lisp). The answer isn't
>> in the material, it is in your mindset.
>>
>> Just by looking at lisp code I can tell what your native language
>> is. Fortran programmers simulate COMMON blocks, C programmers use
>> things as pointers, etc. "You can write Fortran in any language"
>> is a famous quote but "you can't write Lisp in any language". And
>> you can quote me on that. (But only in my obituary :-) )
>>
>> In fact, I think that this is going to be the hardest barrier
>> to the adoption of Clojure. "Real Java Programmers" are not going
>> to like the bracing style (or lack thereof) in Clojure.
>>
>> Tim Daly
>>
>> Greg wrote:
>>> It's almost purely community convention that has been adopted from Lisp.
>>>
>>> You may be interested in this link:
>>>
>>> http://gregslepak.posterous.com/on-lisps-readability
>>>
>>> There is much discussion about this topic there.
>>>
>>> Cheers,
>>> Greg
>>>
>>> On Aug 18, 2010, at 2:09 AM, michele wrote:
>>>
>>>
 Wouldn't that make it easier to keep track of them.

 Example:

 (defn myfn-a [a b]
 (if (zero? b)
   a
   (recur
     (afn (bfn (...)) a)
     (dec b

 (defn myfn-b [a b]
 (if (zero? b)
   a
   (recur
     (afn (bfn (...)) a)
     (dec b)
   )
 )
 )

 --
 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 b

Re: What is the reason Lisp code is not written with closing parenthesis on new lines?

[Phil Hagelberg]

On Wed, Aug 18, 2010 at 1:36 PM, Greg  wrote:
> Attached is a screenshot of some code from the wonderful Incanter library. I 
> think it's a great illustration of how confusing stacking parenthesis can be 
> (there are many functions in there that are like this).

Again, that's quite a straw man--the attached code uses tabs for
indentation, (ick!) and you're viewing it with a different tab-stop
setting. It's also several times longer than reasonable.

-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

Re: cool compiler-project?

[.Bill Smith]

While I think Clojure is an impressive achievement, I would not have
thought that the Clojure compiler  (or Lisp compilers in general)
would be interesting for a post-grad student to work on.  After all,
Lisps are known for their simple syntax and grammar, and Clojure
compiles to Java byte codes, so presumably the Clojure compiler does
not include an optimizer.

Bill Smith
Austin, Texas

On Aug 18, 7:35 am, Sreeraj a  wrote:
> Hi,
> I am a post-grad student looking for a cool compiler - project to do.
> I am getting comfortable with clojure and would really like to help
>
> Ideas anyone?
> or, Is there a to-do list where can i start?
>
> Cheers
> Sreeraj

-- 
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: What is the reason Lisp code is not written with closing parenthesis on new lines?

[Greg]

I should qualify my response though to say that I am not advocating that 
everyone switch their preferred style of code.

Just simply giving reasons for why some prefer one style over another. It's a 
personal thing, and I do not wish to engage in a flame war over it.

Best,
Greg

On Aug 18, 2010, at 1:36 PM, Greg wrote:

>> Now the question you're asking is, why don't lispers write
>> (MyFactory somearg
>> )
>> which makes me cringe.
> 
> That's not at all what's being suggested -- you'll find that both in the OP's 
> code and in the link below, there are many locations where closing 
> parenthesis are ended on the same line.
> 
> Trailing parens are placed only for certain blocks that traditionally would 
> define a "scope" in another language, and this is convenient for many 
> reasons, including generic reasons not attached to any specific language. 
> It's not about carrying over "much loved C style" to Lisp, but to make actual 
> use of parenthesis for the purpose of clearly outlining the structure of your 
> code.
> 
> Again, the link goes much more into depth on this.
> 
> Attached is a screenshot of some code from the wonderful Incanter library. I 
> think it's a great illustration of how confusing stacking parenthesis can be 
> (there are many functions in there that are like this).
> 
> The readability issue occurs when there's a drop in several indentation 
> levels after many lines.  This is a problem regardless of what the 
> indentation width is, but is certainly made worse by a small indentation 
> width.
> 
> - Greg
> 
> 
> On Aug 18, 2010, at 1:17 PM, Tim Daly wrote:
> 
>> A more serious answer is that when I code in Java I use the
>> brace-on-a-line kind of indentation. When I code in Lisp I
>> never write single-line parens of any kind.
>> 
>> I find that I think differently in each language.
>> 
>> My Java code is always a pile of declare-this, do-this, do-this, return
>> Thus I find that I'm delimiting the scope of my variables, marking my
>> control flow and branching logic, try/catch logic, class boundaries, etc.
>> 
>> My Lisp code mixes control flow and data structures in the same syntax.
>> Thus the idea that parens are some kind of control flow delimiter is
>> not particularly meaningful.
>> 
>> To see the alternative case, take a Java program, find every function call
>> such as:
>>  MyFactory(somearg);
>> throw away the ';', and move the paren left to get:
>> (MyFactory somearg)
>> 
>> Now the question you're asking is, why don't lispers write
>> (MyFactory somearg
>> )
>> which makes me cringe.
>> 
>> A second reason is that Lisp allows you to think things that Java
>> does not. Java has this imperative, object-oriented, hierarchical
>> style of writing. My lisp code sytle varies to fit the problem.
>> Sometimes it is imperative, sometimes functional, sometimes OO,
>> sometimes snobol-like pattern matching, sometimes class-based.
>> Occasionally I dynamically construct the code and execute it inline.
>> Or I use macros to create my own problem language and code in that.
>> And I create my data structures "on the fly" inline to the code.
>> 
>> Once you really internalize lisp there are no real constraints
>> on what you think or write. Thus there is no question of "bracing
>> style" that is meaningful.
>> 
>> The whole idea of "bracing style" is Java-think. Your language
>> choice has given you an OO-procedural mindset. So when you reach
>> for Lisp you want to see what you have come to expect. People who
>> work with bricks (Java) tend to wonder why they don't find bricks
>> among people who work with modelling clay (Lisp). The answer isn't
>> in the material, it is in your mindset.
>> 
>> Just by looking at lisp code I can tell what your native language
>> is. Fortran programmers simulate COMMON blocks, C programmers use
>> things as pointers, etc. "You can write Fortran in any language"
>> is a famous quote but "you can't write Lisp in any language". And
>> you can quote me on that. (But only in my obituary :-) )
>> 
>> In fact, I think that this is going to be the hardest barrier
>> to the adoption of Clojure. "Real Java Programmers" are not going
>> to like the bracing style (or lack thereof) in Clojure.
>> 
>> Tim Daly
>> 
>> Greg wrote:
>>> It's almost purely community convention that has been adopted from Lisp.
>>> 
>>> You may be interested in this link:
>>> 
>>> http://gregslepak.posterous.com/on-lisps-readability
>>> 
>>> There is much discussion about this topic there.
>>> 
>>> Cheers,
>>> Greg
>>> 
>>> On Aug 18, 2010, at 2:09 AM, michele wrote:
>>> 
>>> 
 Wouldn't that make it easier to keep track of them.
 
 Example:
 
 (defn myfn-a [a b]
 (if (zero? b)
  a
  (recur
(afn (bfn (...)) a)
(dec b
 
 (defn myfn-b [a b]
 (if (zero? b)
  a
  (recur
(afn (bfn (...)) a)
(dec b)
  )
 )
 )
 
 -- 
 You received this message because you are subscribed to the Googl

Re: What is the reason Lisp code is not written with closing parenthesis on new lines?

[Michael Gardner]

On Aug 18, 2010, at 2:49 PM, Greg wrote:

> On Aug 18, 2010, at 12:07 PM, Michael Gardner wrote:
> 
>> On Aug 18, 2010, at 1:38 PM, Greg wrote:
>> 
>>> http://gregslepak.posterous.com/on-lisps-readability
>> 
>> That article is dishonest.
> 
> Speaking as the author, I'm a bit offended.

Too bad. If you wanted to focus on the trailing-parens (which you clearly did 
in that article), you should have kept everything else the same between your 
examples.

If you wanted to comment on indentation as well, you should have (a) given it 
equal prominence in your discussion, (b) used separate code examples for 
trailing-parens vs indentation, and/or (c) made a separate post.

Closing the comments after people started to question you on this wasn't a good 
move, either (otherwise I'd be commenting there rather than here).

-- 
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: What is the reason Lisp code is not written with closing parenthesis on new lines?

[Tim Daly]

A more serious answer is that when I code in Java I use the
brace-on-a-line kind of indentation. When I code in Lisp I
never write single-line parens of any kind.

I find that I think differently in each language.

My Java code is always a pile of declare-this, do-this, do-this, return
Thus I find that I'm delimiting the scope of my variables, marking my
control flow and branching logic, try/catch logic, class boundaries, etc.

My Lisp code mixes control flow and data structures in the same syntax.
Thus the idea that parens are some kind of control flow delimiter is
not particularly meaningful.

To see the alternative case, take a Java program, find every function call
such as:
   MyFactory(somearg);
throw away the ';', and move the paren left to get:
  (MyFactory somearg)

Now the question you're asking is, why don't lispers write
  (MyFactory somearg
  )
which makes me cringe.

A second reason is that Lisp allows you to think things that Java
does not. Java has this imperative, object-oriented, hierarchical
style of writing. My lisp code sytle varies to fit the problem.
Sometimes it is imperative, sometimes functional, sometimes OO,
sometimes snobol-like pattern matching, sometimes class-based.
Occasionally I dynamically construct the code and execute it inline.
Or I use macros to create my own problem language and code in that.
And I create my data structures "on the fly" inline to the code.

Once you really internalize lisp there are no real constraints
on what you think or write. Thus there is no question of "bracing
style" that is meaningful.

The whole idea of "bracing style" is Java-think. Your language
choice has given you an OO-procedural mindset. So when you reach
for Lisp you want to see what you have come to expect. People who
work with bricks (Java) tend to wonder why they don't find bricks
among people who work with modelling clay (Lisp). The answer isn't
in the material, it is in your mindset.

Just by looking at lisp code I can tell what your native language
is. Fortran programmers simulate COMMON blocks, C programmers use
things as pointers, etc. "You can write Fortran in any language"
is a famous quote but "you can't write Lisp in any language". And
you can quote me on that. (But only in my obituary :-) )

In fact, I think that this is going to be the hardest barrier
to the adoption of Clojure. "Real Java Programmers" are not going
to like the bracing style (or lack thereof) in Clojure.

Tim Daly

Greg wrote:

It's almost purely community convention that has been adopted from Lisp.

You may be interested in this link:

http://gregslepak.posterous.com/on-lisps-readability

There is much discussion about this topic there.

Cheers,
Greg

On Aug 18, 2010, at 2:09 AM, michele wrote:

  

Wouldn't that make it easier to keep track of them.

Example:

(defn myfn-a [a b]
 (if (zero? b)
   a
   (recur
 (afn (bfn (...)) a)
 (dec b

(defn myfn-b [a b]
 (if (zero? b)
   a
   (recur
 (afn (bfn (...)) a)
 (dec b)
   )
 )
)

--
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



  


--
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: Today's clojure trick question

[Armando Blancas]

I don't see what the concern may be. Can you elaborate?

On Aug 18, 10:04 am, Matt Fowles  wrote:
> All~
>
> Boolean.valueOf() was added in 1.4.  While that seems ancient, some older
> libraries use 'new Boolean()' because they maintain 1.2 compatibility.  It
> seems like Clojure should take more care when it unboxes Booleans...
>
> Matt
>
> On Wed, Aug 18, 2010 at 12:57 PM, Nicolas Oury wrote:
>
>
>
> > I am not an expert. Is it possible on some JDK to put a breakpoint on
> > Boolean constructor and look at the stack?
> > Or you can't put a breakpoint on standard library?
>
> > --
> > 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- Hide quoted text -
>
> - Show quoted text -

-- 
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: What is the reason Lisp code is not written with closing parenthesis on new lines?

[Meikel Brandmeyer]

Hi,

Am 18.08.2010 um 11:09 schrieb michele:

> (defn myfn-a [a b]
>  (if (zero? b)
>a
>(recur
>  (afn (bfn (...)) a)
>  (dec b
> 
> (defn myfn-b [a b]
>  (if (zero? b)
>a
>(recur
>  (afn (bfn (...)) a)
>  (dec b)
>)
>  )
> )

I find it interesting, that people find the latter easier to read. In 
particular because the closing parens are now much farther away from their 
opening counterparts. For me, this is much harder to align. As others already 
said: I go mostly by indentation. When the auto-indentation is not what I 
expect, I did something wrong. I think in the end, it's the combination of 
auto-indentation, paren-match when editing, rainbow parens and small functions 
(where the number of parens stays in a reasonable number) that does the trick 
for me. Lisp syntax really isn't around the parens. But you can waste a lot of 
time, discussing where to place them. Just as much as you can waste time on the 
placement of {} in C. We should move on.

Sincerely
Meikel

-- 
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: What is the reason Lisp code is not written with closing parenthesis on new lines?

[Greg]

On Aug 18, 2010, at 12:07 PM, Michael Gardner wrote:

> On Aug 18, 2010, at 1:38 PM, Greg wrote:
> 
>> http://gregslepak.posterous.com/on-lisps-readability
> 
> That article is dishonest.

Speaking as the author, I'm a bit offended.

Yes, the indentation width was changed, and this was acknowledged both in the 
post and in the comments, but you seem to conveniently ignore everything else 
that was said.

Increasing the default indentation width does improve readability, but 
readability is still further improved by trailing parens, for the multitude of 
reasons the article mentions.

- Greg

> The author changes indentation widths between examples, while focusing 
> entirely on the trailing-parens. He claims in a comment that "the post is not 
> solely about trailing parenthesis", but there's only one passing remark about 
> 2-space indentation in the whole article. (I personally use 4-space indents 
> precisely because they make code easy to parse at a glance.)
> 
> -- 
> 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

-- 
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: What is the reason Lisp code is not written with closing parenthesis on new lines?

[Michael Gardner]

On Aug 18, 2010, at 1:38 PM, Greg wrote:

> http://gregslepak.posterous.com/on-lisps-readability

That article is dishonest. The author changes indentation widths between 
examples, while focusing entirely on the trailing-parens. He claims in a 
comment that "the post is not solely about trailing parenthesis", but there's 
only one passing remark about 2-space indentation in the whole article. (I 
personally use 4-space indents precisely because they make code easy to parse 
at a glance.)

-- 
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: Today's clojure trick question

[Matt Fowles]

All~

Boolean.valueOf() was added in 1.4.  While that seems ancient, some older
libraries use 'new Boolean()' because they maintain 1.2 compatibility.  It
seems like Clojure should take more care when it unboxes Booleans...

Matt

On Wed, Aug 18, 2010 at 12:57 PM, Nicolas Oury wrote:

> I am not an expert. Is it possible on some JDK to put a breakpoint on
> Boolean constructor and look at the stack?
> Or you can't put a breakpoint on standard library?
>
> --
> 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
>

-- 
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: What is the reason Lisp code is not written with closing parenthesis on new lines?

[Alan]

The indentation is enough of a hint to get it right. For example, in
myfn-a, because you've indented it correctly I can easily tell that
(dec b) is the second argument to recur, without looking at the
parentheses at all. Isolating close-parens would probably help a
little with this task, but the loss of screen real estate would far
outweigh the gains.

Without the indentation to help, indeed we would be lost in a sea of
parens and it might be necessary to put one on each line; but as Phil
points out, computers are better at that than we are, so we can leave
the parentheses as an "implementation detail" and work on top of the
indentation-based abstraction emacs (or whatever IDE) offers us.

On Aug 18, 2:09 am, michele  wrote:
> Wouldn't that make it easier to keep track of them.
>
> Example:
>
> (defn myfn-a [a b]
>   (if (zero? b)
>     a
>     (recur
>       (afn (bfn (...)) a)
>       (dec b
>
> (defn myfn-b [a b]
>   (if (zero? b)
>     a
>     (recur
>       (afn (bfn (...)) a)
>       (dec b)
>     )
>   )
> )

-- 
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

ANN: SQLRat - A Clojure 1.2 library to access Relational Databases using DataTypes

[Shantanu Kumar]

Hi,

I have uploaded source code (Apache 2 license) for SQLRat - a library
for Clojure 1.2 to access relational databases using DataTypes
(entities). It also lets you define relations between entities and
navigate them. While this is a part of what typically Object-
Relational Mapping (ORM) frameworks do, it is not an ORM framework per
se -- it does not implement State managent, Identity management, Lazy
loading, Eager fetching etc. The code is quite rough around the edges
right now and beta-quality at best (at 0.1-SNAPSHOT), but it works
nevertheless. I intend to release it as GA soon after Clojure 1.2 goes
GA too.

The source code is here: http://bitbucket.org/kumarshantanu/sqlrat/

Discussions can be posted here: http://groups.google.com/group/bitumenframework

You may also like to keep a tab at this: 
http://code.google.com/p/bitumenframework/

The intent of this announcement is to gather feedback, so that I can
fix as many warts as I can before doing a 0.1 GA release. It is not on
Clojars yet, but the GA will eventually be there. The most important
parts to review would be the API it exposes, followed by the
implementation details. So, I would request you to give the library a
try, ask questions (I would be happy to answer), give feedback, make
suggestions and if you can, fork and contribute as well.

The usage can be found in the dbblog.clj file, which contains the unit
tests and describes how the library can be used.

Regards,
Shantanu

-- 
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: What is the reason Lisp code is not written with closing parenthesis on new lines?

[Greg]

It's almost purely community convention that has been adopted from Lisp.

You may be interested in this link:

http://gregslepak.posterous.com/on-lisps-readability

There is much discussion about this topic there.

Cheers,
Greg

On Aug 18, 2010, at 2:09 AM, michele wrote:

> Wouldn't that make it easier to keep track of them.
> 
> Example:
> 
> (defn myfn-a [a b]
>  (if (zero? b)
>a
>(recur
>  (afn (bfn (...)) a)
>  (dec b
> 
> (defn myfn-b [a b]
>  (if (zero? b)
>a
>(recur
>  (afn (bfn (...)) a)
>  (dec b)
>)
>  )
> )
> 
> -- 
> 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

-- 
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: What is the reason Lisp code is not written with closing parenthesis on new lines?

[Tim Daly]

Three reasons.

First, "code density", that is the number of
(/ number-of-lines-of-code number-of-lines-on-screen) should
approach 1 so that every line on the screen is code.

Second, real editors paren-bounce to show matching parens.

Third, "real lispers" don't exit the thought process until the
s-expression is complete :-)

Tim Daly

michele wrote:

Wouldn't that make it easier to keep track of them.

Example:

(defn myfn-a [a b]
  (if (zero? b)
a
(recur
  (afn (bfn (...)) a)
  (dec b

(defn myfn-b [a b]
  (if (zero? b)
a
(recur
  (afn (bfn (...)) a)
  (dec b)
)
  )
)

  


--
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: What is the reason Lisp code is not written with closing parenthesis on new lines?

[Daniel E. Renfer]

On 8/18/10 1:32 PM, Brian Goslinga wrote:
> Putting them on separate lines put the focus on the wrong element of
> the code.  You do not want to be focusing on the parentheses, you want
> to be focusing on the structure of the code.  The idiomatic lisp
> formatting style uses indentation to reveal the large scale structure
> of the code, and so the parentheses can be neatly tucked away.  With a
> little experience, the parentheses will start to fade from view.
> 
> Additionally, putting them on separate lines waste vertical space, and
> you should be using an editor that supports paren matching so you
> don't need to count them.
> 

Generally, when I am working on a function, I will put the closing
parens anywhere with a ton of whitespace all around. Once I'm done with
the function, I make sure to delete all of the excess breaks so that
it's a nice neat block of code.

Using paredit in emacs makes it really easy to handle the closing
parens. I'm sure there are other good tools for the other editors.



signature.asc
Description: OpenPGP digital signature

Re: ANN: Emacs auto-complete plugin for slime users

[MHOOO]

I can get rid of those errors by evaling this in the repl. Does this
work for you as well?:
(do
  (require 'clojure.contrib.with-ns)
  (clojure.contrib.with-ns/with-ns
'swank.commands.basic
(defn- describe-to-string [var]
  {:pre [(var? var)]}
  (with-out-str
(print-doc var)))

(defn- describe-symbol* [symbol-name]
  (with-emacs-package
(let [v (try (ns-resolve (maybe-ns *current-package*) (symbol
symbol-name))
 (catch ClassNotFoundException e
   nil))]
  (if (and v (var? v))
(describe-to-string v)
(str "Unknown symbol " symbol-name)))

On Aug 17, 10:38 am, Stefan Kamphausen  wrote:
> Hi,
>
> just yesterday I took a first look at auto-complete together with your
> slime auto completion sources.
>
> I'm encountering some Exceptions, though,
>
> If I'm in a .clj-buffer and start typing
>
>   (clojure.
>
> and then wait for the auto completion to popup I see a list of
> possible completions like, e.g., clojure.set, clojure.xml and more,
> and then an Exception pops up:
>
> clojure.set
>   [Thrown class java.lang.ClassNotFoundException]
>
> Restarts:
>  0: [QUIT] Quit to the SLIME top level
>  1: [ABORT] ABORT to SLIME level 0
>
> Backtrace:
>   0: java.net.URLClassLoader$1.run(URLClassLoader.java:202)
>   1: java.security.AccessController.doPrivileged(Native Method)
>   2: java.net.URLClassLoader.findClass(URLClassLoader.java:190)
>   3: clojure.lang.DynamicClassLoader.findClass(DynamicClassLoader.java:
> 58)
>   4: java.lang.ClassLoader.loadClass(ClassLoader.java:307)
>   5: java.lang.ClassLoader.loadClass(ClassLoader.java:248)
>   6: java.lang.Class.forName0(Native Method)
>   7: java.lang.Class.forName(Class.java:247)
>   8: clojure.lang.RT.classForName(RT.java:1566)
>   9: clojure.lang.Compiler.maybeResolveIn(Compiler.java:5700)
>  10: clojure.core$ns_resolve.invoke(core.clj:3380)
>  11: swank.commands.basic$describe_symbol_STAR_.invoke(basic.clj:184)
>  12: swank.commands.basic
> $eval880$documentation_symbol__881.invoke(basic.clj:201)
>  13: clojure.lang.Var.invoke(Var.java:365)
>  14: user$eval1927.invoke(NO_SOURCE_FILE)
>  15: clojure.lang.Compiler.eval(Compiler.java:5424)
>  16: clojure.lang.Compiler.eval(Compiler.java:5391)
>  17: clojure.core$eval.invoke(core.clj:2382)
>  18: swank.core$eval_in_emacs_package.invoke(core.clj:94)
>  19: swank.core$eval_for_emacs.invoke(core.clj:241)
>  20: clojure.lang.Var.invoke(Var.java:373)
>  21: clojure.lang.AFn.applyToHelper(AFn.java:169)
>  22: clojure.lang.Var.applyTo(Var.java:482)
>  23: clojure.core$apply.invoke(core.clj:540)
>  24: swank.core$eval_from_control.invoke(core.clj:101)
>  25: swank.core$sldb_loop$fn__401.invoke(core.clj:203)
>  26: swank.core$sldb_loop.invoke(core.clj:200)
>  27: swank.core$invoke_debugger.invoke(core.clj:216)
>  28: swank.core$sldb_debug.invoke(core.clj:220)
>  29: swank.core$eval_for_emacs.invoke(core.clj:279)
>  30: clojure.lang.Var.invoke(Var.java:373)
>  31: clojure.lang.AFn.applyToHelper(AFn.java:169)
>  32: clojure.lang.Var.applyTo(Var.java:482)
>  33: clojure.core$apply.invoke(core.clj:540)
>  34: swank.core$eval_from_control.invoke(core.clj:101)
>  35: swank.core$spawn_worker_thread$fn__455$fn__456.invoke(core.clj:
> 300)
>  36: clojure.lang.AFn.applyToHelper(AFn.java:159)
>  37: clojure.lang.AFn.applyTo(AFn.java:151)
>  38: clojure.core$apply.invoke(core.clj:540)
>  39: swank.core$spawn_worker_thread$fn__455.doInvoke(core.clj:296)
>  40: clojure.lang.RestFn.invoke(RestFn.java:398)
>  41: clojure.lang.AFn.run(AFn.java:24)
>  42: java.lang.Thread.run(Thread.java:619)
>
> Another one shows up if I hit TAB (bound to indent-for-tab-command)
> before the completion shows up I get a
>
> No message.
>   [Thrown class java.lang.NullPointerException]
>
> Restarts:
>  0: [QUIT] Quit to the SLIME top level
>
> Backtrace:
>   0: clojure.lang.Compiler$FnMethod.parse(Compiler.java:4290)
>   1: clojure.lang.Compiler$FnExpr.parse(Compiler.java:3173)
>   2: clojure.lang.Compiler.analyzeSeq(Compiler.java:5367)
>   3: clojure.lang.Compiler.analyze(Compiler.java:5190)
>   4: clojure.lang.Compiler.analyze(Compiler.java:5151)
>   5: clojure.lang.Compiler$InvokeExpr.parse(Compiler.java:3057)
>   6: clojure.lang.Compiler.analyzeSeq(Compiler.java:5371)
>   7: clojure.lang.Compiler.analyze(Compiler.java:5190)
>   8: clojure.lang.Compiler.analyze(Compiler.java:5151)
>   9: clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:4670)
>  10: clojure.lang.Compiler$FnMethod.parse(Compiler.java:4328)
>  11: clojure.lang.Compiler$FnExpr.parse(Compiler.java:3173)
>  12: clojure.lang.Compiler.analyzeSeq(Compiler.java:5367)
>  13: clojure.lang.Compiler.analyze(Compiler.java:5190)
>  14: clojure.lang.Compiler.eval(Compiler.java:5421)
>  15: clojure.lang.Compiler.eval(Compiler.java:5391)
>  16: clojure.core$eval.invoke(core.clj:2382)
>  17: swank.core$eval_in_emacs_package.invoke(core.clj:94)
>  18: swank.core$eval_for_emacs.invoke(core.cl

Re: defprotocol not working?

[Nicolas Oury]

You can create a new project, even if you don't use it:

lein new experiments

inside it will create a project.clj.

Checks the dependencies look like that:

   :dependencies [[org.clojure/clojure "1.2.0-RC3"]
 [org.clojure/clojure-contrib "1.2.0-RC3"]

Type lein deps in the directory. It will download the latest version of clojure.

lein repl, will open a repl.

You can also have a look to the cljr project
http://github.com/liebke/cljr

It is intended for repl-based project.


Hopes that helps.


On Wed, Aug 18, 2010 at 12:29 PM, Henrik Mohr  wrote:
> updated it to support clojure 1.1, and now when I want a REPL I type
>

-- 
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: Today's clojure trick question

[Sean Corfield]

On Wed, Aug 18, 2010 at 10:28 AM, Shantanu Kumar
 wrote:
> Would suggest to consider this:
>
> (let [ x (true? (new java.lang.Boolean false)) ] (if x "trouble"
> "ok"))

Ah, but that wouldn't work for a new Boolean set to true:

(let [ x (true? (new java.lang.Boolean true)) ] (if x "ok" "trouble"))

Expect "ok"? Nope, you'll get "trouble".
-- 
Sean A Corfield -- (904) 302-SEAN
Railo Technologies, Inc. -- http://getrailo.com/
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood

-- 
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: What is the reason Lisp code is not written with closing parenthesis on new lines?

[Brian Goslinga]

Putting them on separate lines put the focus on the wrong element of
the code.  You do not want to be focusing on the parentheses, you want
to be focusing on the structure of the code.  The idiomatic lisp
formatting style uses indentation to reveal the large scale structure
of the code, and so the parentheses can be neatly tucked away.  With a
little experience, the parentheses will start to fade from view.

Additionally, putting them on separate lines waste vertical space, and
you should be using an editor that supports paren matching so you
don't need to count them.

-- 
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: What is the reason Lisp code is not written with closing parenthesis on new lines?

[Marc Spitzer]

On Wed, Aug 18, 2010 at 1:11 PM, Sean Corfield  wrote:
> On Wed, Aug 18, 2010 at 2:09 AM, michele  wrote:
>> (defn myfn-b [a b]
>>  (if (zero? b)
>>    a
>>    (recur
>>      (afn (bfn (...)) a)
>>      (dec b)
>>    )
>>  )
>> )
>
> I started out trying to do that but it ended up being far more work
> that it was worth - as Phil said, computer programs (IDEs / editors)
> do this much better. If you're using an IDE that auto-closes /
> auto-deletes forms, you really don't need to think about parentheses
> at all.
> --
> Sean A Corfield -- (904) 302-SEAN
> Railo Technologies, Inc. -- http://getrailo.com/
> An Architect's View -- http://corfield.org/
>

Also it adds up, you end up seeing much less code on your screen that way.

marc

-- 
Freedom is nothing but a chance to be better.
--Albert Camus

 The problem with socialism is that eventually you run out
of other people's money.
--Margaret Thatcher

-- 
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: Today's clojure trick question

[Shantanu Kumar]

Would suggest to consider this:

(let [ x (true? (new java.lang.Boolean false)) ] (if x "trouble"
"ok"))

Regards,
Shantanu

On Aug 18, 10:05 pm, Chas Emerick  wrote:
> No, you can put a breakpoint on any class, regardless of where it's
> been loaded from.
>
> In this case, I'd suggest not relying on the line numbers shown in
> source dumps.  At least in my experience, line numbers in the standard
> library source differ from what is shown at runtime.  All three Java
> IDEs allow you to set breakpoints on specific classes and methods,
> irrespective of line number -- doing that will allow you to set the
> right breakpoint, if the line number in Boolean(boolean) happens
> to mismatch whichever source tree you have wired into the IDE.
>
> - Chas
>
> On Aug 18, 12:57 pm, Nicolas Oury  wrote:
>
>
>
>
>
>
>
> > I am not an expert. Is it possible on some JDK to put a breakpoint on
> > Boolean constructor and look at the stack?
> > Or you can't put a breakpoint on standard library?

-- 
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: What is the reason Lisp code is not written with closing parenthesis on new lines?

[Nicolas Oury]

auto-indentation and parens highlighting are better than lines with
only one parens.

At least for me.

There is no law. Do what is best for you.

You might, or not, change your mind when you have more practice with
all those parens.

-- 
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: Clojure Web Programming group?

[Marc Spitzer]

its a good idea, so here it is:


Congratulations: you've successfully created your Google Group, Clojure Web
Development.

Here are the essentials:

* Group name: Clojure Web Development
* Group home page: http://groups.google.com/group/clojure-web-dev
* Group email address clojure-web-...@googlegroups.com

feel free to sign up and all archives will be publicly available

thanks,

marc


On Wed, Aug 18, 2010 at 6:38 AM, Chris Jenkins  wrote:
> Great idea. I'm trying to figure out web development in Clojure atm and a
> group to specifically talk about this area would be great.
>
> On 18 August 2010 11:20, Shantanu Kumar  wrote:
>>
>> +1 Neat idea. Starting a Google group "Clojure web development" might
>> be a solution.
>>
>> Regards,
>> Shantanu
>>
>> On Aug 18, 2:05 am, Rasmus Svensson  wrote:
>> > I think there's a lot of questions that a Clojure programmer faces
>> > when doing web programming, not only regarding how the libraries work,
>> > but also regarding how to design a larger-than-trivial web
>> > applications.
>> >
>> > A mail list would be a very good way to be able to ask for advice or
>> > to be inspired by solutions other people have come up with. I think
>> > there is a lack of articles and blog posts on the web where people
>> > write about the experiences they had during the development of their
>> > web applications. I always get the feeling that what I am struggling
>> > with, some else has already struggled with too and maybe even solved.
>> >
>> > During the time I've done web development, I've been searching for
>> > something like this.
>> >
>> > // Rasmus
>>
>> --
>> 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
>
> --
> 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



-- 
Freedom is nothing but a chance to be better.
--Albert Camus

 The problem with socialism is that eventually you run out
of other people's money.
--Margaret Thatcher

-- 
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: Nil Coalesce

[Nicolas Oury]

I have a solution :

(defn unfold [f & as]
   (if-let [[hd new-as] (apply f as)]
 (lazy-seq
  (cons hd (apply unfold f new-as)))
  ()))


unfold could be called co-reduce or coreduce. It is the dual operation
of reduce, in category theory.
Instead of reducing a seq to create a value, it generates a seq from a
value. (generate is sometimes a name for that, too)
I don't know if it is somewhere in core or contrib.
With this function, it is very simple:
(defn nil-coalesce [s1 s2]
  (unfold #(and %1
 (if (first %1)
[(first %1) [(next %1) %2]]
 [(first %2) [(next %1) (next %2)]])) s1 s2))

-- 
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: What is the reason Lisp code is not written with closing parenthesis on new lines?

[Sean Corfield]

On Wed, Aug 18, 2010 at 2:09 AM, michele  wrote:
> (defn myfn-b [a b]
>  (if (zero? b)
>    a
>    (recur
>      (afn (bfn (...)) a)
>      (dec b)
>    )
>  )
> )

I started out trying to do that but it ended up being far more work
that it was worth - as Phil said, computer programs (IDEs / editors)
do this much better. If you're using an IDE that auto-closes /
auto-deletes forms, you really don't need to think about parentheses
at all.
-- 
Sean A Corfield -- (904) 302-SEAN
Railo Technologies, Inc. -- http://getrailo.com/
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood

-- 
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: Today's clojure trick question

[Chas Emerick]

No, you can put a breakpoint on any class, regardless of where it's
been loaded from.

In this case, I'd suggest not relying on the line numbers shown in
source dumps.  At least in my experience, line numbers in the standard
library source differ from what is shown at runtime.  All three Java
IDEs allow you to set breakpoints on specific classes and methods,
irrespective of line number -- doing that will allow you to set the
right breakpoint, if the line number in Boolean(boolean) happens
to mismatch whichever source tree you have wired into the IDE.

- Chas

On Aug 18, 12:57 pm, Nicolas Oury  wrote:
> I am not an expert. Is it possible on some JDK to put a breakpoint on
> Boolean constructor and look at the stack?
> Or you can't put a breakpoint on standard library?

-- 
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: Today's clojure trick question

[Nicolas Oury]

I am not an expert. Is it possible on some JDK to put a breakpoint on
Boolean constructor and look at the stack?
Or you can't put a breakpoint on standard library?

-- 
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: Today's clojure trick question

[David Nolen]

On Wed, Aug 18, 2010 at 11:58 AM, Brian Hurt  wrote:

> For the record, no where in my code am I deliberately creating Boolean
> objects.  Why the hell would I write (new java.lang.Boolean false) when I
> can just as easily write false?  And I have looked through the code to see
> if something stupid like that did sneak in, and didn't find anything.  So
> this means what is happening is the values are being boxed because of some
> subtle interaction I haven't tracked down yet.  Could it be something to do
> with Java's serialization?  Or maybe the way Clojure boxes boolean values?
> I don't know.  So unless you have some information on what I could be doing
> wrong, simply going "don't do that" does not help.
>
> Brian
>

Boxing has nothing to do with it.

(let [x ((fn [] false))] (if x "trouble" "ok")) ; "ok"

Somewhere new Boolean values are being constructed. Are you using an
external Java library that might be doing 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

Re: Today's clojure trick question

[Andrew Gwozdziewycz]

On Wed, Aug 18, 2010 at 11:09 AM, Brian Hurt  wrote:
> Consider the following bit of code:
>
> (let [ x (new java.lang.Boolean false) ] (if x "trouble" "ok"))

I consider the fact that Boolean has a public constructor a bug. It
can only ever represent 2 values.

However, if you do (let [x (java.lang.Boolean/getBoolean "false")] (if
x :trouble :ok)) you're fine, which obviously isn't helpful in your
situation.

> As you might guess from the fact that I'm calling it's a trick question, the
> above code returns "trouble", not "ok".  From experimentation, it looks like
> clojure's if takes the second branch if the value is nil or referentially
> equal to java.lang.Boolean/FALSE.  If you have a boolean object which is not
> referentially equal to Boolean/FALSE, but still holds the value false, this
> is treated as true by Clojure.
>
> The problem is, I'm not 100% sure if this is a bug or not.  The problem is
> nil-punning.  The if statement can't rely on the test expression evaluating
> to a boolean.  Which means to make this work correctly, if statements would
> have to do an instanceof test (to see if the object was a Boolean), then a
> cast and a call to .booleanValue to get the boolean value.  Which is way
> more expensive than a quick nil test and referential equality test.
>
> This is, however, more than a little bit surprising and depressing.
> Somewhere, in my 10K lines of clojure code, boolean values are getting boxed
> in exactly that way.  I've fixed the current problem (dropping in a call to
> .booleanValue in the test), but having if statements that can fail makes me
> paranoid.
>
> Brian
>
> --
> 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



-- 
http://www.apgwoz.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: Nil Coalesce

[GrumpyLittleTed]

My take is almost identical but I used the same length arguments for
the collections which means that the difference in the if branch are
easier to spot, at the cost of more cryptic argument names. This
version will not blow the stack, and its easy to wrap in lazy-seq.

(defn nil-coalesce [s1 s2]
   (if (seq s1)
 (if (first s1)
   (cons (first s1) (nil-coalesce (rest s1) s2))
   (cons (first s2) (nil-coalesce (rest s1) (rest s2))


On 17 Aug, 15:07, Meikel Brandmeyer  wrote:
> Yeah! Golf!
>
> user=> (defn nil-coalesce
>          [coll replacements]
>          (lazy-seq
>            (when-let [s (seq coll)]
>              (let [fst (first s)]
>                (if (nil? fst)
>                  (cons (first replacements)
>                        (nil-coalesce (rest s) (rest replacements)))
>                  (cons fst (nil-coalesce (rest s) replacements)))
> #'user/nil-coalesce
> user=> (nil-coalesce [nil 1 2 3 nil nil] [4 5])
> (4 1 2 3 5 nil)
>
> Sincerely
> Meikel

-- 
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: What is the reason Lisp code is not written with closing parenthesis on new lines?

[Phil Hagelberg]

On Wed, Aug 18, 2010 at 2:09 AM, michele  wrote:
> Wouldn't that make it easier to keep track of them.

It would make it easier for people to keep track of them. However,
keeping track of parentheses is not something people should be doing
since it's menial, repetitive, error-prone work. Computer programs are
much better at tasks like that.

-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

cool compiler-project?

[Sreeraj a]

Hi,
I am a post-grad student looking for a cool compiler - project to do.
I am getting comfortable with clojure and would really like to help

Ideas anyone?
or, Is there a to-do list where can i start?


Cheers
Sreeraj

-- 
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 not working?

[Henrik Mohr]

Ok, thanks for the answer.

I actually have Leiningen installed, and I've just done a "lein
update" - it's now on 1.2.0 as it says. Is this actually "clojure
1.2.0", or just a stand-alone leiningen version?

But I'm in the progress of just learning, so I don't want to have
projects (yet). Because of that I installed clojure-1.1.jar (and
clojure-contrib) manually, and found a "clj" shell script to run. I
updated it to support clojure 1.1, and now when I want a REPL I type
"clj". When I want to run a script file, I type "clj
scriptfilename.clj".

It's very simple, and pretty much resembles what I know from languages
such as ruby (irb).

Is there any way to use leiningen in this way - using it just for REPL
and running test-scripts with simple command lines, not having to
create projects (yet)?

Thanks in advance!
_henrik



On Aug 17, 3:46 pm, Nicolas Oury  wrote:
> defprotocol is a new feature of Clojure 1.2.
> A fantastic RC3 of this fantastic software is available.
>
> A good way to get it is to use the amazing Leiningen.
>
>
>
> On Tue, Aug 17, 2010 at 7:17 AM, Henrik Mohr  wrote:
> > Hi there!
>
> > I'm a completely new newbie in the clojure sphere - old dog in Java
> > and a handful of other languages.
> > But Clojure is my first (new) functional language, and I'm very
> > excited about it - complements on your word Rich et. al.! :-)
>
> > To learn clojure I've started with the (beta) book "Seven Languages in
> > Seven Weeks" by Bruce Tate (pragprog.com) - great book by the way.
> > He's got a section called "defrecord and protocols" where he's got
> > this example:
>
> > (ns tate.compass)
> > (defprotocol Compass (direction [c]) (left [c]) (right [c]))
>
> > The problem for me is this: When I run the code I get this error
> > message from the "REPL":
> > java.lang.Exception: Unable to resolve symbol: defprotocol in this
> > context (NO_SOURCE_FILE:4)
>
> > I'm using the stable version of clojure 1.1 and clojure contrib 1.1.
> > I'm on OSX 10.6.4 and Apple JDK 1.6.0_20-b02-279-10M3065.
>
> > Please help! I'm stuck, and I don't want to procede (for too long)
> > until I figure out why I get this error ;)
>
> > Thanks in advance.
>
> > Kind regards,
> > Henrik Mohr
>
> > --
> > 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

-- 
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

Wrong package name of record classes

[abhinav sarkar]

Hi,
I noticed that when I define a record (using defrecord) in a namespace
having hyphen in its name (like abc.d-ef) and compile the clj file using
AOT, a class file corresponding to the record defined is created in the
package with the name same as the namespace it is defined in, with hyphen
(in this case abc.d-ef) whereas everything else goes in the package with the
name of the namespace with hyphens replaced by underscore (in this case
abc.d_ef).

This seems like a bug to me. Just wanted to confirm here before reporting.

Cheers,
Abhinav

-- 
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

What is the reason Lisp code is not written with closing parenthesis on new lines?

[michele]

Wouldn't that make it easier to keep track of them.

Example:

(defn myfn-a [a b]
  (if (zero? b)
a
(recur
  (afn (bfn (...)) a)
  (dec b

(defn myfn-b [a b]
  (if (zero? b)
a
(recur
  (afn (bfn (...)) a)
  (dec b)
)
  )
)

-- 
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: Today's clojure trick question

[Brian Hurt]

On Wed, Aug 18, 2010 at 11:34 AM, David Nolen wrote:

> On Wed, Aug 18, 2010 at 11:09 AM, Brian Hurt  wrote:
>
>> This is, however, more than a little bit surprising and depressing.
>> Somewhere, in my 10K lines of clojure code, boolean values are getting boxed
>> in exactly that way.  I've fixed the current problem (dropping in a call to
>> .booleanValue in the test), but having if statements that can fail makes me
>> paranoid.
>>
>> Brian
>>
>> Somewhere in your code you are creating boolean values instead of just
> using Clojure's true and false. Get rid of this code.
>
>
>
For the record, no where in my code am I deliberately creating Boolean
objects.  Why the hell would I write (new java.lang.Boolean false) when I
can just as easily write false?  And I have looked through the code to see
if something stupid like that did sneak in, and didn't find anything.  So
this means what is happening is the values are being boxed because of some
subtle interaction I haven't tracked down yet.  Could it be something to do
with Java's serialization?  Or maybe the way Clojure boxes boolean values?
I don't know.  So unless you have some information on what I could be doing
wrong, simply going "don't do that" does not help.

Brian

-- 
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: accessing a mutable field outside of a deftype

[David Nolen]

On Wed, Aug 18, 2010 at 11:41 AM, Nicolas Oury wrote:

> And is the one that works (for non-mutable fields) reliable or just an
> implementation accident that could change in the future?


I'm assuming it's reliable for 1.2.0.

-- 
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

Multi-field sorting: juxt and sort-by

[luskwater]

This is a helpful hint, and probably one that others are already
using, but seemed good to share.

If you're sorting a list of maps on one field, you can use
(sort-by :community list-of-residents)

But sorting on two (or more) fields seems to require a little more
coding:
(sort-by :community (sort-by :last-name list-of-residents))

or
(sort-by #(vector (:community %) (:last-name %)) list-of-
residents)

But the latter version is equivalent to the terser
(sort-by (juxt :community :last-name) list-of-residents)

The juxt function takes functions as an argument (and this includes
function equivalents like keywords) and returns a function that
generates a vector by applying each function in order.  (Not clear
enough?  Well, from the docstring for juxt:

Takes a set of functions and returns a fn that is the
juxtaposition of those
fns.  The returned fn takes a variable number of args, and returns
a vector
containing the result of applying each fn to the args (left-to-
right).

Anyway, the resulting code for sort-by is terse and clear (even if the
reader is not sure about juxt, the prominent key-fields may give the
correct idea).

Thanks for your patience,
ron

-- 
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: accessing a mutable field outside of a deftype

[Nicolas Oury]

And is the one that works (for non-mutable fields) reliable or just an
implementation accident that could change in the future?

On Wed, Aug 18, 2010 at 4:27 PM, Nicolas Oury  wrote:
> And they need to be in an interface first?
>

-- 
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: Today's clojure trick question

[Chouser]

On Wed, Aug 18, 2010 at 11:09 AM, Brian Hurt  wrote:
> Consider the following bit of code:
>
> (let [ x (new java.lang.Boolean false) ] (if x "trouble" "ok"))

The Javadoc for Boolean has something to say on this subject[1]
as does the following excerpt from Fogus' book The Joy of
Clojure:

Don't create Boolean objects


It is possible to create an object that looks a lot like, but is
not actually, `false`.

Java has left a little landmine for you here, so take a moment to
look at it so that you can step past it gingerly and get on with
your life:

(def evil-false (Boolean. "false")) ; NEVER do this

This creates a new instance of Boolean -- and that's already
wrong!  Since there are only two possible values of Boolean, an
instance of each has already been made for you -- they're named
`true` and `false`.  But here you've gone and done it anyway,
created a new instance of Boolean and stored it in a Var named
`evil-false`.  It looks like false:

evil-false
;=> false

Sometimes it even acts like false:

(= false evil-false)
;=> true

But once it gains your trust, it will show you just how wicked it
is by acting like `true`:

(if evil-false :truthy :falsey)
;=> :truthy

Java's own documentation warns against the creation of this evil
thing, and now you've been warned again.  If you just want to
parse a string, use Boolean's static method instead of its
constructor. This is the right way:

(if (Boolean/valueOf "false") :truthy :falsey)
;=> :falsey

--Chouser
http://joyofclojure.com/

1: 
http://download-llnw.oracle.com/javase/1.5.0/docs/api/java/lang/Boolean.html#Boolean%28boolean%29

-- 
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: Simple question about name-spaces

[Adrian Cuthbertson]

Here's an approach that might work...

; app1.clj
(ns app1)
(defn myinc[x] (inc x))
(defn mydec[x] (dec x))
(defn .)

;app2.clj
(ns app2)
(defn mysq[x] (* x x))

then you have a mylib.clj which is your public "user" module;

(ns mylib)
(require 'app1 'app2)
(defn exports[]
  (refer 'app1 :only '(myinc mydec)) ; for e.g
  (refer 'app2))

Then your users use it as follows;

(require 'mylib)
(mylib/exports)

(myinc 2)
3
(mydec 1)
0
(mysq 2)
4

You could wrap the require/exports in a macro and pass in the ns-symbol.

-Regards, Adrian


On Wed, Aug 18, 2010 at 1:21 PM, Nicolas Oury  wrote:
> If you intern all the ns-public variable of a namespace, they will be
> reexoprted?
>
> Will there be an indirection at runtime or the JVM can sort that out?
>

-- 
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: Today's clojure trick question

[David Nolen]

On Wed, Aug 18, 2010 at 11:09 AM, Brian Hurt  wrote:

> This is, however, more than a little bit surprising and depressing.
> Somewhere, in my 10K lines of clojure code, boolean values are getting boxed
> in exactly that way.  I've fixed the current problem (dropping in a call to
> .booleanValue in the test), but having if statements that can fail makes me
> paranoid.
>
> Brian
>
> Somewhere in your code you are creating boolean values instead of just
using Clojure's true and false. Get rid of this code.

David

-- 
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: accessing a mutable field outside of a deftype

[Nicolas Oury]

And they need to be in an interface first?

-- 
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: Today's clojure trick question

[Nicolas Oury]

(defmacro fat-if)

On Wed, Aug 18, 2010 at 4:09 PM, Brian Hurt  wrote:
> Consider the following bit of code:
>
> (let [ x (new java.lang.Boolean false) ] (if x "trouble" "ok"))
>
> As you might guess from the fact that I'm calling it's a trick question, the
> above code returns "trouble", not "ok".  From experimentation, it looks like
> clojure's if takes the second branch if the value is nil or referentially
> equal to java.lang.Boolean/FALSE.  If you have a boolean object which is not
> referentially equal to Boolean/FALSE, but still holds the value false, this
> is treated as true by Clojure.
>
> The problem is, I'm not 100% sure if this is a bug or not.  The problem is
> nil-punning.  The if statement can't rely on the test expression evaluating
> to a boolean.  Which means to make this work correctly, if statements would
> have to do an instanceof test (to see if the object was a Boolean), then a
> cast and a call to .booleanValue to get the boolean value.  Which is way
> more expensive than a quick nil test and referential equality test.
>
> This is, however, more than a little bit surprising and depressing.
> Somewhere, in my 10K lines of clojure code, boolean values are getting boxed
> in exactly that way.  I've fixed the current problem (dropping in a call to
> .booleanValue in the test), but having if statements that can fail makes me
> paranoid.
>
> Brian
>
> --
> 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

-- 
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

Today's clojure trick question

[Brian Hurt]

Consider the following bit of code:

(let [ x (new java.lang.Boolean false) ] (if x "trouble" "ok"))

As you might guess from the fact that I'm calling it's a trick question, the
above code returns "trouble", not "ok".  From experimentation, it looks like
clojure's if takes the second branch if the value is nil or referentially
equal to java.lang.Boolean/FALSE.  If you have a boolean object which is not
referentially equal to Boolean/FALSE, but still holds the value false, this
is treated as true by Clojure.

The problem is, I'm not 100% sure if this is a bug or not.  The problem is
nil-punning.  The if statement can't rely on the test expression evaluating
to a boolean.  Which means to make this work correctly, if statements would
have to do an instanceof test (to see if the object was a Boolean), then a
cast and a call to .booleanValue to get the boolean value.  Which is way
more expensive than a quick nil test and referential equality test.

This is, however, more than a little bit surprising and depressing.
Somewhere, in my 10K lines of clojure code, boolean values are getting boxed
in exactly that way.  I've fixed the current problem (dropping in a call to
.booleanValue in the test), but having if statements that can fail makes me
paranoid.

Brian

-- 
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: accessing a mutable field outside of a deftype

[David Nolen]

On Wed, Aug 18, 2010 at 10:06 AM, Nicolas Oury wrote:

> This works
>
> (deftype A [a])
>
> (.a (A. 5))
>
> This don't
>
> (deftype A [^{:volatile-mutable true} a])
>
> (.a (A. 5))
>
> Is this normal? Is this a bug?
>
> How could I access the field?
>
> Best,
>
> Nicolas.
>

It's not a bug. You need to define your own setters and getters.

David

-- 
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

accessing a mutable field outside of a deftype

[Nicolas Oury]

This works

(deftype A [a])

(.a (A. 5))

This don't

(deftype A [^{:volatile-mutable true} a])

(.a (A. 5))

Is this normal? Is this a bug?

How could I access the field?

Best,

Nicolas.

-- 
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: ANN: Emacs auto-complete plugin for slime users

[Steve Purcell]

On 18 Aug 2010, at 13:51, MHOOO wrote:

> I'm experiencing the exact same problem. Haven't found a way to fix
> this yet.



I've fixed the problem in my fork of swank-clojure and requested that Phil pull 
the commit into the master repo:

  
http://github.com/purcell/swank-clojure/commit/7172c275f390c59d0b532ec3dc2994b2b9f72167

-Steve



> 
> On 17 Aug., 04:38, Stefan Kamphausen  wrote:
>> Hi,
>> 
>> just yesterday I took a first look at auto-complete together with your
>> slime auto completion sources.
>> 
>> I'm encountering some Exceptions, though,
>> 
>> If I'm in a .clj-buffer and start typing
>> 
>>   (clojure.
>> 
>> and then wait for the auto completion to popup I see a list of
>> possible completions like, e.g., clojure.set, clojure.xml and more,
>> and then an Exception pops up:
>> 
>> clojure.set
>>   [Thrown class java.lang.ClassNotFoundException]
>> 
>> Restarts:
>>  0: [QUIT] Quit to the SLIME top level
>>  1: [ABORT] ABORT to SLIME level 0
>> 
>> Backtrace:
>>   0: java.net.URLClassLoader$1.run(URLClassLoader.java:202)
>>   1: java.security.AccessController.doPrivileged(Native Method)
>>   2: java.net.URLClassLoader.findClass(URLClassLoader.java:190)
>>   3: clojure.lang.DynamicClassLoader.findClass(DynamicClassLoader.java:
>> 58)
>>   4: java.lang.ClassLoader.loadClass(ClassLoader.java:307)
>>   5: java.lang.ClassLoader.loadClass(ClassLoader.java:248)
>>   6: java.lang.Class.forName0(Native Method)
>>   7: java.lang.Class.forName(Class.java:247)
>>   8: clojure.lang.RT.classForName(RT.java:1566)
>>   9: clojure.lang.Compiler.maybeResolveIn(Compiler.java:5700)
>>  10: clojure.core$ns_resolve.invoke(core.clj:3380)
>>  11: swank.commands.basic$describe_symbol_STAR_.invoke(basic.clj:184)
>>  12: swank.commands.basic
>> $eval880$documentation_symbol__881.invoke(basic.clj:201)
>>  13: clojure.lang.Var.invoke(Var.java:365)
>>  14: user$eval1927.invoke(NO_SOURCE_FILE)
>>  15: clojure.lang.Compiler.eval(Compiler.java:5424)
>>  16: clojure.lang.Compiler.eval(Compiler.java:5391)
>>  17: clojure.core$eval.invoke(core.clj:2382)
>>  18: swank.core$eval_in_emacs_package.invoke(core.clj:94)
>>  19: swank.core$eval_for_emacs.invoke(core.clj:241)
>>  20: clojure.lang.Var.invoke(Var.java:373)
>>  21: clojure.lang.AFn.applyToHelper(AFn.java:169)
>>  22: clojure.lang.Var.applyTo(Var.java:482)
>>  23: clojure.core$apply.invoke(core.clj:540)
>>  24: swank.core$eval_from_control.invoke(core.clj:101)
>>  25: swank.core$sldb_loop$fn__401.invoke(core.clj:203)
>>  26: swank.core$sldb_loop.invoke(core.clj:200)
>>  27: swank.core$invoke_debugger.invoke(core.clj:216)
>>  28: swank.core$sldb_debug.invoke(core.clj:220)
>>  29: swank.core$eval_for_emacs.invoke(core.clj:279)
>>  30: clojure.lang.Var.invoke(Var.java:373)
>>  31: clojure.lang.AFn.applyToHelper(AFn.java:169)
>>  32: clojure.lang.Var.applyTo(Var.java:482)
>>  33: clojure.core$apply.invoke(core.clj:540)
>>  34: swank.core$eval_from_control.invoke(core.clj:101)
>>  35: swank.core$spawn_worker_thread$fn__455$fn__456.invoke(core.clj:
>> 300)
>>  36: clojure.lang.AFn.applyToHelper(AFn.java:159)
>>  37: clojure.lang.AFn.applyTo(AFn.java:151)
>>  38: clojure.core$apply.invoke(core.clj:540)
>>  39: swank.core$spawn_worker_thread$fn__455.doInvoke(core.clj:296)
>>  40: clojure.lang.RestFn.invoke(RestFn.java:398)
>>  41: clojure.lang.AFn.run(AFn.java:24)
>>  42: java.lang.Thread.run(Thread.java:619)
>> 
>> Another one shows up if I hit TAB (bound to indent-for-tab-command)
>> before the completion shows up I get a
>> 
>> No message.
>>   [Thrown class java.lang.NullPointerException]
>> 
>> Restarts:
>>  0: [QUIT] Quit to the SLIME top level
>> 
>> Backtrace:
>>   0: clojure.lang.Compiler$FnMethod.parse(Compiler.java:4290)
>>   1: clojure.lang.Compiler$FnExpr.parse(Compiler.java:3173)
>>   2: clojure.lang.Compiler.analyzeSeq(Compiler.java:5367)
>>   3: clojure.lang.Compiler.analyze(Compiler.java:5190)
>>   4: clojure.lang.Compiler.analyze(Compiler.java:5151)
>>   5: clojure.lang.Compiler$InvokeExpr.parse(Compiler.java:3057)
>>   6: clojure.lang.Compiler.analyzeSeq(Compiler.java:5371)
>>   7: clojure.lang.Compiler.analyze(Compiler.java:5190)
>>   8: clojure.lang.Compiler.analyze(Compiler.java:5151)
>>   9: clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:4670)
>>  10: clojure.lang.Compiler$FnMethod.parse(Compiler.java:4328)
>>  11: clojure.lang.Compiler$FnExpr.parse(Compiler.java:3173)
>>  12: clojure.lang.Compiler.analyzeSeq(Compiler.java:5367)
>>  13: clojure.lang.Compiler.analyze(Compiler.java:5190)
>>  14: clojure.lang.Compiler.eval(Compiler.java:5421)
>>  15: clojure.lang.Compiler.eval(Compiler.java:5391)
>>  16: clojure.core$eval.invoke(core.clj:2382)
>>  17: swank.core$eval_in_emacs_package.invoke(core.clj:94)
>>  18: swank.core$eval_for_emacs.invoke(core.clj:241)
>>  19: clojure.lang.Var.invoke(Var.java:373)
>>  20: clojure.lang.AFn.applyToHelper(AFn.java:169)
>>  21: clojure.lang.Var.applyTo(Var.java:482)
>>  22: clojure.core$apply.invoke(core.clj:540)
>>

Re: Nil Coalesce

[Justin Kramer]

On Aug 18, 2:42 am, Michael Wood  wrote:
> "nils replace nils when there are fewer substitutions than nil
> positions" was one of the requirements.
>
> From the first post:
>
> > If nil is encountered in the first sequence and the second sequence is
> > exhaused, nil will be returned:
>
> > e.g.  user> (nil-coalesce (nil 1 2 3 nil nil) (4 5))
> > (4 1 2 3 5 nil)

_Returning_ nil is the requirement, which is what happens in the code
I posted (it behaves the same as other submissions as far as I can
tell). Replacing nil with nil in the result vector isn't necessary for
that to happen.

Justin

-- 
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: ANN: Emacs auto-complete plugin for slime users

[MHOOO]

I'm experiencing the exact same problem. Haven't found a way to fix
this yet.

On 17 Aug., 04:38, Stefan Kamphausen  wrote:
> Hi,
>
> just yesterday I took a first look at auto-complete together with your
> slime auto completion sources.
>
> I'm encountering some Exceptions, though,
>
> If I'm in a .clj-buffer and start typing
>
>   (clojure.
>
> and then wait for the auto completion to popup I see a list of
> possible completions like, e.g., clojure.set, clojure.xml and more,
> and then an Exception pops up:
>
> clojure.set
>   [Thrown class java.lang.ClassNotFoundException]
>
> Restarts:
>  0: [QUIT] Quit to the SLIME top level
>  1: [ABORT] ABORT to SLIME level 0
>
> Backtrace:
>   0: java.net.URLClassLoader$1.run(URLClassLoader.java:202)
>   1: java.security.AccessController.doPrivileged(Native Method)
>   2: java.net.URLClassLoader.findClass(URLClassLoader.java:190)
>   3: clojure.lang.DynamicClassLoader.findClass(DynamicClassLoader.java:
> 58)
>   4: java.lang.ClassLoader.loadClass(ClassLoader.java:307)
>   5: java.lang.ClassLoader.loadClass(ClassLoader.java:248)
>   6: java.lang.Class.forName0(Native Method)
>   7: java.lang.Class.forName(Class.java:247)
>   8: clojure.lang.RT.classForName(RT.java:1566)
>   9: clojure.lang.Compiler.maybeResolveIn(Compiler.java:5700)
>  10: clojure.core$ns_resolve.invoke(core.clj:3380)
>  11: swank.commands.basic$describe_symbol_STAR_.invoke(basic.clj:184)
>  12: swank.commands.basic
> $eval880$documentation_symbol__881.invoke(basic.clj:201)
>  13: clojure.lang.Var.invoke(Var.java:365)
>  14: user$eval1927.invoke(NO_SOURCE_FILE)
>  15: clojure.lang.Compiler.eval(Compiler.java:5424)
>  16: clojure.lang.Compiler.eval(Compiler.java:5391)
>  17: clojure.core$eval.invoke(core.clj:2382)
>  18: swank.core$eval_in_emacs_package.invoke(core.clj:94)
>  19: swank.core$eval_for_emacs.invoke(core.clj:241)
>  20: clojure.lang.Var.invoke(Var.java:373)
>  21: clojure.lang.AFn.applyToHelper(AFn.java:169)
>  22: clojure.lang.Var.applyTo(Var.java:482)
>  23: clojure.core$apply.invoke(core.clj:540)
>  24: swank.core$eval_from_control.invoke(core.clj:101)
>  25: swank.core$sldb_loop$fn__401.invoke(core.clj:203)
>  26: swank.core$sldb_loop.invoke(core.clj:200)
>  27: swank.core$invoke_debugger.invoke(core.clj:216)
>  28: swank.core$sldb_debug.invoke(core.clj:220)
>  29: swank.core$eval_for_emacs.invoke(core.clj:279)
>  30: clojure.lang.Var.invoke(Var.java:373)
>  31: clojure.lang.AFn.applyToHelper(AFn.java:169)
>  32: clojure.lang.Var.applyTo(Var.java:482)
>  33: clojure.core$apply.invoke(core.clj:540)
>  34: swank.core$eval_from_control.invoke(core.clj:101)
>  35: swank.core$spawn_worker_thread$fn__455$fn__456.invoke(core.clj:
> 300)
>  36: clojure.lang.AFn.applyToHelper(AFn.java:159)
>  37: clojure.lang.AFn.applyTo(AFn.java:151)
>  38: clojure.core$apply.invoke(core.clj:540)
>  39: swank.core$spawn_worker_thread$fn__455.doInvoke(core.clj:296)
>  40: clojure.lang.RestFn.invoke(RestFn.java:398)
>  41: clojure.lang.AFn.run(AFn.java:24)
>  42: java.lang.Thread.run(Thread.java:619)
>
> Another one shows up if I hit TAB (bound to indent-for-tab-command)
> before the completion shows up I get a
>
> No message.
>   [Thrown class java.lang.NullPointerException]
>
> Restarts:
>  0: [QUIT] Quit to the SLIME top level
>
> Backtrace:
>   0: clojure.lang.Compiler$FnMethod.parse(Compiler.java:4290)
>   1: clojure.lang.Compiler$FnExpr.parse(Compiler.java:3173)
>   2: clojure.lang.Compiler.analyzeSeq(Compiler.java:5367)
>   3: clojure.lang.Compiler.analyze(Compiler.java:5190)
>   4: clojure.lang.Compiler.analyze(Compiler.java:5151)
>   5: clojure.lang.Compiler$InvokeExpr.parse(Compiler.java:3057)
>   6: clojure.lang.Compiler.analyzeSeq(Compiler.java:5371)
>   7: clojure.lang.Compiler.analyze(Compiler.java:5190)
>   8: clojure.lang.Compiler.analyze(Compiler.java:5151)
>   9: clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:4670)
>  10: clojure.lang.Compiler$FnMethod.parse(Compiler.java:4328)
>  11: clojure.lang.Compiler$FnExpr.parse(Compiler.java:3173)
>  12: clojure.lang.Compiler.analyzeSeq(Compiler.java:5367)
>  13: clojure.lang.Compiler.analyze(Compiler.java:5190)
>  14: clojure.lang.Compiler.eval(Compiler.java:5421)
>  15: clojure.lang.Compiler.eval(Compiler.java:5391)
>  16: clojure.core$eval.invoke(core.clj:2382)
>  17: swank.core$eval_in_emacs_package.invoke(core.clj:94)
>  18: swank.core$eval_for_emacs.invoke(core.clj:241)
>  19: clojure.lang.Var.invoke(Var.java:373)
>  20: clojure.lang.AFn.applyToHelper(AFn.java:169)
>  21: clojure.lang.Var.applyTo(Var.java:482)
>  22: clojure.core$apply.invoke(core.clj:540)
>  23: swank.core$eval_from_control.invoke(core.clj:101)
>  24: swank.core$spawn_worker_thread$fn__455$fn__456.invoke(core.clj:
> 300)
>  25: clojure.lang.AFn.applyToHelper(AFn.java:159)
>  26: clojure.lang.AFn.applyTo(AFn.java:151)
>  27: clojure.core$apply.invoke(core.clj:540)
>  28: swank.core$spawn_worker_thread$fn__455.doInvoke(core.clj:296)
>  29: clojure.lang.RestFn.invoke(Re

Re: Simple question about name-spaces

[Nicolas Oury]

If you intern all the ns-public variable of a namespace, they will be
reexoprted?

Will there be an indirection at runtime or the JVM can sort that out?

-- 
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: Simple question about name-spaces

[Adrian Cuthbertson]

Hi Nicolas,

I've done a bit of manipulation of namespaces for dynamic loading and
executing of functions in a web app context which might give you some
ideas...

Here ns-nm and ipath have been extracted from a url. Then...

(let [ .
  ipath (if (or (nil? ipath) (= ipath "")) "root" ipath)
  ipath (if (.startsWith ipath "/") (.substring ipath 1) ipath)
  ns-sym (symbol ns-nm)
  found-ns (find-ns ns-sym)
  found-ns (if (nil? found-ns)
 (let [n (create-ns ns-sym)]
 (require ns-sym) n)
 found-ns)
  _ (when (nil? found-ns)
(throw (IllegalArgumentException.
(str  "Namespace not found for: " ns-sym
  req-fn (get (ns-publics ns-sym) (symbol ipath)) ]
(req-fn ...

So, the requisite functions you can use are;
create-ns
require
ns-publics

and you can role your own :).

-Hope that helps a bit, Adrian.




On Wed, Aug 18, 2010 at 12:24 PM, Nicolas Oury  wrote:
> That helps a lot. Thank you very much.
>
> That is not very nice though. I quite would like a :reexport option to use.
>
> Best,
>
> Nicolas.
>
>
> On Wed, Aug 18, 2010 at 11:17 AM, Meikel Brandmeyer  wrote:
>> There is no standard way of doing that. There is immigrate of an old
>> Compojure version, which is a hack at best. If all functions should
>> end up in one namespace anyway, you can have a master file, which
>> basically loads the other files.
>>
>> my/name/space.clj:
>>
>> (ns my.name.space
>>  (:load "a" "b" "c"))
>>
>> my/name/{a,b,c}.clj:
>>
>> (in-ns 'my.name.space)
>>
>> 
>>
>> Hope that helps.
>>
>> Sincerely
>> Meikel
>>
>
> --
> 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

-- 
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: Clojure Web Programming group?

[Chris Jenkins]

Great idea. I'm trying to figure out web development in Clojure atm and a
group to specifically talk about this area would be great.

On 18 August 2010 11:20, Shantanu Kumar  wrote:

> +1 Neat idea. Starting a Google group "Clojure web development" might
> be a solution.
>
> Regards,
> Shantanu
>
> On Aug 18, 2:05 am, Rasmus Svensson  wrote:
> > I think there's a lot of questions that a Clojure programmer faces
> > when doing web programming, not only regarding how the libraries work,
> > but also regarding how to design a larger-than-trivial web
> > applications.
> >
> > A mail list would be a very good way to be able to ask for advice or
> > to be inspired by solutions other people have come up with. I think
> > there is a lack of articles and blog posts on the web where people
> > write about the experiences they had during the development of their
> > web applications. I always get the feeling that what I am struggling
> > with, some else has already struggled with too and maybe even solved.
> >
> > During the time I've done web development, I've been searching for
> > something like this.
> >
> > // Rasmus
>
> --
> 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
>

-- 
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: Simple question about name-spaces

[Nicolas Oury]

That helps a lot. Thank you very much.

That is not very nice though. I quite would like a :reexport option to use.

Best,

Nicolas.


On Wed, Aug 18, 2010 at 11:17 AM, Meikel Brandmeyer  wrote:
> There is no standard way of doing that. There is immigrate of an old
> Compojure version, which is a hack at best. If all functions should
> end up in one namespace anyway, you can have a master file, which
> basically loads the other files.
>
> my/name/space.clj:
>
> (ns my.name.space
>  (:load "a" "b" "c"))
>
> my/name/{a,b,c}.clj:
>
> (in-ns 'my.name.space)
>
> 
>
> Hope that helps.
>
> Sincerely
> Meikel
>

-- 
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: Clojure Web Programming group?

[Shantanu Kumar]

+1 Neat idea. Starting a Google group "Clojure web development" might
be a solution.

Regards,
Shantanu

On Aug 18, 2:05 am, Rasmus Svensson  wrote:
> I think there's a lot of questions that a Clojure programmer faces
> when doing web programming, not only regarding how the libraries work,
> but also regarding how to design a larger-than-trivial web
> applications.
>
> A mail list would be a very good way to be able to ask for advice or
> to be inspired by solutions other people have come up with. I think
> there is a lack of articles and blog posts on the web where people
> write about the experiences they had during the development of their
> web applications. I always get the feeling that what I am struggling
> with, some else has already struggled with too and maybe even solved.
>
> During the time I've done web development, I've been searching for
> something like this.
>
> // Rasmus

-- 
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: Simple question about name-spaces

[Meikel Brandmeyer]

Hi,

On 18 Aug., 11:49, Nicolas Oury  wrote:

> I have a library of multiple namespaces( a b c) that I want to include
> in one namespace lib, so user of
> the library can only use/require lib and have access to all the
> functions i a, b and c.
>
> What is the standard way to do that?

There is no standard way of doing that. There is immigrate of an old
Compojure version, which is a hack at best. If all functions should
end up in one namespace anyway, you can have a master file, which
basically loads the other files.

my/name/space.clj:

(ns my.name.space
  (:load "a" "b" "c"))

my/name/{a,b,c}.clj:

(in-ns 'my.name.space)



Hope that helps.

Sincerely
Meikel

-- 
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

Simple question about name-spaces

[Nicolas Oury]

Dear all,

I have a simple problem I can't manage to solve.

I have a library of multiple namespaces( a b c) that I want to include
in one namespace lib, so user of
the library can only use/require lib and have access to all the
functions i a, b and c.

What is the standard way to do that?

Best,

Nicolas.

-- 
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: multiline strings and multiline comments ?

[Zmitro Lapcjonak]

On Aug 17, 12:14 am, Lee Spector  wrote:
> On Aug 16, 2010, at 4:13 PM, Meikel Brandmeyer wrote:
>
> > Every descent editor should provide a comment-selected-text functionality.

> I've worked in several editors that have comment-selected-text, but I don't 
> see it in Eclipse/Counterclockwise

I've created issue: "comment multiple lines by pressing Ctrl+/"
http://code.google.com/p/counterclockwise/issues/detail?id=61

Still under development.

--
Zmi La

-- 
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: ANN: Emacs auto-complete plugin for slime users

[Steve Purcell]

On 17 Aug 2010, at 21:21, Steve Molitor wrote:

> Sorry my message got truncated.  Let's try again:
> 
> Fuzzy completion (ac-source-slime-fuzzy) isn't working for me.  It complains 
> that the function slime-fuzzy-completions is not defined.  I'm using slime.el 
> version 2010404, which does not define that function, although it does define 
> slime-simple-completions.  Not sure if there's a newer version of slime.el 
> out there but I did install fresh about a week or two ago.
> 
> Not to worry; I'm very happy with ac-source-slime-simple.


To use fuzzy completions you need to have and require slime-fuzzy.el, which 
comes with the full slime, but not with the version in ELPA.

-Steve

-- 
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: Program design

[Mark Engelberg]

I think the easiest way to port OO code would be to use Clojure's
multimethods, dispatching on the type of the first argument.

-- 
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

Program design

[prishvin]

Dear Friends,

I am thinking about porting my existing program to clojure. Is there
any way of designing equivalents to classes with simple inheritance?
For e.g. if I have base class fruit and derived classes apple and
orange. The OOP design gives me a possibility to handle those object
in the same way.

Thank you in advance.

-- 
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