Re: Call for masters thesis ideas (possibly related to Clojure)
What about adding circular dependency resolution to the compiler between Clojure -> Java code ? I know, I know - it's not very sexy but it would go a long way for companies with larger legacy Java code bases that may be considering moving to Clojure. Being able to replace Java code 'one step at a time' would be invaluable in that area and it also makes Clojure easier to 'sell'. On Dec 18, 4:35 am, Patrick Kristiansen wrote: > Hi > > We're two students that have been working with concurrent programming > languages (Erlang and Clojure), and while both languages are very > interesting, we would like to work on something related to Clojure in > our masters thesis. > > I once asked on #clojure for ideas, and Rich Hickey suggested looking > into predicate dispatch and it is one idea that we are considering. We > have also considered working on distributed Clojure, but I don't know > if there is already an effort going on in that regard? > > Do you have any other suggestions? We'd be really thankful for any > suggestions. > > Thanks in advance. > > -Patrick -- 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: Advice for someone coming from an OO world?
If you could share more detail, the end result of helping you could be interesting : both versions (OOP & clojure) of a same program. 2009/12/18 IslandRick > Up until a month ago, my total Lisp experience consisted of hacking > my .emacs file to bend it to my will -- a lot. Discovering Clojure > was amazing. I immediately liked several aspects of it, especially > how compact it feels and easy it is to do complex functional tasks. > > I decided the best way to get to know Clojure is to write something in > it. So I've been doing a stock-market backtesting simulator with > Clojure in my nights & weekends. There's just one problem: I think > I'm tainted by too much exposure to OO. > > I often find my self going upstream, against the language. I want to > have an object and send it a message or invoke it, rather than > invoking a function in some package and happening to pass it the right > type of thing. An object-oriented model "feels" more natural to me, > and when I try to express that design in Clojure, I wind up doing a > lot of awkward-feeling things involving watchers and agents. > > As an experiment, I switched over to Ruby, and within 2 hours I had a > basic scaffolding up and running. Now I know being new to Clojure > means I shouldn't expect miracles, and I don't -- but it did feel like > I'm missing something. Either too many years of OO have poisoned my > brain, or I'm just using the wrong tool for the job. > > Can anyone here offer some advice to those who are too ingrained in > using an object-oriented hammer on every nail they see? I know Rich > and Stuart have some good design examples around (I've read many), but > if there are any tutorials that show how to re-envision OO problems in > an FP world, I'd love to see them. > > Thanks for the great & lively community, > Rick in Bainbridge Island, WA > > -- > 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: Parenthesis Inference
It seems that noone has brought up the amazing paredit mode for emacs which gives you keyboard commands for s-expression structure manipulation. It also makes sure you never get your close parenthesis wrong. I use it and can't imagine writing any medium+-complexity code without it. On Dec 19, 2009 6:11 AM, "ajay gopalakrishnan" wrote: Hi, I've a different take on the entire thing. Based on my experience I have realized the following: 1. A lot of software engineers do not have a CS background. Out of them, many joined this field for the fun of coding and are willing to learn new things. I know many like that. However, I feel a large majority of them are those for whom Java is probably what Software development basically is. (This has been a boon and bane of Computer Science. It reduces the barrier to entry, but also prevents them from appreciating the true beauty. Many can code a web application, thanks to Rails, Hibernate and the like without even having an idea of what B-tree is) Everything begins and ends with Java. They don't even know anything about C/C++. And I think it would be foolish to assume that Clojure acceptance will reach critical mass unless it is accepted by this group of people. 2. Second issue is Bosses (higher-ups) and convincing them is hard. Language features and the beauty of Lisp is not going to convince them. The biggest problem is I think when they realize that they will have to loose all the Imperative programming skills they have acquired all over these years and now they will be on equal footing with the rest when it comes to Functional programming experience. 3. Sad as it is, most of the work gets done by Copy-paste work and unless there is a online cookbook type thing, people will find it hard. Unless Clojure (not just Clojure, any functional programming language) reduces this barrier to entry for both the non-core developers and the Bosses, I think any FP language will find it hard. Now, if we want Clojure to get accepted fast, I think we must be eager to reduce this barrier to entry. Just saying that "If you can program in LISP" then you can code Clojure is not a very smart answer. Similarly saying "get used to parenthesis" is not a smart answer either. *It's really wrong to think that if they do not accept Clojure they are doomed. The users have a higher hand and if not Clojure, new languages will keep on being built until some language gets accepted by all. * I think what needs to be done is the following: 1. In LISP like languages, Parenthesis is a non-issue as long as code is properly indented. And hence *strictly following indenting rules* while defining functions/Macros etc. is really really crucial. Hence my next point. 2. Excellent IDE indenting support for code Indentation. I have tried Enclojure and it is good. But what I find is difficult for the LISP newbie is deciding when to put code on the new line for function arguments and all that. I know that there are rules for that (most Scheme like), but frankly speaking, people have become very lazy and wouldn't waste time reading the indenting rules, especially when the other Haskell,F#, Scala camp boasts to address the same issues and say that we do it all without a lot of parenthesis. *So in short, Can we do something in the IDE to make Clojure code indentation a totally no-brainer?* Perhaps Enclojure must show some *placeholders* properly indented based on whether it is defmacro, defn or fn etc and the developer just fills it up. This would be an excellent aid in promoting LISP indenting standards. Overtime, once Clojure is widespread people will automatically start doing it correctly. 3. A nice and good article written by Clojure folks that highlights how to transition from the OOPS thinking to Functional thinking. 1. Just saying "Practice coding recursively" does not help at all. Even core CS people do not use recursion for every thing these days. Students have OS labs, Networking Labs and projects but everyone knows that it does not involve much of recursion and all - just a plain sequence of operations, that's all. At most 2-3 courses on Algorithms is where they use Recursion heavily. 2. I think the keyword "let" and the pipeline is very understated. "let" is the single most important thing that makes this transition easy. 4. Have an article that has some decent functions in it and each should have an explanation of how an experienced Clojurian/LISPian would read this code mentally. Just write it as a transcript. Or may be a Screen cast. 5. Have a cookbook like article for all common tasks. 6. Explain how idiomatic code looks like in Clojure. I feel experienced Lispers can help in this. It feels very scary when an experienced OOPS developer knowing all idiomatic code in OOPS does not know anything in LISP. I'm afraid
Re: Call for masters thesis ideas (possibly related to Clojure)
How about static analysis? Plenty of interesting problems there. For example: 1. detect incorrect uses of transients (those that would certainly lead to exceptions) and report them during compile-time. 2. related to (1), but different: detect places where the compiler can implicitly convert collections to transients and back, without losing correctness, and use that as a speed-up. 3. soft typing, either to speed up code or to detect incorrect code early. Such things have been done with Scheme. I believe Clojure has certain advantages when working on static analysis: * you can call the reader and macro expander during analysis, which greatly simplifies the language to be analyzed. * the core language is relatively simple * the compiler source is freely available and is written in a relatively high-level language (java and not c), so it (should) be relatively easy to get into. Relatedly, it might be interesting to create formal semantics for Clojure, and interface it with a proof assistant, enabling proofs to be written and checked about the behavior of clojure programs. In that context, one of the opportunities provided by lispiness is that macros can help write the proof, by automatically creating propositions about the code that they return. For example, (dotimes [i n] body) can be modified to attach these propositions to its output, using an appropriate proof language: - i>=0 - i<(the result of) n - the loop terminates if its body terminates That's just scratching the surface. That field is deep and wide, and a complete implementation is probably beyond the scope of a master's theses. Still, parts of it can be done. -- 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: Parenthesis Inference
It's certainly something I would like to add to counterclockwise. If only paredit's code was written in clojure, it could have been more easily reused by enclojure, La Clojure and counterclockwise ! :-( 2009/12/19 Avital Oliver > It seems that noone has brought up the amazing paredit mode for emacs which > gives you keyboard commands for s-expression structure manipulation. It also > makes sure you never get your close parenthesis wrong. I use it and can't > imagine writing any medium+-complexity code without it. > > On Dec 19, 2009 6:11 AM, "ajay gopalakrishnan" wrote: > > Hi, > > I've a different take on the entire thing. Based on my experience I have > realized the following: > >1. A lot of software engineers do not have a CS background. Out of >them, many joined this field for the fun of coding and are willing to learn >new things. I know many like that. However, I feel a large majority of them >are those for whom Java is probably what Software development basically is. >(This has been a boon and bane of Computer Science. It reduces the barrier >to entry, but also prevents them from appreciating the true beauty. Many > can >code a web application, thanks to Rails, Hibernate and the like without > even >having an idea of what B-tree is) Everything begins and ends with Java. > They >don't even know anything about C/C++. >And I think it would be foolish to assume that Clojure acceptance will >reach critical mass unless it is accepted by this group of people. >2. Second issue is Bosses (higher-ups) and convincing them is hard. >Language features and the beauty of Lisp is not going to convince them. The >biggest problem is I think when they realize that they will have to loose >all the Imperative programming skills they have acquired all over these >years and now they will be on equal footing with the rest when it comes to >Functional programming experience. >3. Sad as it is, most of the work gets done by Copy-paste work and >unless there is a online cookbook type thing, people will find it hard. > > Unless Clojure (not just Clojure, any functional programming language) > reduces this barrier to entry for both the non-core developers and the > Bosses, I think any FP language will find it hard. > Now, if we want Clojure to get accepted fast, I think we must be eager to > reduce this barrier to entry. Just saying that "If you can program in LISP" > then you can code Clojure is not a very smart answer. Similarly saying "get > used to parenthesis" is not a smart answer either. > > *It's really wrong to think that if they do not accept Clojure they are > doomed. The users have a higher hand and if not Clojure, new languages will > keep on being built until some language gets accepted by all. * > > I think what needs to be done is the following: > >1. In LISP like languages, Parenthesis is a non-issue as long as code >is properly indented. And hence *strictly following indenting rules*while > defining functions/Macros etc. is really really crucial. Hence my next >point. >2. Excellent IDE indenting support for code Indentation. I have tried >Enclojure and it is good. But what I find is difficult for the LISP newbie >is deciding when to put code on the new line for function arguments and all >that. I know that there are rules for that (most Scheme like), but frankly >speaking, people have become very lazy and wouldn't waste time reading the >indenting rules, especially when the other Haskell,F#, Scala camp boasts to >address the same issues and say that we do it all without a lot of >parenthesis. *So in short, Can we do something in the IDE to make >Clojure code indentation a totally no-brainer?* >Perhaps Enclojure must show some *placeholders* properly indented based >on whether it is defmacro, defn or fn etc and the developer just fills it >up. This would be an excellent aid in promoting LISP indenting standards. >Overtime, once Clojure is widespread people will automatically start >doing it correctly. >3. A nice and good article written by Clojure folks that highlights how >to transition from the OOPS thinking to Functional thinking. > 1. Just saying "Practice coding recursively" does not help at all. > Even core CS people do not use recursion for every thing these days. > Students have OS labs, Networking Labs and projects but everyone knows > that > it does not involve much of recursion and all - just a plain sequence of > operations, that's all. At most 2-3 courses on Algorithms is where they > use > Recursion heavily. > 2. I think the keyword "let" and the pipeline is very understated. > "let" is the single most important thing that makes this transition > easy. >4. Have an article that has some decent functions in it and each should >have an explanation of how an experienced Clojurian/LISP
Re: Parenthesis Inference
Hi, On 18 Dez., 20:07, Martin Coxall wrote: > One of the things that always puts people off of Lisp, as we all know, are > the parentheses. one of the things that always put Lispers off is this same question. I have three arguments to make. Love, reason and trust. * Love. Parentheses are an advantage, you will learn to love them if you start some serious hacking. * Reason. They could have been taken away in more than 50 years of history. Guess what, they are still there. If I came to lisp as a newbie, I would think that there must be some reason. * Trust. Just trust all the people telling you over and over again for ages, just trust all the fine software engineers who kept them in place for a very long time. Stefan -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Call for masters thesis ideas (possibly related to Clojure)
On Dec 19, 1:52 am, ajay gopalakrishnan wrote: > Put > > *Comparative performance evaluation of Java threads for embedded > applications**: Linux thread vs. Green thread Your Google search skills are obviously beyond ours. :) I've found it now. -- 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: Parenthesis Inference
On Dec 18, 8:07 pm, Martin Coxall wrote: > I had this thought at work, when I should have been working, so please bear > with me if it's nonsense. > > One of the things that always puts people off of Lisp, as we all know, are > the parentheses. Now, many ways have been suggested of doing this in other > Lisps, but have never taken off, mainly due to inertia and a fear of > sacrificing homoiconicity. > > However, I love Clojure, and want to see it really take off. And so I want to > see all barriers to that removed. Also, I think the language is young enough > that seemingly-but-not-really radical proposals can still be sneaked in. > > Let's take this example, since I note that Rich Hickey weighed in in the > comments: > > http://www.innoq.com/blog/st/2009/12/clojurelisp_readability.html > > (apply merge-with + > (pmap count-lines > (partition-all *batch-size* > (line-seq (reader filename) > > This little snippet has ten parentheses. And is potentially very unnerving to > a non-lisper. Ten parentheses in four lines seems a lot to most programmers. > > Rich, in the comments, suggests a pipelined style to make the code more > readable: > > (->> (line-seq (reader filename)) > (partition-all *batch-size*) > (pmap count-lines) > (apply merge-with +)) > > I accept that this is more readable because it has less nesting. But it now > has *12* parentheses, more than the original, potentially just as alarming to > the Lispophobes. > > My question is this: why can't we introduce a simple and importantly, > optional 'off-side rule' (much simpler than Haskell's) that allows the reader > to infer many of the parentheses? > > A very simple offside rule could turn the original into: > > apply merge-with + > pmap count-lines > partition-all *batch-size* > line-seq (reader filename) > > With a startling two parentheses and Rich's corrected version into: > > ->> > line-seq (reader filename) > partition-all *batch-size* > pmap count-lines > apply merge-with + > > Also with two. That last example in particular looks splendidly readable. > Almost... monadic. > > The parenthesis inference here is very simple, and could be stated in two > sentences: > > For each line that is not within a vector, and does not have an opening > parenthesis, infer an opening parenthesis at the start of the line. Remember > the level of indentation, and infer a closing parenthesis at the end of the > line *before* the next line whose indentation is the same as or less than the > remembered one. > > My question is: why would such a scheme work/not work, and why would/would > not it be desirable? > > Martin Whitespace-sensitive S-exprs have indeed already been implemented for Clojure. The author's github account seems to have been renamed/ deleted, however: http://209.85.129.132/search?q=cache:-f3Sb3BYidoJ:github.com/onyin/pleajure For my own toy programs, I have seen little use for significant whitespace in Clojure so far. Even though I work with Python professionally and like it's lack of syntactical noise, Clojure's parentheses (and vector brackets, and map braces) tend to communicate the programmer's intent more clearly, especially when code becomes as dense as is possible using Lisps/FP. All of this once the initial hurdle is overcome, of course. Clojure just looks and feels different compared to most mainstream languages, different even compared to the more traditional Lisps. I guess it's mostly a matter of judging a language by its long-term merits instead of initial appearance -- just like with so many other things in life. -- 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
Transient Bug
Hey, I was experimenting with transients, and they don't seem to work for sorted collections: user=> (transient (sorted-map 1 2 3 4)) java.lang.ClassCastException: clojure.lang.PersistentTreeMap cannot be cast to clojure.lang.IEditableCollection (NO_SOURCE_FILE:0) user=> (transient (sorted-set 1 2 3 4)) java.lang.ClassCastException: clojure.lang.PersistentTreeSet cannot be cast to clojure.lang.IEditableCollection (NO_SOURCE_FILE:0) Is this desired behavior? Sean -- 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: Transient Bug
IIRC, you can use transient only with maps and vectors. David On Sat, Dec 19, 2009 at 8:46 AM, Sean Devlin wrote: > Hey, > I was experimenting with transients, and they don't seem to work for > sorted collections: > > user=> (transient (sorted-map 1 2 3 4)) > java.lang.ClassCastException: clojure.lang.PersistentTreeMap cannot be > cast to clojure.lang.IEditableCollection (NO_SOURCE_FILE:0) > > user=> (transient (sorted-set 1 2 3 4)) > java.lang.ClassCastException: clojure.lang.PersistentTreeSet cannot be > cast to clojure.lang.IEditableCollection (NO_SOURCE_FILE:0) > > Is this desired behavior? > > Sean > > -- > 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: Transient Bug
> I was experimenting with transients, and they don't seem to work for
> sorted collections:
>
> user=> (transient (sorted-map 1 2 3 4))
> java.lang.ClassCastException: clojure.lang.PersistentTreeMap cannot be
> cast to clojure.lang.IEditableCollection (NO_SOURCE_FILE:0)
>
> user=> (transient (sorted-set 1 2 3 4))
> java.lang.ClassCastException: clojure.lang.PersistentTreeSet cannot be
> cast to clojure.lang.IEditableCollection (NO_SOURCE_FILE:0)
>
> Is this desired behavior?
>From http://clojure.org/transients :
"Currently only vectors are supported, and note that not all Clojure data
structures can support this feature, but most will. Lists will not, as there is
no benefit to be had."
That appears a bit out of date given these grep results on master:
public class PersistentArrayMap extends APersistentMap implements
IEditableCollection {
public class PersistentHashMap extends APersistentMap implements
IEditableCollection {
public class PersistentVector extends APersistentVector implements
IEditableCollection{
public class PersistentHashSet extends APersistentSet implements
IEditableCollection {
It looks to me like PersistentTreeMap and PersistentTreeSet have just not yet
been extended to support transients.
--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: Parenthesis Inference
Personally, I don't think the problem for non-Lispers is with the number of parentheses so much as with the *depth* of parens-nesting and having to invert the reading order, starting from the deepest s-expr and reading your way back out. I'm still very new to Clojure (basically I have only been paying close attention to it for a few weeks, and have not written any substantial Clojure code yet), and I come from ten years of programming the usual non-Lisp Python/Java/JavaScript/C-style languages. But I can honestly say that reading Clojure code comes very naturally for me now, as long as I'm familiar with all the functions in an expression, and I assure you that it's certainly not that I'm special or particularly bright. Interested programmers are willing to learn different syntaxes - judging from the number of apps, there are probably at least fifty thousand programmers who were willing to look past all the square brackets in Objective-C so that they could write iPhone apps. What I think makes it difficult to approach an S-expression isn't the parentheses, but the fact that you often have to read it in an inverse order, or maintain a mental stack of functions that have been applied so far. For me, this is especially the case when function calls are nested very deeply. I'm not familiar with it, but from your example it appears that the ->> macro lets the code be written in an order which is not inverted. Furthermore, the first example "looks" like it has more parens than the ->> example, even though it actually has fewer, because of its deeper nesting - so it's easier to read through what's happening in the ->> example, without having to maintain a mental stack of what functions have are being applied to the expression. For interested programmers new to Clojure, I would think this is way more useful than reducing the number parentheses. e PS: I use the term "interested programmers" above because I don't think Clojure will ever appeal to a programmer who isn't interested in learning something new. The syntax is the easy part. The hard part is learning a different approach to designing and structuring programs. On Fri, Dec 18, 2009 at 2:07 PM, Martin Coxall wrote: > I had this thought at work, when I should have been working, so please bear > with me if it's nonsense. > > One of the things that always puts people off of Lisp, as we all know, are > the parentheses. Now, many ways have been suggested of doing this in other > Lisps, but have never taken off, mainly due to inertia and a fear of > sacrificing homoiconicity. > > However, I love Clojure, and want to see it really take off. And so I want to > see all barriers to that removed. Also, I think the language is young enough > that seemingly-but-not-really radical proposals can still be sneaked in. > > Let's take this example, since I note that Rich Hickey weighed in in the > comments: > > http://www.innoq.com/blog/st/2009/12/clojurelisp_readability.html > > (apply merge-with + > (pmap count-lines > (partition-all *batch-size* > (line-seq (reader filename) > > This little snippet has ten parentheses. And is potentially very unnerving to > a non-lisper. Ten parentheses in four lines seems a lot to most programmers. > > Rich, in the comments, suggests a pipelined style to make the code more > readable: > > (->> (line-seq (reader filename)) > (partition-all *batch-size*) > (pmap count-lines) > (apply merge-with +)) > > > I accept that this is more readable because it has less nesting. But it now > has *12* parentheses, more than the original, potentially just as alarming to > the Lispophobes. > > My question is this: why can't we introduce a simple and importantly, > optional 'off-side rule' (much simpler than Haskell's) that allows the reader > to infer many of the parentheses? > > A very simple offside rule could turn the original into: > > apply merge-with + > pmap count-lines > partition-all *batch-size* > line-seq (reader filename) > > > With a startling two parentheses and Rich's corrected version into: > > ->> > line-seq (reader filename) > partition-all *batch-size* > pmap count-lines > apply merge-with + > > > Also with two. That last example in particular looks splendidly readable. > Almost... monadic. > > The parenthesis inference here is very simple, and could be stated in two > sentences: > > For each line that is not within a vector, and does not have an opening > parenthesis, infer an opening parenthesis at the start of the line. Remember > the level of indentation, and infer a closing parenthesis at the end of the > line *before* the next line whose indentation is the same as or less than the > remembered one. > > My question is: why would such a scheme work/not work, and why would/would > not it be desirable? > > Martin > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" gro
Re: Transient Bug
Steve,
I've been checking out the Java, and it looks the same to me. I think
this raises a couple issues:
1. Should sorted versions get transient support in 1.1?
2. The docs should be updated to reflect the 1.1 status of
transients.
Sean
On Dec 19, 10:23 am, "Stephen C. Gilardi" wrote:
> > I was experimenting with transients, and they don't seem to work for
> > sorted collections:
>
> > user=> (transient (sorted-map 1 2 3 4))
> > java.lang.ClassCastException: clojure.lang.PersistentTreeMap cannot be
> > cast to clojure.lang.IEditableCollection (NO_SOURCE_FILE:0)
>
> > user=> (transient (sorted-set 1 2 3 4))
> > java.lang.ClassCastException: clojure.lang.PersistentTreeSet cannot be
> > cast to clojure.lang.IEditableCollection (NO_SOURCE_FILE:0)
>
> > Is this desired behavior?
>
> Fromhttp://clojure.org/transients:
>
> "Currently only vectors are supported, and note that not all Clojure data
> structures can support this feature, but most will. Lists will not, as there
> is no benefit to be had."
>
> That appears a bit out of date given these grep results on master:
>
> public class PersistentArrayMap extends APersistentMap implements
> IEditableCollection {
> public class PersistentHashMap extends APersistentMap implements
> IEditableCollection {
> public class PersistentVector extends APersistentVector implements
> IEditableCollection{
> public class PersistentHashSet extends APersistentSet implements
> IEditableCollection {
>
> It looks to me like PersistentTreeMap and PersistentTreeSet have just not yet
> been extended to support transients.
>
> --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: 1.1 changes.txt typo
On Dec 18, 3:03 pm, David Thomas Hume wrote: > From the 1.1 release notes: > > "Futures represent asynchronous computations. They are away to get > code to run in another thread, and obtain the result." > > I know "away" is just a typo for "a way", but be damned if that isn't > the best pun I've seen in a while. > > Apologies if this seems like noise, but it brightened my last pre- > holiday work day, and I wanted to vote for not changing it, apart from > possibly adding a warning not to bank on them. > > -Dave Topically related, there is no mention of future-call in the release notes. Aside from being an implementation detail of future, it seems useful in its own right because it's a function, not a macro, and avoids creating an additional closure if all the developer wants is to asynchronize a function call. -- 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: Call for masters thesis ideas (possibly related to Clojure)
Predicate dispatch would be an interesting topic. The #1 problem with predicate dispatch is method ordering. Predicate dispatch as described in the orignal paper [http://www.cs.washington.edu/homes/mernst/pubs/ dispatching-ecoop98-abstract.html] decides what order to used based on implication between predicates. For example: def foo(x) where x is Animal = A def foo(x) where x is Chicken = B def foo(x) where x is Bird = C If you call foo(new Crow) you want the method with "where x is Bird" to be called. A Crow is not a Chicken, so we can rule out the Chicken method. But a Crow is also an Animal, so how does the dispatch decide that it calls the Bird method and not the Animal method? The answer of the authors of the predicate dispatch paper is that you determine implication between predicates. If x is a Bird, that implies that x is an Animal. So we test if x is a Bird and only after that we consider the Animal method. This is good but unfortunately checking implication between predicates is undecidable. For example if we define this: def bar(n) where 5^n == 5 mod n = A def bar(n) where prime?(n) = B How is the static analysis going to determine that the second predicate implies the first? You can solve this case by requiring the programmer to provide implication information to the compiler, like this: implication prime?(n) => 5^n == 5 mod n As you can see this isn't nice. In my opinion we need a better way to do method ordering. I've been thinking about this and my proposal is to use the definition order in the source code to decide which methods to check first: try methods that are defined last first. def baz(x) where p(x) = A def baz(x) where q(x) = B def baz(x) where r(x) = C We first check for r(x) and if it's true we execute C. If it's false then we check if q(x) is true and execute B. If q(x) is false we check p(x) and execute A. The implementation of this kind of predicate dispatch is trivial. You don't need a complicated implication checker. It's just a simple macro. But the question is whether this simple method ordering rule works in practice. With this order you can do everything that you can do with a class hierarchy (in Java for example). It also subsumes Clojure's hierarchies by using a predicate this is itself a method. I think it's interesting to explore this further to see if this order still works well for more advanced uses of predicate dispatch, and to explore alternative orderings. Some other research ideas: - Functional reactive programming in Clojure. A problem with FRP is that you have to invert dependencies. Instead of specifying for each cause what its effects are, you have to specify for each effects what its possible causes are. Can you solve this? The problem is much easier if you don't try to prevent glitches as other FRP systems do. Is a system without glitch prevention useful, is introducing glitches for removing cause and effect inversion a good trade off? - Type/value inference with abstract interpretation. Can you write an abstact interpretation to infer possible values of a variable? Is this useful in creating a better compiler. Can the information be used to create better editors (intellisense?). - In a statically typed language like Haskell & Scala you can write a generic sum function that sums a list of things. You cannot do this in any dynamic language that I know of. You want sum to work on any list of things that support +. Suppose that numbers support + and strings support + (maybe they shouldn't but bear with me for this example). sum ([1,2]) = 3. sum(["ab","cd"]) = "abcd". Now comes the problem. What is sum([])? For numbers it should be 0, for strings it should be "". In a statically typed language you can use the type of the list to determine which value to return. How can we write a generic sum function in a dynamic language? Jules On Dec 18, 1:35 pm, Patrick Kristiansen wrote: > Hi > > We're two students that have been working with concurrent programming > languages (Erlang and Clojure), and while both languages are very > interesting, we would like to work on something related to Clojure in > our masters thesis. > > I once asked on #clojure for ideas, and Rich Hickey suggested looking > into predicate dispatch and it is one idea that we are considering. We > have also considered working on distributed Clojure, but I don't know > if there is already an effort going on in that regard? > > Do you have any other suggestions? We'd be really thankful for any > suggestions. > > Thanks in advance. > > -Patrick -- 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: Parenthesis Inference
> > > It is proudly a Lisp for people that want to get things done. Any > Java/.NET/Python/Brainfuck/Ruby/Basic/C/C++ (No Perlmongers :)) that > want to get better are welcome. However, there is a way things are > done in the language, driven by the underlying problems reality > imposes on developers. A prospective Clojure developer must accept > that the language does this to help you, not hurt you, and they need > to be open to the ideas. > > That is the intended audience. Clojure may be a new Lisp, but it seems the die hard holier-than-thou attitude of old-school Lipsers is alive and well. Look, there's a reason nobody uses Lisp. And the attitude of "we know best and if you can't see that you're an idiot" is certainly part of it. A prospective Clojure developer "must" not do anything. They will probably take one look at Clojure's seemingly user-hostile syntax, read how unless they immediately embrace parens that they are *not welcome*, click their browser back button and never give another thought to Clojure again. Martin -- 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: Parenthesis Inference
On 19 Dec 2009, at 13:50, Stefan Kamphausen wrote: > Hi, > > On 18 Dez., 20:07, Martin Coxall wrote: >> One of the things that always puts people off of Lisp, as we all know, are >> the parentheses. > > one of the things that always put Lispers off is this same question. > > I have three arguments to make. Love, reason and trust. > > * Love. Parentheses are an advantage, you will learn to love them if > you start some serious hacking. I've seriously hacked in many languages, and have come to rely on the presence of Syntax. If Clojure wants me to seriously believe that syntax is overrated, it had better had a bloody go argument. > * Reason. They could have been taken away in more than 50 years of > history. Guess what, they are still there. Guess what? NOBODY uses Lisp. Because of those parens. > If I came to lisp as a > newbie, I would think that there must be some reason. > * Trust. Just trust all the people telling you over and over again for > ages, just trust all the fine software engineers who kept them in > place for a very long time. I trust the many, many more people that have rejected Lisp for its hostile syntax and delusions of importance than the statistically insignificant minority who have actually stuck with it. Martin -- 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: Call for masters thesis ideas (possibly related to Clojure)
I want to thank you all for your suggestions, the clojure community is really great! On Dec 18, 1:35 pm, Patrick Kristiansen wrote: > Hi > > We're two students that have been working with concurrent programming > languages (Erlang and Clojure), and while both languages are very > interesting, we would like to work on something related to Clojure in > our masters thesis. > > I once asked on #clojure for ideas, and Rich Hickey suggested looking > into predicate dispatch and it is one idea that we are considering. We > have also considered working on distributed Clojure, but I don't know > if there is already an effort going on in that regard? > > Do you have any other suggestions? We'd be really thankful for any > suggestions. > > Thanks in advance. > > -Patrick -- 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: OnLisp: Porting Chapter 19 to Clojure
Thanks! I found this one, it involves a function that does the resolve: (defn -dynlet [bvec body] `(let ~bvec ~body)) (defmacro dynlet [bvec body] `(eval (-dynlet ~bvec ~body))) -- 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: Leiningen in Python
Hi,
I am trying to use lein.py, from above, on Windows (Vista).
It works nicely for some commands (e.g. lein.py compile),
after removing the extra space in two places e.g.
'leiningen-%s-standalone .jar' ->
'leiningen-%s-standalone.jar'
and
'1.1.0-alpha-SNAPSHOT/cloju re-1.1.0-alpha-SNAPSHOT.jar' ->
'1.1.0-alpha-SNAPSHOT/clojure-1.1.0-alpha-SNAPSHOT.jar'
But I still have the following error with the 'lein.py install' and
'lein.py jar' commands:
E:\temp\leiningen\myproject> E:\etc\clojure\Leiningen\lein.py install
Exception in thread "main" java.util.regex.PatternSyntaxException:
Illegal/unsupported escape sequence near index 9
^E:\temp\leiningen\myproject
^ (NO_SOURCE_FILE:0)
at clojure.lang.Compiler.eval(Compiler.java:5274)
at clojure.lang.Compiler.eval(Compiler.java:5226)
...
E:\temp\leiningen\myproject> E:\etc\clojure\Leiningen\lein.py jar
Exception in thread "main" java.util.regex.PatternSyntaxException:
Illegal/unsupported escape sequence near index 9
^E:\temp\leiningen\myproject
^ (NO_SOURCE_FILE:0)
at clojure.lang.Compiler.eval(Compiler.java:5274)
at clojure.lang.Compiler.eval(Compiler.java:5226)
...
I am guessing that this means that the backslash in 'temp\leiningen'
needs to be escaped
somewhere in the python script (lein.py) above.
(I am not clear why the first backslash (in E:\temp) is not reported
as the error (index 4).)
I have tried many guesses (I am not familiar with python (V2.6)).
Can anyone make some suggestions?
Regards,
John.
On Dec 12, 10:31 pm, Rob Wolfe wrote:
> Mike K writes:
> > All,
>
> > I tried to use this script on Windows and it blew up real good! I'm a
> > Clojure, Java, and Leiningen newbie, so perhaps a kind soul can help
> > me out.
>
> > 1. lein self-install "worked". It downloaded leiningen-1.0.0-
> > standalone.jar. However, that contradicts the description at
> >http://zef.me/2470/building-clojure-projects-with-leiningenwhich
> > indicates that self-install should download several jars, including
> > clojure itself. That didn't happen, and it looks like it would never
> > happen according to the python script. Also, I'd rather use one and
> > only one clojure, clojure-contrib, etc. for everything rather than
> > Leiningen using its own. Is this possible?
>
> As you have already found out you need only standalone leiningen jar,
> which is downloaded by "lein.py".
>
>
>
>
>
> > 2. Any other lein command seems to require the clojure jar in the
> > repository ~/.m2/repository/org/clojure/clojure/1.1.0-alpha-SNAPSHOT/
> > clojure-1.1.0-alpha-SNAPSHOT.jar. Since I don't have one there, I
> > modified CLOJURE_JAR to point to my existing jar. Everything still
> > fails with this sort of error:
>
> > lein help
> > java.lang.NoClassDefFoundError: Files
> > Caused by: java.lang.ClassNotFoundException: Files
> > at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
> > at java.security.AccessController.doPrivileged(Native Method)
> > at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
> > at java.lang.ClassLoader.loadClass(ClassLoader.java:303)
> > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
> > at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
> > at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:316)
> > Could not find the main class: Files. Program will exit.
> > Exception in thread "main"
>
> > I suspect the suspicious "Files" class name is coming from the fact
> > that I now have CLOJURE_JAR set as follows:
>
> > CLOJURE_JAR = expanduser("C:\\Program Files (x86)\\Clojure Box\\clojure
> > \\clojure-1.0.0.jar")
>
> > Looks like I'm getting bit by spaces in the path name. This would not
> > be an issue if lein had downloaded its own clojure jar during step 1
> > (no spaces in that path).
>
> Yes, there are some escaping problems on Windows. I changed a little bit
> "lein.py" and this worked for me on Windows and Linux:
>
>
> #!/usr/bin/env python
>
> import sys
> from glob import glob
> from os import makedirs, system, getenv
> from os.path import expanduser, dirname, exists
> from urllib import urlretrieve
>
> ### inits
>
> VERSION = "1.0.0"
>
> if sys.platform == "win32":
> CP_SEP = ";"
> else:
> CP_SEP = ":"
>
> LEIN_JAR =
> expanduser("~/.m2/repository/leiningen/leiningen/%s/leiningen-%s-standalone
> .jar" % (VERSION, VERSION))
>
> CLOJURE_JAR =
> expanduser("~/.m2/repository/org/clojure/clojure/1.1.0-alpha-SNAPSHOT/cloju
> re-1.1.0-alpha-SNAPSHOT.jar")
>
> CPS = glob("lib/*")
>
> LEIN_URL = "http://repo.technomancy.us/leiningen-%s-standalone.jar"; %
> (VERSION)
>
> # leiningen installation checks
>
> LEIN_BIN_DIR = dirname(sys.argv[0])
>
> if exists(LEIN_BIN_DIR + "../src/leiningen/core.clj"):
> # running from source-checkout
> LEIN_LIBS = glob(LEIN_BIN_DIR + "/*")
> CLASSPATH = CPS + [LEIN_LIBS]
> if len(LEIN_LIBS) < 1 and sys.argv[1] != 'self-install':
> print "Your Leiningen development ch
Re: leiningen with latest clojure
Thanks for your answers. Yes, I'd like to use the new branch not the master one, anyway having this dependency in project.clj: [org.clojure/clojure "1.1.0-new-SNAPSHOT"] and using lein repl, I still have 1.1.0-alpha-SNAPSHOT at the repl. I added the spec to the dev-dependencies too, but still having no success. Andrea. On Dec 19, 3:56 am, "Alex Osborne" wrote: > defn writes: > > On Dec 18, 7:00 am, Andrea Tortorella wrote: > >> I'd like to ask how to use leiningen with the latest clojure > >> development new branch, is this possible? > > This will pull down 1.1.0-master-SNAPSHOT per the settings in > > project.clj which is as new as Dec. 18th, 16:00 at the time of writing > > this. > > I think Andrea meant the "new" branch rather than the "master" branch. > Just use "1.1.0-new-SNAPSHOT" as the version number for both clojure and > clojure-contrib and you should be okay. Just be aware that if you pull > in other Clojure libraries they may be compiled against "master" and > won't work against "new". This compatibility will hopefully be sorted > out in future as "slim jars" (not AOT-compiled) are probably going to > become the default in most tools. -- 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: Parenthesis Inference
> > I guess it's mostly a matter of judging a language by its long-term > merits instead of initial appearance -- just like with so many other > things in life. > That - right there - is a tacit admission that the Clojure community will find it actively desirable that it remain a minority language, so we can all feel smug that we understand something those poor average programmers were too simple to see. You know there's nothing wrong with allowing Clojure to display its elegance upfront, rather than making programmers work for it like it's some Presbytarian admission exam. Martin -- 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: Parenthesis Inference
On Sat, Dec 19, 2009 at 8:25 AM, Martin Coxall wrote: > > > > I guess it's mostly a matter of judging a language by its long-term > > merits instead of initial appearance -- just like with so many other > > things in life. > > > > That - right there - is a tacit admission that the Clojure community will > find it actively desirable that it remain a minority language, so we can all > feel smug that we understand something those poor average programmers were > too simple to see. > I don't think anybody in the Clojure community wants to Clojure to be a fringe language. Considering the ML now has about 3K subscribers (up 2500 from 14 months ago) I think Rich Hickey and the community have done a fair job touting it's advantages. However, there are somethings about every language that you just have to accept. Lisp's parentheses are one of those things. For example, it's really not worth complaining about Python's enforcement of significant whitespace. Sure people sing it praises now, but to this day there still fruitless discussions about the matter mostly initiated by people with only a passing familiarity of the language. > You know there's nothing wrong with allowing Clojure to display its > elegance upfront, rather than making programmers work for it like it's some > Presbytarian admission exam. > You are not the first to bring up the concern about parentheses and you will certainly not be the last. My advice would be to let the matter drop. People who aren't going to learn Lisp just because it has parentheses aren't going to be converted. But from the variety of programmers on this list, parens are not a significant deterrant for programmers coming from the background of Java, Scala, JavaScript, C, C++, Objective-C, OCaml, Haskell, Prolog, Erlang, PHP, Perl, Python, Ruby, etc. > > Martin > > -- > 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: Parenthesis Inference
Martin, I was short with you yesterday. I'm sorry about that. Please let me try again. I'm all for providing better documentation, eliminating bad design, and holding hands as people get up to speed. As a community, we constantly need to do more work to make it accessible. That's the point of the IRC channel & this list. I believe you browse the archives you'll see that mutual assistance is the prevailing attitude here. Clojure's clean design does make it easy to learn. The sequence abstraction makes the core library small. The persistent data structures make it easier to write multithreaded stuff than in any other language (I invite you to provide a counter example). The macro system is hygienic, and as powerful as any other. I'm going to use a point from Paul Grahams' crtique of Java: http://www.paulgraham.com/javacover.html The main point I want to echo is that tools "designed for other people" always seem to be inferior to tools "designed for myself". Clojure was originally written by Rich for Rich. I check that any feature I suggest really improves my own code before I post to the list. After that, the idea has to survive critique from lots of other Clojure experts, making sure that the feature is "designed for myself". A lot of proposals don't get past this step, because it is already solved or it doesn't fit into the Clojure way. Removing parens is one of those changes that simultaneously is "designed for other people" and makes the expert's job more difficult (By making macro writing & argument resolution harder). It's a complete and total loss from my perspective, and that is what evokes the emotional response. I've suffered enough at the hands of languages "designed for other poeple". This is Clojure, and I want to keep it a language "designed for myself". Sean On Dec 19, 9:18 am, Martin Coxall wrote: > > It is proudly a Lisp for people that want to get things done. Any > > Java/.NET/Python/Brainfuck/Ruby/Basic/C/C++ (No Perlmongers :)) that > > want to get better are welcome. However, there is a way things are > > done in the language, driven by the underlying problems reality > > imposes on developers. A prospective Clojure developer must accept > > that the language does this to help you, not hurt you, and they need > > to be open to the ideas. > > > That is the intended audience. > > Clojure may be a new Lisp, but it seems the die hard holier-than-thou > attitude of old-school Lipsers is alive and well. > > Look, there's a reason nobody uses Lisp. And the attitude of "we know best > and if you can't see that you're an idiot" is certainly part of it. > > A prospective Clojure developer "must" not do anything. They will probably > take one look at Clojure's seemingly user-hostile syntax, read how unless > they immediately embrace parens that they are *not welcome*, click their > browser back button and never give another thought to Clojure again. > > Martin -- 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: Parenthesis Inference
Very abstract java example (as concise as possible):
List processList(List oldObjects)
{
List newObjects = ArrayList;
for(Object object : oldObjects)
{
newObjects.add(manipulate(object));
}
return newObjects;
}
Clojure equivalent:
(defn processList [#^Object list]
(for [object list] (manipulate object)))
I realize this is a very pedestrian example, but a couple things to note (and
I'm sure mentioned previously):
- Lisps are much more expressive, in general
- Compared to most languages there is significantly less syntactic noise-
There is "just enough" syntax to delimit the code.
- The code is a data-structure (homoiconicity), and it is very easy to see
where the expression begins and ends (this is good for readability, code
formatters, etc)
- Lisps are very consistent- no special code formatting rules to remember.
Despite what seems like a large number of parentheses there are far less
'control' characters.
I.e. instead of : . ; ( ) { } you have ( ), and usually fewer of them.
- Most programmers rely on their IDE/Editor or indentation to make sure they
are matching curly-braces correctly,
which is made harder by blocks of code that frequently extend beyond the
height of your screen.
IDEs/editors can match parentheses as well. :)
- The parentheses make the code sleek and aerodynamic
---
Joseph Smith
j...@uwcreations.com
(402)601-5443
On Dec 19, 2009, at 11:21 AM, David Nolen wrote:
> On Sat, Dec 19, 2009 at 8:25 AM, Martin Coxall wrote:
> >
> > I guess it's mostly a matter of judging a language by its long-term
> > merits instead of initial appearance -- just like with so many other
> > things in life.
> >
>
> That - right there - is a tacit admission that the Clojure community will
> find it actively desirable that it remain a minority language, so we can all
> feel smug that we understand something those poor average programmers were
> too simple to see.
>
> I don't think anybody in the Clojure community wants to Clojure to be a
> fringe language. Considering the ML now has about 3K subscribers (up 2500
> from 14 months ago) I think Rich Hickey and the community have done a fair
> job touting it's advantages.
>
> However, there are somethings about every language that you just have to
> accept. Lisp's parentheses are one of those things. For example, it's really
> not worth complaining about Python's enforcement of significant whitespace.
> Sure people sing it praises now, but to this day there still fruitless
> discussions about the matter mostly initiated by people with only a passing
> familiarity of the language.
>
> You know there's nothing wrong with allowing Clojure to display its elegance
> upfront, rather than making programmers work for it like it's some
> Presbytarian admission exam.
>
> You are not the first to bring up the concern about parentheses and you will
> certainly not be the last. My advice would be to let the matter drop. People
> who aren't going to learn Lisp just because it has parentheses aren't going
> to be converted. But from the variety of programmers on this list, parens are
> not a significant deterrant for programmers coming from the background of
> Java, Scala, JavaScript, C, C++, Objective-C, OCaml, Haskell, Prolog, Erlang,
> PHP, Perl, Python, Ruby, etc.
>
>
> Martin
>
> --
> 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: Parenthesis Inference
Oops.. left two parentheses out in my Java code. Guess that just furthers my
point. :)
> List newObjects = ArrayList();
On Dec 19, 2009, at 12:04 PM, Joseph Smith wrote:
> Very abstract java example (as concise as possible):
>
> List processList(List oldObjects)
> {
>List newObjects = ArrayList;
>for(Object object : oldObjects)
>{
> newObjects.add(manipulate(object));
>}
>return newObjects;
> }
>
> Clojure equivalent:
>
>(defn processList [#^Object list]
> (for [object list] (manipulate object)))
>
> I realize this is a very pedestrian example, but a couple things to note (and
> I'm sure mentioned previously):
> - Lisps are much more expressive, in general
> - Compared to most languages there is significantly less syntactic noise-
> There is "just enough" syntax to delimit the code.
> - The code is a data-structure (homoiconicity), and it is very easy to see
> where the expression begins and ends (this is good for readability, code
> formatters, etc)
> - Lisps are very consistent- no special code formatting rules to remember.
> Despite what seems like a large number of parentheses there are far less
> 'control' characters.
> I.e. instead of : . ; ( ) { } you have ( ), and usually fewer of them.
> - Most programmers rely on their IDE/Editor or indentation to make sure they
> are matching curly-braces correctly,
>which is made harder by blocks of code that frequently extend beyond the
> height of your screen.
>IDEs/editors can match parentheses as well. :)
> - The parentheses make the code sleek and aerodynamic
>
> ---
> Joseph Smith
> j...@uwcreations.com
> (402)601-5443
>
>
>
>
>
> On Dec 19, 2009, at 11:21 AM, David Nolen wrote:
>
>> On Sat, Dec 19, 2009 at 8:25 AM, Martin Coxall wrote:
>> >
>> > I guess it's mostly a matter of judging a language by its long-term
>> > merits instead of initial appearance -- just like with so many other
>> > things in life.
>> >
>>
>> That - right there - is a tacit admission that the Clojure community will
>> find it actively desirable that it remain a minority language, so we can all
>> feel smug that we understand something those poor average programmers were
>> too simple to see.
>>
>> I don't think anybody in the Clojure community wants to Clojure to be a
>> fringe language. Considering the ML now has about 3K subscribers (up 2500
>> from 14 months ago) I think Rich Hickey and the community have done a fair
>> job touting it's advantages.
>>
>> However, there are somethings about every language that you just have to
>> accept. Lisp's parentheses are one of those things. For example, it's really
>> not worth complaining about Python's enforcement of significant whitespace.
>> Sure people sing it praises now, but to this day there still fruitless
>> discussions about the matter mostly initiated by people with only a passing
>> familiarity of the language.
>>
>> You know there's nothing wrong with allowing Clojure to display its elegance
>> upfront, rather than making programmers work for it like it's some
>> Presbytarian admission exam.
>>
>> You are not the first to bring up the concern about parentheses and you will
>> certainly not be the last. My advice would be to let the matter drop. People
>> who aren't going to learn Lisp just because it has parentheses aren't going
>> to be converted. But from the variety of programmers on this list, parens
>> are not a significant deterrant for programmers coming from the background
>> of Java, Scala, JavaScript, C, C++, Objective-C, OCaml, Haskell, Prolog,
>> Erlang, PHP, Perl, Python, Ruby, etc.
>>
>>
>> Martin
>>
>> --
>> 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
Maven2 repo URL required for Clojure 1.1 RC
Hi, Could anybody please give me a Clojure 1.1 Maven2 repo URL? It's not there on Maven central repo yet, and (surprise!) clojars.org doesn't seem to have it either. I am going to use the 1.1 RC JAR in my local repo until I find one. 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: Parenthesis Inference
The intended audience are Software Engineers. Not the people who hide behind "this-is-not-intuitive" their lack of willing to learn the most effective way to spend their professional life. Why is it that you believe them to be mutually exclusive events? You portray Software engineers as if they are Gods and the most brilliant minds on the planet. A lot are just average. And ofcourse, if Clojure does not try to make them feel at home, it is just going to be another Hobby language. That's all. -- 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: Parenthesis Inference
On Sat, Dec 19, 2009 at 9:21 AM, David Nolen wrote: > I don't think anybody in the Clojure community wants to Clojure to be a > fringe language. Actually, I don't mind if Clojure retains a certain degree of "fringe" status. To clarify, I think the ideal size for a language community is somewhere in between the two extremes. You certainly want enough people who love working with a language that the language keeps moving forward and cool libraries and tools are continually being developed. On the other hand, there's something very nice about knowing a language that is a bit of a "secret weapon". Sometimes companies advertise that they are looking for a certain language, not because they really need that language, but because they know that any developer who knows that language is likely to be of a certain high caliber. They use the language as a way to weed out run-of-the-mill software engineers. Languages like Haskell, Scheme, and ML are often used for this purpose (not Java, of course, it's too mainstream). Such job posts also send a signal to talented developers that their company is a special place to work, because they know the value of "secret weapon" languages. I would actively like to see Clojure remain obscure enough to fall into this category. I sympathize with the original poster's point, however. I have been using Lisp dialects for 20 years, and I still find Lisp code harder to read than its mainstream counterparts. The parentheses provide a visual sameness to the code that forces you to think very hard to understand it. Python, on the other hand, is the most readable language I've encountered. So, despite all the claims that you'll "learn to love parentheses", I'll say that it's not necessarily true. I have no love for the hyper-consistent prefix syntax for functions, macros, and keywords, and all the deeply-nested parentheses that result. Still, I'm flexible enough that I have no problem *tolerating* Lisp's syntax. And if other people can't see past the parentheses and understand the value of the language, I have a hard time getting worked up about that (see above point). -- 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
Parentheses
Parens are really a non-issue once you are using an editor that counts them and highlights matching appropriately. -- 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: Parenthesis Inference
On Dec 18, 9:28 pm, Sean Devlin wrote: > It is proudly a Lisp for people that want to get things done. Any > Java/.NET/Python/Brainfuck/Ruby/Basic/C/C++ (No Perlmongers :)) I was a Perlmonger back in the day. :) -SS -- 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: 1.1 changes.txt typo
On Dec 18, 9:03 am, David Thomas Hume wrote: > From the 1.1 release notes: > > "Futures represent asynchronous computations. They are away to get > code to run in another thread, and obtain the result." That's been fixed now in the 1.1.x branch; thanks for the report. -SS -- 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: Parenthesis Inference
Well, good thing you repented of your evil ways On Dec 19, 3:37 pm, Stuart Sierra wrote: > On Dec 18, 9:28 pm, Sean Devlin wrote: > > > It is proudly a Lisp for people that want to get things done. Any > > Java/.NET/Python/Brainfuck/Ruby/Basic/C/C++ (No Perlmongers :)) > > I was a Perlmonger back in the day. :) > > -SS -- 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
popping optional args from the front
In Clojure it is idiomatic to have optional args at the front of the
signature. This makes it easy to define convenient caller APIs, but it
leads to bulky let forms like this one (from clojure.core/defmulti)
(let [docstring (if (string? (first options))
(first options)
nil)
options (if (string? (first options))
(next options)
options)
m (if (map? (first options))
(first options)
{})
options (if (map? (first options))
(next options)
options)
dispatch-fn (first options)
options (next options)
m (assoc m :tag 'clojure.lang.MultiFn)
m (if docstring
(assoc m :doc docstring)
m)
m (if (meta mm-name)
(conj (meta mm-name) m)
m)]
Is it worth capturing this common idiom in a helper function, e.g. pop-
optional-args:
(defn pop-optional-args
[preds args]
(if (seq preds)
(if ((first preds) (first args))
(cons (first args) (pop-optional-args (rest preds) (rest args)))
(cons nil (pop-optional-args (rest preds) args)))
(list args)))
The above let form would then be:
(let [[docstring m dispatch-fn options] (pop-optional-args [string?
map? identity] options)
m (assoc m :tag 'clojure.lang.MultiFn)
m (if docstring
(assoc m :doc docstring)
m)
m (if (meta mm-name)
(conj (meta mm-name) m)
m)]
Worth doing? If so, how could it be better?
Stu
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Maven2 repo URL required for Clojure 1.1 RC
Shantanu Kumar writes: > Could anybody please give me a Clojure 1.1 Maven2 repo URL? It's not > there on Maven central repo yet, and (surprise!) clojars.org doesn't > seem to have it either. http://build.clojure.org/snapshots/ -- 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: Advice for someone coming from an OO world?
On 18 dec, 17:55, IslandRick wrote: > Can anyone here offer some advice to those who are too ingrained in > using an object-oriented hammer on every nail they see? I know Rich > and Stuart have some good design examples around (I've read many), but > if there are any tutorials that show how to re-envision OO problems in > an FP world, I'd love to see them. You are probably running into two problems at the same time: 1 is the expectation that you can modify stuff left and right 2. is the "dispatch" issue In my (short) experience with clojure, the main problem is actually #1. In most relatively simple programs in clojure you actually don't need all that much dynamic dispatching, and if you really do need it there's always multi-methods. When you're working in clojure and want to keep the code simple, it's vital that you think about what parts of the shared data can actually change, and try to keep those parts minimal, and keep the inter- changeable parts as unrelated as possible. That tends to mean you probably prefer not to set up a big graph of inter-related objects if you can help it - while that is something that's common in OO programming. Rich's ant colony example is a good demonstration of that principle: instead of having ant objects that "carry around" all kinds of state, you have a static grid of mutable locations and the ants are immutable objects "contained" in the grid's cells. Hope that helps, If you've got more specific questions about your program, people here can probably help you in more detail. Cheers, Joost Diepenmaat. -- 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: Advice for someone coming from an OO world?
Oh and another thing: In my experience, it's easier to start by putting all the code in a single package, and only split it up once you get to a level of complexity that really demands splitting it up. Emacs/SLIME (and probably other interactive environments) really help too: once you've written/rewritten a function, you want to test it immediately, interactively. Write/compile/run loops are annoying if you don't have an interactive environment. This is why in emacs, the *scratch* buffer and ielm are so handy. -- 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
let-binding overrides binding-binding
Hi, just found that a binding-form within a let-form does still use the outer value. user> (def *val* "root binding") #'user/*val* user> (defn print-val [] (println "*val* is: " *val*)) #'user/print-val user> (defn let-vs-binding [] (println "beginning: " *val*) (let [*val* "bound by let"] (println "in LET: " *val*) (print-val) (binding [*val* "bound by BINDING"] (println "in BINDING: " *val*) (print-val #'user/let-vs-binding user> (let-vs-binding) beginning: root binding in LET: bound by let *val* is: root binding in BINDING: bound by let *val* is: bound by BINDING As far as I can see this is the documented behavior. The rules for resolving a symbol described in http://clojure.org/evaluation seem to be the relevant part. Two questions 1. Is my explanation correct? 2. Is this the desired behavior or will it change in the near future? Kind regards, Stefan -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Leiningen in Python
John writes: > Hi, > > I am trying to use lein.py, from above, on Windows (Vista). > > It works nicely for some commands (e.g. lein.py compile), > after removing the extra space in two places e.g. > 'leiningen-%s-standalone .jar' -> > 'leiningen-%s-standalone.jar' > and > '1.1.0-alpha-SNAPSHOT/cloju re-1.1.0-alpha-SNAPSHOT.jar' -> > '1.1.0-alpha-SNAPSHOT/clojure-1.1.0-alpha-SNAPSHOT.jar' It's really strange. These additional spaces don't exist in my original script. They were added by google groups or something. > But I still have the following error with the 'lein.py install' and > 'lein.py jar' commands: > > E:\temp\leiningen\myproject> E:\etc\clojure\Leiningen\lein.py install > Exception in thread "main" java.util.regex.PatternSyntaxException: > Illegal/unsupported escape sequence near index 9 > ^E:\temp\leiningen\myproject > ^ (NO_SOURCE_FILE:0) > at clojure.lang.Compiler.eval(Compiler.java:5274) > at clojure.lang.Compiler.eval(Compiler.java:5226) > ... > > E:\temp\leiningen\myproject> E:\etc\clojure\Leiningen\lein.py jar > Exception in thread "main" java.util.regex.PatternSyntaxException: > Illegal/unsupported escape sequence near index 9 > ^E:\temp\leiningen\myproject > ^ (NO_SOURCE_FILE:0) > at clojure.lang.Compiler.eval(Compiler.java:5274) > at clojure.lang.Compiler.eval(Compiler.java:5226) > ... > > I am guessing that this means that the backslash in 'temp\leiningen' > needs to be escaped > somewhere in the python script (lein.py) above. > (I am not clear why the first backslash (in E:\temp) is not reported > as the error (index 4).) > > I have tried many guesses (I am not familiar with python (V2.6)). > Can anyone make some suggestions? I don't think it is `lein.py` problem anymore. Leiningen uses regular expressions on paths and as usually there is a problem with windows path separator. I took a look in leiningen source and this small patch made command "jar" working for me on Windows (I haven't looked at "install" command, but probably it is the same problem): diff --git a/src/leiningen/jar.clj b/src/leiningen/jar.clj index 227bccd..d1dd766 100644 --- a/src/leiningen/jar.clj +++ b/src/leiningen/jar.clj @@ -22,13 +22,17 @@ (str "Main-Class: " main))]) "\n") +(defn unix-path [path] + (.replaceAll path "" "/")) + (defmulti copy-to-jar (fn [project jar-os spec] (:type spec))) (defmethod copy-to-jar :path [project jar-os spec] (doseq [child (file-seq (file (:path spec)))] (when-not (.isDirectory child) - (let [path (str child) -path (re-sub (re-pattern (str "^" (:root project))) "" path) + (let [path (unix-path (str child)) +path (re-sub (re-pattern (str "^" (unix-path (:root project + "" path) path (re-sub #"^/resources" "" path) path (re-sub #"^/classes" "" path) path (re-sub #"^/src" "" path) HTH, Rob -- 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: popping optional args from the front
Occasionally I have to write a custom def macro, and this would make
life easier. I would have to use it to provide specific feedback, but
it seems like an idea worth pursuing.
On Dec 19, 3:58 pm, Stuart Halloway wrote:
> In Clojure it is idiomatic to have optional args at the front of the
> signature. This makes it easy to define convenient caller APIs, but it
> leads to bulky let forms like this one (from clojure.core/defmulti)
>
> (let [docstring (if (string? (first options))
> (first options)
> nil)
> options (if (string? (first options))
> (next options)
> options)
> m (if (map? (first options))
> (first options)
> {})
> options (if (map? (first options))
> (next options)
> options)
> dispatch-fn (first options)
> options (next options)
> m (assoc m :tag 'clojure.lang.MultiFn)
> m (if docstring
> (assoc m :doc docstring)
> m)
> m (if (meta mm-name)
> (conj (meta mm-name) m)
> m)]
>
> Is it worth capturing this common idiom in a helper function, e.g. pop-
> optional-args:
>
> (defn pop-optional-args
> [preds args]
> (if (seq preds)
> (if ((first preds) (first args))
> (cons (first args) (pop-optional-args (rest preds) (rest args)))
> (cons nil (pop-optional-args (rest preds) args)))
> (list args)))
>
> The above let form would then be:
>
> (let [[docstring m dispatch-fn options] (pop-optional-args [string?
> map? identity] options)
> m (assoc m :tag 'clojure.lang.MultiFn)
> m (if docstring
> (assoc m :doc docstring)
> m)
> m (if (meta mm-name)
> (conj (meta mm-name) m)
> m)]
>
> Worth doing? If so, how could it be better?
>
> Stu
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Parenthesis Inference
On 19 dec, 15:25, Martin Coxall wrote: > > I guess it's mostly a matter of judging a language by its long-term > > merits instead of initial appearance -- just like with so many other > > things in life. > > That - right there - is a tacit admission that the Clojure community will > find it actively desirable that it remain a minority language, so we can all > feel smug that we understand something those poor average programmers were > too simple to see. > > You know there's nothing wrong with allowing Clojure to display its elegance > upfront, rather than making programmers work for it like it's some > Presbytarian admission exam. Most programming languages aren't judged on their syntactical elegance, otherwise nobody would use Erlang, for example. Now I like Erlang, but I still think it just looks horrible and it has way too many syntactical niggles that are hard to get familiar with. Lisp languages are completely simple in that regard. The worst question you generally run into is whether to add 1 or 2 pairs of parentheses at some point. Clojure makes this a bit simpler in the generally-used cases and a bit harder overall (since it uses 4+ different kinds of delimiters) Now that does not mean it doesn't look "alien". It does. Deal with it or do something else. But don't pretend that doing what clojure *does* is much easier to write or read in any kind of "familiar" syntax, unless you're got a really serious contender. It's been tried many times - McCarthy himself did not think s-expressions were the final syntax for the language - but nobody has been able to come up with a syntax that actually works better for Lisp. Once everything is an expression - and especially when you place a large emphasis on side-effect free code - all you can really do to improve the "parenthesis problem" is to compact typical constructs. We've already got macros and decent reader syntax. -- 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: leiningen with latest clojure
Andrea Tortorella writes: > Yes, I'd like to use the new branch not the master one, anyway having > this dependency in project.clj: > > [org.clojure/clojure "1.1.0-new-SNAPSHOT"] > > and using lein repl, I still have 1.1.0-alpha-SNAPSHOT at the repl. That's a bug. Currently due to I/O limitations with the repl it's not capable of being launched in a subclassloader, so it must use the same version of Clojure as Leiningen. See "Known Issues" in the readme. -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: Leiningen in Python
John writes: > I am trying to use lein.py, from above, on Windows (Vista). > But I still have the following error with the 'lein.py install' and > 'lein.py jar' commands: I don't know Python myself, so I will wait until I hear about these being resolved before I check this in. -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: Parenthesis Inference
Martin Coxall writes: > I trust the many, many more people that have rejected Lisp for its > hostile syntax and delusions of importance than the statistically > insignificant minority who have actually stuck with it. Sometimes people are just looking for excuse to criticize. Before it was considered mainstream, there was just as much noise about Python and whitespace-sensitivity and the explicit "self" in method arguments as there is about Clojure and parens. > But I'm trying to think of it from the point of view of Joe Q. Coder, > who will take one look at our beloved elegant, expressive Clojure, see > all the parens and run screaming. Take away the parens and that same Joe Q. Coder is likely to pick something else to take one look at and run away screaming. Perhaps the JVM, perhaps immutability, perhaps the whitespace-sensitive syntax. I'm not telling you not to try it. If you can pull off a preprocessor or much better an editor, that makes Clojure code _significantly_ easier to read while retaining its expressiveness, simplicity of macro writing and tool support then I will join you in using and championing it. But this is the same "great idea" that everyone who's ever used a lisp since the dawn of programming has come up with and despite numerous attempts, to my knowledge not a single one of them has ever taken off. That doesn't mean it's not possible, just that it's not going to be as simple as just allowing "others" to write whitespace-sensitive Clojure. The reaction you are seeing from the old-school lispers (of which I am not one, unless 4 months is "old") is understandable. It's the same sort of reaction you would get from an old-school Python programmer if you jumped on the Python mailing list and declared that you've solved the significant-whitespace problem: allow newcomers to write Python code with lisp-like 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: let-binding overrides binding-binding
On Dec 19, 2009, at 5:23 PM, Stefan Kamphausen wrote: > 1. Is my explanation correct? It is. The binding form operates on the var, it doesn't affect name resolution within the binding form's body. *val* within the body of the binding still resolves to the let-bound local. While *val* is shadowed by a let-bound local, if you want to refer to the var *val*, use its fully qualified name. > 2. Is this the desired behavior or will it change in the near future? This behavior is well-established. I have no special knowledge of what may or may not change, but changing this behavior seems very unlikely to me. --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: Transient Bug
On Sat, Dec 19, 2009 at 10:30 AM, Sean Devlin wrote: > Steve, > I've been checking out the Java, and it looks the same to me. I think > this raises a couple issues: > > 1. Should sorted versions get transient support in 1.1? > 2. The docs should be updated to reflect the 1.1 status of > transients. I would vote for "no" and "yes", respectively. Adding transient support to a collection has a history of adding bugs as well, until they're ironed out. I think 1.1 is the wrong timeframe for that. Perhaps 1.2? I've updated http://clojure.org/transients to reflect vectors and hash-map support of 'transient' in 1.1.0 --Chouser -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com 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: Parenthesis Inference
"Alex Osborne" writes: >> But I'm trying to think of it from the point of view of Joe Q. Coder, >> who will take one look at our beloved elegant, expressive Clojure, see >> all the parens and run screaming. > But this is the same "great idea" that everyone who's ever used a lisp > since the dawn of programming has come up with and despite numerous > attempts, to my knowledge not a single one of them has ever taken off. You're forgetting about Dylan! ... (peals of explosive laughter here) -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
A tale of cond, clauses, and the docs
What, exactly, is a "clause" in clojure? From seeing the term used in context, I inferred that it meant something along the lines of "a keyword which can optionally be used to change the semantics of a form". Apparently, it means more than that. This is valid clojure: (defn sign [x] (cond (> x 0) "Positive" (< x 0) "Negative" :else "Zero")) I had no idea that I could use :else for the fallthrough case of a "cond", so I looked it up in the docs: user> (doc cond) - clojure.core/cond ([& clauses]) Macro Takes a set of test/expr pairs. It evaluates each test one at a time. If a test returns logical true, cond evaluates and returns the value of the corresponding expr and doesn't evaluate any of the other tests or exprs. (cond) returns nil. Apparently, each "test/expr pair" is a clause, or perhaps each test and each expression is a clause. No mention of supporting an :else "clause" though. Let's check out the source code: (defmacro cond "Takes a set of test/expr pairs. It evaluates each test one at a time. If a test returns logical true, cond evaluates and returns the value of the corresponding expr and doesn't evaluate any of the other tests or exprs. (cond) returns nil." [& clauses] (when clauses (list 'if (first clauses) (if (next clauses) (second clauses) (throw (IllegalArgumentException. "cond requires an even number of forms"))) (cons 'clojure.core/cond (next (next clauses)) I don't know much about macros, but it is clear that "cond" builds on "if". However, the documentation for "if" mentions nothing about :else, and the source for "if" is not available, presumably because it's implemented in java. Is there a way to have discovered the existence of :else from the documentation alone? Is this just an oversight in the docs, or is there a more general point concerning clauses that I'm missing? Mike -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: A tale of cond, clauses, and the docs
Ah, :else is an unfortunate choice. The cond macro keeps testing clauses until it finds one that is true. :else was chose because it is simply not nil, and therefor always true. I would re-write your fn like so: (defn sign [x] (cond (> x 0) "Positive" (< x 0) "Negative" true "Zero")) Sean On Dec 19, 10:22 pm, Mike K wrote: > What, exactly, is a "clause" in clojure? From seeing the term used in > context, I inferred that it meant something along the lines of "a > keyword which can optionally be used to change the semantics of a > form". Apparently, it means more than that. > > This is valid clojure: > > (defn sign [x] (cond (> x 0) "Positive" (< x 0) "Negative" :else > "Zero")) > > I had no idea that I could use :else for the fallthrough case of a > "cond", so I looked it up in the docs: > > user> (doc cond) > - > clojure.core/cond > ([& clauses]) > Macro > Takes a set of test/expr pairs. It evaluates each test one at a > time. If a test returns logical true, cond evaluates and returns > the value of the corresponding expr and doesn't evaluate any of the > other tests or exprs. (cond) returns nil. > > Apparently, each "test/expr pair" is a clause, or perhaps each test > and each expression is a clause. No mention of supporting an :else > "clause" though. Let's check out the source code: > > (defmacro cond > "Takes a set of test/expr pairs. It evaluates each test one at a > time. If a test returns logical true, cond evaluates and returns > the value of the corresponding expr and doesn't evaluate any of the > other tests or exprs. (cond) returns nil." > [& clauses] > (when clauses > (list 'if (first clauses) > (if (next clauses) > (second clauses) > (throw (IllegalArgumentException. > "cond requires an even number of forms"))) > (cons 'clojure.core/cond (next (next clauses)) > > I don't know much about macros, but it is clear that "cond" builds on > "if". However, the documentation for "if" mentions nothing > about :else, and the source for "if" is not available, presumably > because it's implemented in java. > > Is there a way to have discovered the existence of :else from the > documentation alone? Is this just an oversight in the docs, or is > there a more general point concerning clauses that I'm missing? > > Mike -- 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: Parenthesis Inference
can't believe, you guys, WAIST! your time discussing about parentheses. There are far more interesting things to discuss. Please don't waist time (time is life, is all we have) in that, and specially, this is a public group, where knowledge should be share, not nonsense discussions. If somebody likes parentheses, good, if not, don't program in anything lispy. No body is forcing that person to program in lisp. Guido On Dec 19, 7:45 pm, Phil Hagelberg wrote: > "Alex Osborne" writes: > >> But I'm trying to think of it from the point of view of Joe Q. Coder, > >> who will take one look at our beloved elegant, expressive Clojure, see > >> all the parens and run screaming. > > But this is the same "great idea" that everyone who's ever used a lisp > > since the dawn of programming has come up with and despite numerous > > attempts, to my knowledge not a single one of them has ever taken off. > > You're forgetting about Dylan! > > ... > > (peals of explosive laughter here) > > -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: bug or feature in (require ...)?
Hi, Am 18.12.2009 um 19:43 schrieb Alex Ott: > Question - this is feature of require? or this is a bug? The current require cannot handle this situation. You will have to reload all namespaces with :reload in the right order manually. See here for more on this issue: http://groups.google.com/group/clojure-dev/browse_thread/thread/b9d15561e8a3b5aa 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: Parenthesis Inference
I think this discussion is getting too long, but anyway ..
Coming from an imperative background, especially Java which is a lot
bloated, when I tried to read Lisp code, I start to get the feeling that I
am staring at the same place for a long time. In an imperative setting, it
definitely means that I am unable to understand the code. However, in the
case of Lisp, since it is more condensed than Java, even though I am looking
at the same place for a longer time, I am actually assimilating at almost
the same rate!
I believe that for Lisp beginners coming from Imperative style, the Brain is
being fooled into believing that it is dumb! Actually it is doing perfectly
fine as long as it understand the different functions/API.
Parenthesis, prefix notations were never a big issue for me. In fact, the
parenthesis are mostly invisible in properly syntax highlighted and properly
indented code. However proper indentation is the key. In other languages you
can figure out things based on syntax symbols like [] { } => and so on.
Since Lisp does not have any of these, the only support the Programmer has
is Indentation!
I should not say this ... but just to get a feel I stared at some Scala code
for a while and said to myself - "What the hell is this! Why am I feeling it
painful to move my eyes so much and there is so much of syntactic noise".
It is just a matter of getting used to. Granted not everybody will feel
comfortable in the same time and so there will be resistance to Lisp style
syntax for a while.
On Sat, Dec 19, 2009 at 2:35 PM, Mark Engelberg wrote:
> On Sat, Dec 19, 2009 at 9:21 AM, David Nolen
> wrote:
> > I don't think anybody in the Clojure community wants to Clojure to be a
> > fringe language.
>
> Actually, I don't mind if Clojure retains a certain degree of "fringe"
> status.
>
> To clarify, I think the ideal size for a language community is
> somewhere in between the two extremes. You certainly want enough
> people who love working with a language that the language keeps moving
> forward and cool libraries and tools are continually being developed.
>
> On the other hand, there's something very nice about knowing a
> language that is a bit of a "secret weapon". Sometimes companies
> advertise that they are looking for a certain language, not because
> they really need that language, but because they know that any
> developer who knows that language is likely to be of a certain high
> caliber. They use the language as a way to weed out run-of-the-mill
> software engineers. Languages like Haskell, Scheme, and ML are often
> used for this purpose (not Java, of course, it's too mainstream).
> Such job posts also send a signal to talented developers that their
> company is a special place to work, because they know the value of
> "secret weapon" languages. I would actively like to see Clojure
> remain obscure enough to fall into this category.
>
> I sympathize with the original poster's point, however. I have been
> using Lisp dialects for 20 years, and I still find Lisp code harder to
> read than its mainstream counterparts. The parentheses provide a
> visual sameness to the code that forces you to think very hard to
> understand it. Python, on the other hand, is the most readable
> language I've encountered. So, despite all the claims that you'll
> "learn to love parentheses", I'll say that it's not necessarily true.
> I have no love for the hyper-consistent prefix syntax for functions,
> macros, and keywords, and all the deeply-nested parentheses that
> result. Still, I'm flexible enough that I have no problem
> *tolerating* Lisp's syntax. And if other people can't see past the
> parentheses and understand the value of the language, I have a hard
> time getting worked up about that (see above point).
>
> --
> 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: Parenthesis Inference
On Sat, 19 Dec 2009 14:22:22 + Martin Coxall wrote: > On 19 Dec 2009, at 13:50, Stefan Kamphausen wrote: > > * Reason. They could have been taken away in more than 50 years of > > history. Guess what, they are still there. > Guess what? NOBODY uses Lisp. Because of those parens. You've overstated the case. Both times. I encounter about one company a year that uses LISP commercially - mostly doing the heavy lifting on the back end server in what we call "cloud" applications these days. Anyone serious about either emacs or Autocad works with lisp. XlispStat seems to still be alive and well. Sure, even all put together, they're a really small fringe group - but the difference between "nothing" and "almost nothing" can be *very* significant (just ask the guy who though that the Tacoma narrows wind resonance was nothing). Second, I've encountered both people and companies that have dropped LISP, and the reason is almost never "those parens." It usually because of one of a number of reasons that can be summarized as "LISP doesn't play well with others": 1. Lack of access to system libraries and frameworks. 2. The pain of sharing data with system utilities and applications. 3. The difficulty of moving programs to other platforms, *especially* if the LISP has solved 1 & 2! This is why the people doing LISP commercially tend to use it on servers - they duck issue #3 for getting the solution to their customers, and thus only have to find an implementation that solves #1 and 2 on their server platform. Note that Clojure solves all three problems by running on the JVM with Java integration. Of course, the question is - how much have you overstated the case? Because that will determine how true this is: On Sat, 19 Dec 2009 12:16:03 -0500 ajay gopalakrishnan wrote: > Why is it that you believe them to be mutually exclusive events? You portray > Software engineers as if they are Gods and the most brilliant minds on the > planet. A lot are just average. And ofcourse, if Clojure does not try to > make them feel at home, it is just going to be another Hobby language. > That's all. Possibly. But what do you mean by "Hobby language"? Something like Oz, which only a few people have heard of, and is pretty much only used academically? I suspect we're already past that stage. Or something like Python, which has a fair share of the LAMP market, in spite of having syntax issues that drive about as much discussion as the parens in LISP do, but almost no presence as an "enterprise language"? If the latter, I'm perfectly happy with that. I've made pretty good living writing Python the past decade or so. If I were willing to use Django or one of the other web templating systems built in Python, I could have done even better. The question here is, how much are you willing to give up in order to make Clojure "an enterprise language"? In the python community - and I've already seen a bit of it here - complaints about the lack of static type checking are about as common as complaints about the lack block delimiters. Are we going to add type declarations to Clojure to make those people "feel at home"? The end result of this path is that Clojure just becomes another Java, and won't be as productive or as much fun as it is today. One of the best things about Python is that the community wants the language to actually improve, even if it means not growing the community. Features aren't normally added to the language just because a lot of people want them; they're added because they actually answer a real need, and don't encourage people to write ugly code. Part of this is because they realize that adding a feature has a cost even for people who don't use it. If nobody uses it, why add it? If somebody uses it, then at some point you'll encounter code that does - so you'll have to know about it. If it encourages the creation of ugly code, so much the worse. The net result of these attitudes is that, even after nearly 20 years of change and community growth, python remains both powerful and a joy to write and read. So, does it really do you any good to add features to Clojure that attract more programmers if the end result is a language that you don't enjoy programming in, and that doesn't give you the productivity that drew you to the language in the first place? 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: Advice for someone coming from an OO world?
On Fri, 18 Dec 2009 08:55:13 -0800 (PST)
IslandRick wrote:
> Can anyone here offer some advice to those who are too ingrained in
> using an object-oriented hammer on every nail they see? I know Rich
> and Stuart have some good design examples around (I've read many), but
> if there are any tutorials that show how to re-envision OO problems in
> an FP world, I'd love to see them.
I haven't seen an answer to this, so here's my one-page guide. This is
meant more for LISP in general than Clojure specific, but should be
better than nothing.
I. Functions
There have been a number of references to the fact that writing
functional programming seems upside-down and/or backwards. That's what
you've got here. Clojure's -> macro may help with that, but I'm going
to avoid it here.
When writing a function in an imperative language, you usually start
with arguments, and then pass them through a series of transforms to
get the value you want to return, like so:
results1 = step1(arguments)
results2 = step2(results1)
return third_step(results2)
To translate that into a function form, either go up from the bottom
of the imperative function as you go inwards in the functional
version, or start at the inside of the functional version as you go
down the imperative one:
(third_step (step2 (step1 arguments)))
Just like learning a foreign language, if you keep it up you'll
eventually stop thinking in imperative terms and translating to
functional, and start thinking in functional terms. Actually, that's
easier than getting to the point of thinking in a foreign language -
or at least it was for me.
II: Structure
OO programs tend to have objects that invoke each others methods in
order to manipulate state and extract information. The typical syntax
for a method invocation is:
object.method(args)
Lisp systems have variables - some of which are functions -
instead. So instead of an object that has both it's instance data and
the class methods, you have a LISP data structure that holds the
"instance data" and a set of functions that manipulate it. A typical
invocation (using the names above) looks like:
(method object args)
As an aside, "class data" winds up in the global variable space.
So to write a "class" in LISP, you'd start with the native data
structure appropriate for the instance variables. Then you'd write
functions that accept one of those as the first argument, and take the
appropriate action.
I.e. - if you stored a bank account in a hashmap with the balance and
id #, you'd do something like (untested code):
(defn make-account [initial-balance id] {:balance initial-balance :id id})
(defn deposit [account amount] (make-account (+ (:balance account) amount) id))
(defn withdraw [account amount] (make-account (- (:balance account) amount) id))
(defn balance [account] (:balance account))
and then do (deposit my-account 20) to invoke the deposit "method" on
my-account and get an updated account, and so on. It's then up to the
caller to do whatever is required with the account to make the state
persistent (update a ref, write it to a database, whatever).
If you really need to have the methods and data in one object that
appears first in the invocation, you can capture them in a
closure. Here's a version of the bank account object with an (object
:method args) version of the API:
(defn make-account [initial-balance id]
(let [methods {:balance (fn []
initial-balance)
:deposit (fn [amount]
(make-account (+ initial-balance amount) id))
:withdraw (fn [amount]
(make-account (- initial-balance amount) id))}]
(fn [method & args]
(apply (methods method) args
which would then be used as (my-account :deposit 20), etc.
Note that LISP systems with OO subsystems tend to keep the
method-first invocation. But they also only seem to be used by a
fringe of the LISP community.
I'm not going to talk about inheritance - it's sensitive to the
underlying LISP, and I don't really know enough about Clojure to do so
intelligently.
HTH,
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: Parenthesis Inference
Is it possible that people are confusing their inability to comprehend deeply nested function calls (no offense intended by that - I hit this often myself) with the strangeness of the perens? I think what others have said about having to think more about each line of Clojure is true. It is more expressive and information-dense. The remedy to this though is not to eliminate the perens syntax, but to use intermediate defs and defns to break up the logic into manageable chunks. These defs would also make the code more self documenting, by associating names with information. As someone who's never learned a lisp before, I find myself warming up quickly to the perens syntax. I think that it's appropriate that a language which takes a completely different approach should also have a different syntax than what I'm used to. I don't think that "it might offend some people" is a valid argument for stripping out a core element of the language syntax. If they're not willing to come out of their comfort zones on such a minor detail then they probably aren't very receptive to functional programming in the first place. And that's my $0.02. :-) -Brandon On Dec 19, 10:21 am, David Nolen wrote: > On Sat, Dec 19, 2009 at 8:25 AM, Martin Coxall wrote: > > > > I guess it's mostly a matter of judging a language by its long-term > > > merits instead of initial appearance -- just like with so many other > > > things in life. > > > That - right there - is a tacit admission that the Clojure community will > > find it actively desirable that it remain a minority language, so we can all > > feel smug that we understand something those poor average programmers were > > too simple to see. > > I don't think anybody in the Clojure community wants to Clojure to be a > fringe language. Considering the ML now has about 3K subscribers (up 2500 > from 14 months ago) I think Rich Hickey and the community have done a fair > job touting it's advantages. > > However, there are somethings about every language that you just have to > accept. Lisp's parentheses are one of those things. For example, it's really > not worth complaining about Python's enforcement of significant whitespace. > Sure people sing it praises now, but to this day there still fruitless > discussions about the matter mostly initiated by people with only a passing > familiarity of the language. > > > You know there's nothing wrong with allowing Clojure to display its > > elegance upfront, rather than making programmers work for it like it's some > > Presbytarian admission exam. > > You are not the first to bring up the concern about parentheses and you will > certainly not be the last. My advice would be to let the matter drop. People > who aren't going to learn Lisp just because it has parentheses aren't going > to be converted. But from the variety of programmers on this list, parens > are not a significant deterrant for programmers coming from the background > of Java, Scala, JavaScript, C, C++, Objective-C, OCaml, Haskell, Prolog, > Erlang, PHP, Perl, Python, Ruby, etc. > > > > > Martin > > > -- > > 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: A tale of cond, clauses, and the docs
On Dec 19, 8:27 pm, Sean Devlin wrote: > :else was chose because it is simply not nil, and therefor always true. I suspected something along these lines soon after I posted. I did some more experimenting and discovered that :foo will work just as well as :else. So if I understand correctly, :else is not even defined in the language anywhere. Like :foo, it springs into existence when I first mention it, and it evaluates to true by virtue of being a keyword. Cond exploits this behavior for free. This is in contrast with, e.g., the ns macro, which presumably would have to explicitly match against keywords such as :use or :require to implement the proper semantics. Mike -- 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: Parenthesis Inference
Phil Hagelberg writes: > "Alex Osborne" writes: >> But this is the same "great idea" that everyone who's ever used a lisp >> since the dawn of programming has come up with and despite numerous >> attempts, to my knowledge not a single one of them has ever taken off. > > You're forgetting about Dylan! Gosh. So I am. It was created by Apple, no less. It even lets you use semicolons. Semicolons and Apple! That's got to be a recipe for success with the superficial masses. Seriously though, there's plenty of examples that show that popularity does not strongly depend on readable syntax (look at HTML, Ant, heck Perl). But from either side, an argument based on an appeal to popularity is sort of missing the point. I share the opinion of Mark Engelberg and others. I don't mind Lisp syntax because it has benefits, but it's definitely not as readable. The sweet expressions guy (David Wheeler) covers this pretty well: http://www.dwheeler.com/readable/retort-lisp-can-be-readable.html I'm not sure if sweet expressions are the answer. Or even if there is an answer. But for me editor support is key. I've overheard this conversation countlessly, about so many languages: "Oh, what's that you're coding in?" "Foobar. It's pretty awesome." "Yeah, it looks pretty nice." "See how you don't need to specify the blahs? The compiler just figures it out." "Nice! I might try it out. Does it work with Eclipse?" "Well, sort of, but ..." "Oh. Are there any other nice editors that work better with it? Netbeans maybe?" "Not really. There's an Emacs mode but ..." "Oh. Well. Nevermind then. Some other time, maybe." I know David Wheeler's retort to the suggestion of tools is: If you have to use tools to make parens less of a problem, perhaps you should use a better notation that removes extraneous characters in the first place. But I'm not sure I agree with him. I find code (in any syntax) harder to read without syntax highlighting. I also find it frustrating to write without at least basic auto-indentation. We're going to want tools anyway and Lisp's simple syntax and homoiconicity make it so much easier to write them. Funnily enough, I know people who claim Python and Ruby are horrifying. What do they prefer? XSLT. Yes, that XSLT. Yes, the W3C one. Really. Why? Better editor support. Structural editing, on the fly validation, online previewing, XPath generation, backmapping, extensive auto-completion, profilers, debuggers, graph and table visualizations, WYSIWYG XSL-FO report generators, the list goes on and on. The language and syntax are quite frankly awful, but boy do they have some nice tools. The more I use paredit's structural editing the more I find I can't live without it either. The one annoyance I have with it is when I accidentally manage to insert a stray bracket and it gets confused. But maybe here there's something to be learned from the XSLT folks, even if their serialization format leaves a lot to be desired. Maybe paredit should be taken to its logical conclusion: just edit data structures directly, don't worry about the text. Let your editor display and edit infix math. Heck, let it show you complex math expressions with LaTeX formatting for the ultimate in readability. Let it show nesting just with indentation. When you save the file, what does your hypothetical editor do? It writes things out, properly indented, in that good-old relatively easy to parse (for both man and machine) syntax from time immemorial. Can we have our cake and eat it too? -- 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: Parenthesis Inference
Give it a shot. Hack up a prototype. Let's see what happens. On Dec 20, 12:07 am, "Alex Osborne" wrote: > Phil Hagelberg writes: > > "Alex Osborne" writes: > >> But this is the same "great idea" that everyone who's ever used a lisp > >> since the dawn of programming has come up with and despite numerous > >> attempts, to my knowledge not a single one of them has ever taken off. > > > You're forgetting about Dylan! > > Gosh. So I am. It was created by Apple, no less. It even lets you use > semicolons. Semicolons and Apple! That's got to be a recipe for > success with the superficial masses. > > Seriously though, there's plenty of examples that show that popularity > does not strongly depend on readable syntax (look at HTML, Ant, heck > Perl). But from either side, an argument based on an appeal to > popularity is sort of missing the point. I share the opinion of Mark > Engelberg and others. I don't mind Lisp syntax because it has benefits, > but it's definitely not as readable. The sweet expressions guy (David > Wheeler) covers this pretty well: > > http://www.dwheeler.com/readable/retort-lisp-can-be-readable.html > > I'm not sure if sweet expressions are the answer. Or even if there is > an answer. But for me editor support is key. I've overheard this > conversation countlessly, about so many languages: > > "Oh, what's that you're coding in?" > "Foobar. It's pretty awesome." > "Yeah, it looks pretty nice." > "See how you don't need to specify the blahs? The compiler just > figures it out." > "Nice! I might try it out. Does it work with Eclipse?" > "Well, sort of, but ..." > "Oh. Are there any other nice editors that work better with it? > Netbeans maybe?" > "Not really. There's an Emacs mode but ..." > "Oh. Well. Nevermind then. Some other time, maybe." > > I know David Wheeler's retort to the suggestion of tools is: > > If you have to use tools to make parens less of a problem, perhaps > you should use a better notation that removes extraneous characters > in the first place. > > But I'm not sure I agree with him. I find code (in any syntax) harder > to read without syntax highlighting. I also find it frustrating to > write without at least basic auto-indentation. We're going to want > tools anyway and Lisp's simple syntax and homoiconicity make it so much > easier to write them. > > Funnily enough, I know people who claim Python and Ruby are horrifying. > What do they prefer? XSLT. Yes, that XSLT. Yes, the W3C one. Really. > > Why? Better editor support. Structural editing, on the fly validation, > online previewing, XPath generation, backmapping, extensive > auto-completion, profilers, debuggers, graph and table visualizations, > WYSIWYG XSL-FO report generators, the list goes on and on. The language > and syntax are quite frankly awful, but boy do they have some nice > tools. > > The more I use paredit's structural editing the more I find I can't live > without it either. The one annoyance I have with it is when I > accidentally manage to insert a stray bracket and it gets confused. But > maybe here there's something to be learned from the XSLT folks, even if > their serialization format leaves a lot to be desired. Maybe paredit > should be taken to its logical conclusion: just edit data structures > directly, don't worry about the text. > > Let your editor display and edit infix math. Heck, let it show you > complex math expressions with LaTeX formatting for the ultimate in > readability. Let it show nesting just with indentation. > > When you save the file, what does your hypothetical editor do? It > writes things out, properly indented, in that good-old relatively easy > to parse (for both man and machine) syntax from time immemorial. > > Can we have our cake and eat it too? -- 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: Parenthesis Inference
> Is it possible that people are confusing their inability to comprehend > deeply nested function calls (no offense intended by that - I hit this > often myself) with the strangeness of the perens? I think what others > have said about having to think more about each line of Clojure is > true. It is more expressive and information-dense. The remedy to > this though is not to eliminate the perens syntax, but to use > intermediate defs and defns to break up the logic into manageable > chunks. These defs would also make the code more self documenting, by > associating names with information. > > Yes. Even I feel the same. The problem is not the Parens, but Remembering the deep stack of function calls. This brings me to my next question: - Is it LESS idiomatic to use "lets" to bind the output of a few functions. - Do you derive ANY benefit by deeply nesting functions? I would assume the opposite. The only loss is conciseness and I would be willing to sacrifice it a bit for readability. If not, then the use of Let should be highly encouraged. And that will fix the problem provided code is indented correctly. > As someone who's never learned a lisp before, I find myself warming up > quickly to the perens syntax. I think that it's appropriate that a > language which takes a completely different approach should also have > a different syntax than what I'm used to. I don't think that "it > might offend some people" is a valid argument for stripping out a core > element of the language syntax. If they're not willing to come out of > their comfort zones on such a minor detail then they probably aren't > very receptive to functional programming in the first place. > > And that's my $0.02. :-) > > -Brandon > > On Dec 19, 10:21 am, David Nolen wrote: > > On Sat, Dec 19, 2009 at 8:25 AM, Martin Coxall > wrote: > > > > > > I guess it's mostly a matter of judging a language by its long-term > > > > merits instead of initial appearance -- just like with so many other > > > > things in life. > > > > > That - right there - is a tacit admission that the Clojure community > will > > > find it actively desirable that it remain a minority language, so we > can all > > > feel smug that we understand something those poor average programmers > were > > > too simple to see. > > > > I don't think anybody in the Clojure community wants to Clojure to be a > > fringe language. Considering the ML now has about 3K subscribers (up 2500 > > from 14 months ago) I think Rich Hickey and the community have done a > fair > > job touting it's advantages. > > > > However, there are somethings about every language that you just have to > > accept. Lisp's parentheses are one of those things. For example, it's > really > > not worth complaining about Python's enforcement of significant > whitespace. > > Sure people sing it praises now, but to this day there still fruitless > > discussions about the matter mostly initiated by people with only a > passing > > familiarity of the language. > > > > > You know there's nothing wrong with allowing Clojure to display its > > > elegance upfront, rather than making programmers work for it like it's > some > > > Presbytarian admission exam. > > > > You are not the first to bring up the concern about parentheses and you > will > > certainly not be the last. My advice would be to let the matter drop. > People > > who aren't going to learn Lisp just because it has parentheses aren't > going > > to be converted. But from the variety of programmers on this list, parens > > are not a significant deterrant for programmers coming from the > background > > of Java, Scala, JavaScript, C, C++, Objective-C, OCaml, Haskell, Prolog, > > Erlang, PHP, Perl, Python, Ruby, etc. > > > > > > > > > Martin > > > > > -- > > > 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+uns
clojure.contrib.error-kit bug?
(defn- special-form [form]
(and (list form)
(symbol? (first form))
(#{#'handle #'bind-continue} (resolve (first form)
I think the second line should say (list? form). (list form) is
always true.
--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: Parenthesis Inference
Yes, Martin, please give it a try. Only then can we know if the parenthesis is real issue or not. There is no point arguing about it. The only disadvantage is that, over time, people will forget that it is actually a list. But, hey, if it does not prevent us from writing efficient and correct code then why not forget it and leave the compiler to worry about that. If possible, I would also want to see a macro that allows me to write (x < y) instead of (< x y). (+ x y) can be read literally as "add x to y" (square x) can be read literally as "squares x" (< x y) how do you read this literally left-to-right? Relational operators being so common in code, I think it abuse of notation is valid here. Thanks Ajay G. On Sun, Dec 20, 2009 at 12:40 AM, Sean Devlin wrote: > Give it a shot. Hack up a prototype. Let's see what happens. > > On Dec 20, 12:07 am, "Alex Osborne" wrote: > > Phil Hagelberg writes: > > > "Alex Osborne" writes: > > >> But this is the same "great idea" that everyone who's ever used a lisp > > >> since the dawn of programming has come up with and despite numerous > > >> attempts, to my knowledge not a single one of them has ever taken off. > > > > > You're forgetting about Dylan! > > > > Gosh. So I am. It was created by Apple, no less. It even lets you use > > semicolons. Semicolons and Apple! That's got to be a recipe for > > success with the superficial masses. > > > > Seriously though, there's plenty of examples that show that popularity > > does not strongly depend on readable syntax (look at HTML, Ant, heck > > Perl). But from either side, an argument based on an appeal to > > popularity is sort of missing the point. I share the opinion of Mark > > Engelberg and others. I don't mind Lisp syntax because it has benefits, > > but it's definitely not as readable. The sweet expressions guy (David > > Wheeler) covers this pretty well: > > > > http://www.dwheeler.com/readable/retort-lisp-can-be-readable.html > > > > I'm not sure if sweet expressions are the answer. Or even if there is > > an answer. But for me editor support is key. I've overheard this > > conversation countlessly, about so many languages: > > > > "Oh, what's that you're coding in?" > > "Foobar. It's pretty awesome." > > "Yeah, it looks pretty nice." > > "See how you don't need to specify the blahs? The compiler just > > figures it out." > > "Nice! I might try it out. Does it work with Eclipse?" > > "Well, sort of, but ..." > > "Oh. Are there any other nice editors that work better with it? > > Netbeans maybe?" > > "Not really. There's an Emacs mode but ..." > > "Oh. Well. Nevermind then. Some other time, maybe." > > > > I know David Wheeler's retort to the suggestion of tools is: > > > > If you have to use tools to make parens less of a problem, perhaps > > you should use a better notation that removes extraneous characters > > in the first place. > > > > But I'm not sure I agree with him. I find code (in any syntax) harder > > to read without syntax highlighting. I also find it frustrating to > > write without at least basic auto-indentation. We're going to want > > tools anyway and Lisp's simple syntax and homoiconicity make it so much > > easier to write them. > > > > Funnily enough, I know people who claim Python and Ruby are horrifying. > > What do they prefer? XSLT. Yes, that XSLT. Yes, the W3C one. Really. > > > > > Why? Better editor support. Structural editing, on the fly validation, > > online previewing, XPath generation, backmapping, extensive > > auto-completion, profilers, debuggers, graph and table visualizations, > > WYSIWYG XSL-FO report generators, the list goes on and on. The language > > and syntax are quite frankly awful, but boy do they have some nice > > tools. > > > > The more I use paredit's structural editing the more I find I can't live > > without it either. The one annoyance I have with it is when I > > accidentally manage to insert a stray bracket and it gets confused. But > > maybe here there's something to be learned from the XSLT folks, even if > > their serialization format leaves a lot to be desired. Maybe paredit > > should be taken to its logical conclusion: just edit data structures > > directly, don't worry about the text. > > > > Let your editor display and edit infix math. Heck, let it show you > > complex math expressions with LaTeX formatting for the ultimate in > > readability. Let it show nesting just with indentation. > > > > When you save the file, what does your hypothetical editor do? It > > writes things out, properly indented, in that good-old relatively easy > > to parse (for both man and machine) syntax from time immemorial. > > > > Can we have our cake and eat it too? > > -- > 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 moder
Re: Parenthesis Inference
> (< x y) how do you read this literally left-to-right? I've been writing Common Lisp and Clojure for about 6 years now, and I read that "less-than x y" without any confusion. I have almost no problems with prefix notation; even arithmetic (which I was taught in infix for years) rarely trips me up when writing. Reading prefix-notation arithmetic is, of course, a joy when compared to infix (no trying to remember precedence, building intermediate tree nodes in my head, etc.). -- 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: Parenthesis Inference
ajay gopalakrishnan writes: > If possible, I would also want to see a macro that allows me to write (x < y) > instead of (< x y). Here's Chouser's infix function, which he apparently has never used since writing it: http://paste.lisp.org/display/75230 > (+ x y) can be read literally as "add x to y" > (square x) can be read literally as "squares x" > (< x y) how do you read this literally left-to-right? Ah yeah, that's one that still trips me up. Some people kind of read (< x y z) as (ascending? x y z) and you could think of the < symbol as a ramp going up so the z is above the y is above the x. Even knowing that I still confuse myself occasionally though. I don't have any problems with arithmetic or function calls, I just really expect the larger quantity to be on the "wide" side of the < wedge. -- 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: Parenthesis Inference
Precedence is an overrated thing. You dont run into that issue every day. When we do we have the support of (). So, a developer must have the option to disambiguate it when necessary, but otherwise should not have to type the otherwise redundant () all the time. (All this talk is about arithmetic expressions, so the whole () problem in LISP in general) Arithmetic expressions are rarely complicated enough to need full bracketing. And hence, it is better to have a preprocessor that fills in the required brackets when they are just redundant. For e.g. (+ (* 1 3) (/ 1 5)) It would be better if I could write it as: + (* 1 3) (/ 15) and the preprocessor should be able to convert it to (+ (* 1 3) (/ 1 5)) After all, the additional () is what the compiler needs. Not me. Above simplified version is mathematically unambiguous. This is much less noise. On Sun, Dec 20, 2009 at 2:12 AM, Richard Newman wrote: > > (< x y) how do you read this literally left-to-right? > > I've been writing Common Lisp and Clojure for about 6 years now, and I > read that "less-than x y" without any confusion. > > I have almost no problems with prefix notation; even arithmetic (which > I was taught in infix for years) rarely trips me up when writing. > Reading prefix-notation arithmetic is, of course, a joy when compared > to infix (no trying to remember precedence, building intermediate tree > nodes in my head, etc.). > > -- > 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
