Re: Funding Clojure 2010
I'm sorry, but I find the whole "donate" thing a little off-putting. I've just started looking into Clojure, and the thought that the key developer might just stop working on it doesn't exactly give me a warm fuzzy feeling. Now the evaluation will have to include looking at the community, and trying to decide if Clojure could survive Rich departing it(*). Part of it is that I don't recall any other open source software movement having dunned me for money before - and that's with having been using, writing, and contributing to such for over 20 years now. In particular, Larry Wall managed to grow Perl from a cute little report generation language he used to get his work done at Unisys to a specification rivaling CL in size without dunning users for money. Larry - and others I know who've worked on open source - did this in part by having a position with employers who realized that the tools helped them do their job, and would let them release the results unencumbered. I think Rich mentioned that sort of thing in his long posting, but it's not really something to hope for these days. But they also did other things. Many of them were regulars running tutorials on their software at Usenix meetings, which paid a pretty penny at the time. They also did talks, lectures and tutorials elsewhere for a fee. From what's been said here, Rich is an excellent speaker - possibly something like that would help? They also made money writing books and doing contract work, including custom code that was later released under an open source license. The classic example of the latter is Cygnus Solutions, which made money porting GNU to new chips while under NDA until it was sold to red hat, turning all the people working for it into millionaires. Yeah, I realize that those things don't contribute directly to Clojure, probably aren't as much fun as working on Clojure (for those of us who think of working inside LISP systems as fun), and would almost certainly cut into the development time available for Clojure. But as a potential Clojure user/developer, I'd be a lot more comfortable if the message was "By donating, you'll free Clojure development time" or maybe even the typical donationware message of "Donate to have your feature requests/bug reports given higher priority" than the current one of"I may not be able to continue developing if you don't donate". One last thought: Clojure was designed to help deal with concurrency, something no really popular language does well. Seems that the people interested in funding research into that aer the ones putting multiCPU boxes on people's desks: AMD & Intel. The Java link - as well as Sun's history of dealing with multi-cpu systems - makes Sun an obvious choice, but between the potential Oracle purchase and the financial difficulties that lead to it, that's another thing that's not exactly a warm fuzzy feeling. http://groups.google.com/group/clojure?hl=en
Re: Clojure analysis
On Thu, 17 Dec 2009 10:26:03 -0800 (PST) Santhosh G R wrote: > > You warn that you learn languages "just for the fun of it". I would be > > curious to know how much time you spent learning Clojure... > > I have been working with Scheme for the past 5 years. I think this is a critical element! > Yep, I don't have 20+ years in development; neither 12+ months in > Clojure. My learning of Clojure has been for the past 2-3 months. I expect that 5 years with Scheme is worth more than 20+ years with C/C++/Java when it comes to learning Clojure. Clojure is, after all, a LISP dialect. Once you've gotten your mind around the proper way to write programs in LISPy languages - which is a non-trivial thing - adopting to another one is fairly easy. I feel that mind-set coming back after my absence from the language as I read through the examples. The other unique features of Clojure should be relatively straightforward to deal with once you've gotten past this. > > So either you are a genius and went through Clojure faster than we > > could, learning all the features it offers, or you just skimmed the > > surface. > Neither a genius, nor did I skim through. Right. Just someone who was already familiar with programming in a LISPy environment. > I completely miss this. As I said "I am not a clojure developer. I am > a programming language enthusiast and have learnt multiple languages > with different programming paradigms; just for the fun of it. > Programming languages which I know are Java, Python, Scheme, okie- > dokie PERL, C# which for me is Java with a different library and > idiom, C, C++ including the (in)famous STL, COBOL & FORTRAN purely > because it was in my syllabus, Javascript both in its prototype and > functional forms. I have tried to be unbiased; if it exists it might > be due to my stronger background in Java, Python, Scheme." Given that list of languages, I'd suggest taking a look at Eiffel. It's imperative and statically typed, but it's a lot saner than the C++/C#/Java languages. It has a high mechanism for dealing with concurrency that make an interesting contrast to STM. It's the source of the function pre/post condition facilities that Clojure has. 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: Clojure analysis
On Fri, 18 Dec 2009 00:44:02 -0500 Luc Préfontaine wrote: > Mike, I think that the whole issue about Lisp creates a big cloud about > Clojure. Yes, it does. When I mention that, people tend to shudder. > If you sum up Clojure as being a Lisp because of what it look likes and > use only this to compare it to other > languages then you are missing the forest and looking at a single tree. I agree with that as well. My point wasn't that Clojure is "just another LISP", it's that a good grasp on writing LISP well gets you over the biggest hurdle in going from C-family languages to Clojure. > If you code in a Lisp like language using setq or set! or alike then you > can get very far away from functional > programming and end up writing procedural code with parenthesis. You > will eventually face the issues that Clojure avoids. Yup, but those were considered bad style in the places I learned LISP. If you avoided those - as I was taught to do - the code you wrote looks a lot like most of the Clojure code I've seen to date. > Clojure takes a brutal approach, forget the left-right assignment that > almost every language eventually > supports, forget variable mutations visible to everyone, forget > procedural code... > Oups these are the real show stoppers independently of the syntax used. > There's no escapes in Clojure while in other languages you can still > cheat (setq/set! and similar). Why don't you consider ref's and atoms escapes in Clojure? I can use those to write C code with Clojure syntax, just like I can use setters to write C code with Scheme syntax. The point isn't how easy/hard it is to write C code with that syntax; it's that well-written LISP looks an awful lot like well-written Clojure. > What I found non-trivial in Clojure were these "restrictions", no the > syntax. As soon as I understood > the decisions behind these choices, my mental blockage vanished. Again, I agree. The real issue isn't the syntax, it's the *mindset*. Well-written LISP is functional, and tends to avoid set, and dynamically scoped variables, and macros that capture variables, and all such things. Sure, they're available if you find yourself stuck, but they shouldn't be your first choice. > Immutable data structures, transparent iterations over a variety of > structures, lazy sequences, a workable STM implementation, > parallel processing capabilities ridiculously simple to use, huge set of > Java librairies available, easy to use, ... > These are the real features that make Clojure distinct from other > languages. All the choices made are sound and the > sum of these decisions is coherent. Nothing looks like it's been added > late to fill a gap like a nose in a face. Yes, but it's the sum of those choices that make Clojure distinct. Each of them exist in one or more other languages. My point was that of all of those features, the hardest to get used to if you haven't seen it before is the LISP-like functional programming aspect. That's a fundamental change in the way you program. The rest of them - well, they may be major improvements in the areas they touch upon, but they don't change they way you think about programming much outside of that area. Those others are like switching from playing cornerback to safety, or defensive end to tackle. Getting used to pure functional programming the first time is like switching from defensive end to wicket-keeper. > I adhere to justified critics when a rationale has been exposed > otherwise I call it (repeat "blablabla"). I wasn't claiming that the original analysis was anywhere near correct. I was responding to the claim that two or three months wasn't enough time to learn Clojure well. I don't see anything here that someone who's already got their head around writing pure functional code should have a lot of trouble with in that amount of time. Sure, there are other pure functional languages with loopholes - and even some with high-level concurrency features - but those are all even less popular than LISP when it comes to real-world programming. > To expose some rationale it implies that you understand the subject you > are talking about. If you don't then you should > be cautious about what you state or you state it conditionally. You state that as if there were hard scientific facts behind any of this. When was the last time you saw a serious scientific study of how any of these features - or pretty much any set of features - affect programmer productivity? All we've got is hearsay and personal experience, possibly gussied up as "case studies" to make them sound respectable. So would it make you happy if I point out that my conclusions are based on my experiences? I think comparing peni.. uh, years of experience is a silly thing. A fool with lots of experience is still a fool. However, I've managed to deal with every feature you mentioned above, and every feature I've found so far in Clojure, in some form or another during my career. The only one that make me have
Re: Parenthesis Inference
On Fri, 18 Dec 2009 19:07:43 + Martin Coxall wrote: > 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? Congratulations, you've just (re-invented) ABC & Python. It can work. It's very comfortable to write, as it cuts down on a lot of the syntactic noise in a program. Downsides: - Breaking the formatting of code beaks the meaning. - Cutting and pasting inside a program becomes more interesting. It can be done - emacs can rigidly indent a region that's been pasted to the right place - but you can't really fix it "by hand" later. - The size of tabs suddenly *matters*. And the biggie: - A lot of people find this significant whitespace as off-putting as the parenthesis in LISP. Not as many, but still a significant number. 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
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
defmethod question....
First, an aside: I was pleasantly surprised to find that the defmulti dispatch function could itself be polymorphic. Well, surprised isn't the right word - I half expected it to work. But it's always nice when new tools follow POLA. Which leads to a question where Clojure doesn't seem to follow POLA. I want to have a multimethod dispatch on structure types. Specifically, if I define two structures: (defstruct A :a :b :c) (defstruct B :b :d :e) I want a multimethod that uses different methods for A & B. I'd *like* to be able to write them like: (defmethod meth A ...) (defmethod meth B ...) That doesn't seem to be possible - I can't find a function that accepts a PersistentStructMap and returns the symbol passed to struct so it knows the keylist to use for the arguments. Nor could I find the magic incantation to let me use those symbol names with derive, which would let me use keywords for them. I got something working by having the dispatch function use sets of keys from the maps, but that seems fragile. Writing defFOO and FOO macros that attached the appropriate metadata to each struct seem possible, but sorta ugly. Anyone got a suggestion here? Thanks, 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: defmethod question....
On Sun, 27 Dec 2009 08:59:53 -0800 (PST)
Jason Wolfe wrote:
> > That doesn't seem to be possible - I can't find a function that
> > accepts a PersistentStructMap and returns the symbol passed to struct
> > so it knows the keylist to use for the arguments. Nor could I find the
> > magic incantation to let me use those symbol names with derive, which
> > would let me use keywords for them. I got something working by having
> > the dispatch function use sets of keys from the maps, but that seems
> > fragile. Writing defFOO and FOO macros that attached the appropriate
> > metadata to each struct seem possible, but sorta ugly.
>
> I believe this is the current way to do it. For each struct type I
> intend to use in this way, I write a
>
> (defn make-A [a b c]
> (with-meta (struct A a b c) {:type ::A}))
>
> function and use this to construct all of my struct instances.
To bad. I did think of a nice way to do this with current constructs,
but it doesn't work now :-(. However, not only does it solve my
problem, it might be useful elsewhere, so I'll describe it in hopes
that it might get further consideration.
Basically, the idea is to allow destructured argument lists in an
overloaded defn, treating them as "failed" if some of the assignment
in the argument list aren't made. So you could solve this problem with
something like:
(defstruct foo :a :b :c)
(defstruct bar :c :d :e)
(defn struct-dispatch
([{_ :a _ :b _ :c}] ::foo)
([{_ :c _ :d _ :e}] ::bar))
(defmulti struct-method struct-dispatch)
(defmethod struct-method ::foo
; work on struct foo
)
(defmethod struct-method ::bar
; work on struct bar
)
Other supported destructurings would also be possible. In the extreme
case, Oz-style unification would be really cool, but that could also
be really expensive.
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: Clojure and c++ and a bit more
On Thu, 31 Dec 2009 13:01:35 -0800 (PST) nathaniel wrote: > BTW, does anyone know what kind of GC algorithms (reference counting > or thread- based or what) are used by other Lisps? Reference-counting GC's in most LISPs are pretty much a thing of the past. Between needing to do cycle detection and having to lock the reference counters in concurrent environments, they just lose to many ways. Generational garbage collectors were big last time I looked. Given todays large address spaces, DDI might even be acceptable again. 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: Language similarities
On Fri, 1 Jan 2010 13:45:43 -0300 Angel Java Lopez wrote: > I would like to add Ada exception management. I don't know if there were > previous work on the field. Any info? I worked with Algol, but I don't > remember if something like exceptions was present those days. Any early Lisp > exception management? Try/Catch were add to MacLisp in 1972, because the previous error handling facilities (ERR/ERRSET) were being abused to get that behavior. This predates the formation of the Ada working group by a couple of years. > And namespaces. The first Eiffel had no management of name collision; it has > some sort of renaming. The first time I saw namespaces was in nineties C++, > then popularized by Java packages. Any previous work on that? Smalltalk > categories, dictionaries could be considered namespaces? Python dates back to the 80s, and namespaces are a core concept: "Namespaces are one honking great idea -- let's do more of those!" is part of the Zen of python. But Common Lisp had them for package management dating back to the early 80s. 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: Lift equivalent
On Sat, 2 Jan 2010 07:01:20 -0800 (PST) ngocdaothanh wrote: > Scala has Lift with many advanced features: > http://blog.lostlake.org/index.php?/archives/16-Web-Framework-Manifesto.html > http://blog.lostlake.org/index.php?/archives/25-Why-the-world-needs-another-web-framework.html There are definitely some good ideas there - and I agree with most of the goals. But Lift, like most other page-centric web frameworks, seems to break one of the fundamental rules of good API design: Simple things should be simple. I.e. - the simple "hello world" application requires three different files in three different languages (or two, if you consider two different XML schema to be "the same language"). This can hardly be considered simple. Why on earth should it take more than one beyond whatever it takes to connect it to a web framework? > If a similar (or better) web framework is written in Clojure, how will > it be implemented? I've spent the last few days contemplating just this question. More accurately, I've been considering how to build a web framework modeled on Seaside for Clojure. After looking at the Lift documentation, it's clear that Clojure has two major disadvantages when compared to Scala for doing this kind of thing: 1) Support for XML as a primitive type. That's just way cool. 2) The web has a natural mapping to OO concepts, so the mixed functional/oo model in Scala helps a lot. Basically, the issues I've been dealing with for Clojure become trivial with Scala. > Which existing Java libraries can be used to save time? Good question. I'm not a Java person - I looked at it a decade ago, decided it wasn't mature yet, and have been ignoring it since. I now find myself thrown into the deep end evaluating Java web frameworks to see if any can be co-opted for what I have in mind. Seems like the natural place to start is the ability to build servlets, and those can be grafted into whatever larger framework the user wants, but another two days of wading through documentation could change my mind. 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: Matt Raible: "Why is Clojure better than Scala or Groovy?"
On Fri, Jan 15, 2010 at 8:22 PM, Julian wrote: > Matt Raible - Spring Expert and Java consultant posted the following > entry to Twitter: > "Why is Clojure better than Scala or Groovy?" How about two reasons to learn Clojure instead? 1) Clojure is (a) LISP. According to Eric Raymond, "LISP is worth learning for a different reason — the profound enlightenment experience you will have when you finally get it. That experience will make you a better programmer for the rest of your days, even if you never actually use LISP itself a lot." 2) Clojure is designed from the ground up for concurrent programming. It has a number of mechanisms that improve on locks for managing state. Those come from other languages, and are liable to appear in yet more languages in the future. If you're doing concurrent programming, learning them will make you a better concurrent programmer. If you're not doing concurrent programming, consider that CPU improvement has changed from an exponential growth in raw speed to an exponential growth in number of cores. 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: Debugging in Clojure
On Fri, 22 Jan 2010 10:08:45 +0200 Miron Brezuleanu wrote: > Hello, > > On Fri, Jan 22, 2010 at 3:14 AM, ajay gopalakrishnan > wrote: > > > Hi, > > > > I usually debug by adding println statements. How can I achieve the same > > effect in Clojure. I don't think I can introduce println at arbitrary places > > to figure out at which step is the algorithm failing. > > > > I also use 'do's as others have suggested. Another trick is to add dummy > variables in lets just to be able to print something. For instance, > > (let [a 1 >b 2 >dummy1 (println "stuff") >c 3] > ...) > > (this could be done by putting the 2 for b in a do and adding the println in > the do, but that would be more invasive - with the dummy variable, it's just > add/uncomment or delete/comment out one line). > Um, I'm surprised that no one has mentioned clojure.contrib.trace. Given that Clojure is mostly functional, those "debugging" printlns will mostly be arguments to functions, or values coming out of them. The trace package lets you evaluate an expression at the repl, tracing the values in and out of a user-specified set of functions during the evaluation process. That's what I'd consider the idiomatic way to do debugging in a LISP. 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: Debugging in Clojure
On Fri, 22 Jan 2010 17:25:39 -0800 ajay gopalakrishnan wrote: > I dont mind using println. The problem is that needs to be inside a do or > when ... and that is not really part of my code. When the time comes to > remove the prints, i need to remove all these do blocks too. I can leave > them as it is I guess, but then it is not neat and non-idiomatic. From all > the replies, it seems that Debugging is going to be a pain in the Lisp style > languages. How do people in Lisp/Scheme debug it? In the REPL. That's a pretty complete debugger, all by itself. In something like SLIME, you get the ability to examine the call stack, etc. while things are running. The trace package just dumps arguments/results of functions while they run. It's a primitive tool, but better than println's in many cases: user it, then use dotrace: user> (use 'clojure.contrib.trace) nil user> (defn foo [coll] (reduce + coll)) #'user/foo user> (defn bar [coll] (map inc coll)) #'user/bar user> (dotrace [foo bar] (foo (bar [1 1 1]))) TRACE t7043: (bar [1 1 1]) TRACE t7043: => (2 2 2) TRACE t7044: (foo (2 2 2)) TRACE t7044: => 6 6 user> (dotrace [foo +] (foo (bar [1 1 1]))) TRACE t7071: (foo (2 2 2)) TRACE t7072: |(+ 2 2) TRACE t7072: |=> 4 TRACE t7073: |(+ 4 2) TRACE t7073: |=> 6 TRACE t7071: => 6 6 and so on. 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: Full Disclojure - I Need Topics!
On Sun, 24 Jan 2010 23:11:50 -0800 (PST) mac wrote: > > On 25 Jan, 06:50, Mark Engelberg wrote: > > Debugging techniques, including: > > * How to make sense of Clojure's stack traces. > > * How to use Java debugging and profiling tools with Clojure. > > +1 for this. I haven't had the energy to try any debugging or > profiling tools yet. > Would be nice with demo of something that is stand alone ie. not built > in to an IDE, since a lot of people (and me) use emacs. You want SLIME. Working properly, anyway. SLIME has the capability to look through the stack, evaluate things in context, etc. They just don't seem to work in clojure (at least, my installation, which is probably out of date). Note that this really isn't a "lisp" thing: any language with proper introspection tools can do this. I.e., Python does it, though not quite as well integrated as LISP. http://groups.google.com/group/clojure?hl=en
Re: apply macro to 'argument' list?
On Thu, 28 Jan 2010 15:08:18 -0800 Raoul Duke wrote: > > You can sometimes avoid the use of a macro by using alternative evaluation > > strategies, whether that's provided by odd calling semantics, by pervasive > > laziness (e.g., one can implement `if` in Haskell using a function), or by > > manual thunking (or the use of `delay`). If that's what you mean, then the > > answer is "yes". > > yup. and i mean "i wish lisp had that ability, rather than forcing > everything that isn't strict-evaluation functional argument passing > into compile time macros." One of the benefits of LISP - like Algol - is that it has every feature you want, just not necessarily all in the same dialect. IIRC, some Pre-CL lisps had four function definition facilities: You could either get all your arguments evaluated, or not; and you could get your arguments bound to variables, or just get the list of them. The former turned into macros, because that was 99% of the use cases; the former turned into extended argument processing. http://groups.google.com/group/clojure?hl=en
Question: Clojure & concurrency in large-scale problems.
On Thu, 28 Jan 2010 14:56:05 -0800 (PST) Francis Lavoie wrote: > I found that blog post that make a comparison between python and > clojure. > http://www.bestinclass.dk/index.php/2009/10/python-vs-clojure-evolving/ Note that the author has several of his facts wrong about Python, and looks at non-Pythonic python. Read the sequel to correct the latter. The one point he is right on is that Python pretty much sucks when it comes to threading. The best available high-level tool is the queue library, which is just CSP in different clothing. Worse, the interpreter doesn't multi-thread, so only one thread can be in the interpreter at a time. The Pythonic view is that threading is generally bad idea, because trying to do concurrent programming with locks is like trying to do construction work with a toothpick. You're better off using processes and IPC, so you avoid all the issues surrounding locking. I've found that this works fairly well in practice - at least when your problems are to big to fit on a single system. I've rebuilt thread-based Python systems to use processes, and gotten better performance along the way. Clojure avoid those problems by providing better tools. Which is why I keep trying to find time to do some work in clojure. Except that, well, you really *don't* avoid the problems of locking; you just move them to a different place. I.e. - if one process is producing a file, and one or more other processes are waiting to consume it, and possibly a few more are waiting to reuse the input data for that process - how do you synchronize them? Answer: locks. Which brings me to my question: how does clojure deal with concurrency at the inter-process level? At the inter-system level? Are their distributed versions of refs & atoms and the like available somewhere? I know it works really well working with hadoop and the like - but what about if I wanted to build hadoop in clojure? thank http://groups.google.com/group/clojure?hl=en
Re: Prepping clojure for packaging (was: Re: Clojure for system administration)
On Sat, 6 Feb 2010 18:25:47 -0800 (PST) Constantine Vetoshev wrote: > On Feb 6, 1:06 pm, Peter Schuller wrote: > > But the practical issue > > remains that if I want to write some software that I want sysadmins in > > various situations to want to use effortlessly (in my case, a backup > > tool), problems like these do get in the way of choosing Clojure. > > > > Maybe uberjars are the pragmatic approach after all. But then what > > about GPL libraries and similar license hassles? > > I can't comment on the licensing problem, but could you expand on what > exactly you don't like about packaging jars (as uberjars or separates) > and distributing them as part of your application? If you distribute > your app with precisely the jars you tested with, you don't have to > worry about subtle incompatibilities sneaking in. Except for obviously > bloated software (e.g., JBoss), Java jar files are relatively small. > When you package for Debian, put the jars in /usr/share/my-awesome-app/ > jars, put in a dependency on sun-java-1.x, and provide a wrapper shell > script to start the whole thing (your classpath just includes the > stuff you provided). For the installing admin, your package is just an > "aptitude install my-awesome-app" away, and it just pulls down a JVM > dependency. Simple, and fairly lightweight. It means that your software isn't playing well in the system. You install a duplicate copy of everything - or nearly everything - you require, basically creating a "weird parallel universe" just for your application. > I stopped using Python and Ruby and Perl partly because the packaging > situation for all those languages is a horrible mess. For example, if > you write a Ruby app, you are highly likely to run into trouble > packaging it even for a recent distribution because your dependencies > may not have been packaged or made available as rb-*.debs in the > official repository. Or, rb-*.debs exist, but provide an incompatible > version of the library you need. Ubuntu and Fedora may ship different > versions of common gems, so you can't even code against an obvious > lowest common denominator. (To make matters worse, "gem install", > "easy_install", and "cpan -i" all create weird parallel universes of > packages which may cause conflicts with system-provided packages. > Python's virtualenv helps mitigate the problem to some extent.) The first part isn't an issue with the python/ruby/perl packaging software, it's an issue with the OS packaging systems providing out-of-date or no versions of things you need. That's pretty much why I've punted on Linux as a development environment - I couldn't find a distribution that had up-to-date versions of the tools I wanted available. This second part also sounds like a problem with the OS packaging system, not python, ruby, cpan, etc. FreeBSD solves these problems by making the packaging system cpan/easy_install/etc. aware, so that when you install an OS package, it goes through those systems, and when you install something with those systems, the OS will notice them and let them satisfy the dependency on things that need it. I suspect that pkgsrc does the same, given how modular it is. > C programs have it easier, because the overwhelming majority of > commonly used libraries are packaged and available in recent > distributions, and I have rarely had trouble with just writing against > a slightly older version of a library. It's perfectly reasonable to > dynamically link against libjpeg and make a note of a libjpeg > dependency in the package descriptor file. You've had better luck than I've had. Creating a truly static binary using a modern GCC is nearly impossible, given that it wants to dynamically link part of it's support code. I inevitably find that critical shared libraries either aren't in the packaging system, or are so far out of date the author lists them as "DO NOT USE". I frequently find that even when the available tools are only a little bit out of date, critical bug fixes or features aren't available in that "slightly older library". Again, why I don't use Linux as a development platform. > In short, I think that the Java and Clojure way of packaging software > make life much easier for programmers, package maintainers, and > administrators, not harder. Making applications self-contained helps > avoid dependency hell at packaging and deployment time, not to mention > during development. It's a bit wasteful to have multiple copies of > log4j or whatever floating around, but I'd rather waste a few > gigabytes of disk space on duplicates than deal with system-wide > classpaths. I think of this as the "Windows" way of packaging, though calling it the "proprietary" way may be more accurate. That solution works for Python, Ruby, C - pretty much anything. You just bundle up every dependency you can get a license for, cram it all into the application directory, and distribute that along with a binary that arranges to use all those things. It's esse
A couple of namespace questions
I've got two questions about namespaces; one is pretty clojure-specific, the other possibly more related to java's classpath stuff. First, is there either a way to use names that exist in clojure.core? I.e., if wanted variable called map, can I get it somehow? If not, is there an idiom for such names, akin to Python's use of a postfix _ for variables whose names would otherwise be keywords? Second, is there a way to refer to a relative namespace? I.e., if I'm in org.mired.project.foo, is there some way to refer org.mired.project.bar without having to type entire path in again? Thanks 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
Question about how I got run?
So, the next question - possibly another name-space question. Is there any way to tell if inside a .clj file if it was invoked as a script by clojure.main, vs. being loaded for use elsewhere? What I'd like to do is make my unit tests usable in two modes: While working on a bug, I'd like to be able to load them in the REPL to rerun the subset of interest - possibly just the test which is failing. However, I'd also like to be able to feed the script to clojure.main with something like "clj test.clj" and have it run them all. I have the latter working - I just provide the appropriate run-tests form at the bottom of the unit tests file. However, this causes the tests to be run whenever I load them, which I'd like to avoid. I could have an arg check of my own, or possibly the value of some of the hooks in clojure.main, but those don't feel quite clean. So the question: is there a good way to distinguish being run as a script from being loaded from the repl (or by another file, for that matter). Thanks, 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: Question about how I got run?
On Sun, 14 Feb 2010 22:32:45 -0800 (PST) ataggart wrote: > On Feb 14, 6:47 pm, Mike Meyer 620...@mired.org> wrote: > > So, the next question - possibly another name-space question. > > > > Is there any way to tell if inside a .clj file if it was invoked as a > > script by clojure.main, vs. being loaded for use elsewhere? > No. To bad. It's really handy, especially as it starts trickling into system modules. You get one file that provides the simple command line usage plus functions that allow user to get to advanced usage. It also restores functionality that appears to be available in Java but not clojure, in that properly written scripts can then be invoked either from the command line, or as a function by an external caller. Wouldn't be hard to do, either. Just bind *script-name* (or some such) to the path in script-opt, and let the client decide if it's the same as *file*. > > What I'd like to do is make my unit tests usable in two modes: While > > working on a bug, I'd like to be able to load them in the REPL to > > rerun the subset of interest - possibly just the test which is > > failing. However, I'd also like to be able to feed the script to > > clojure.main with something like "clj test.clj" and have it run them > > all. > > java -cp path/to/clojure.jar:path/to/your/src clojure.main -e "(run- > tests 'your.namespace)" This doesn't work - run-tests isn't defined, you have to load clojure.test to get it. Even if you wrap the clojure invocation up in a shell script, it's still sort of ugly. 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: Question about how I got run?
On Tue, 16 Feb 2010 11:13:28 -0800 (PST) Daniel Werner wrote: > On Feb 16, 2:12 am, Mike Meyer 620...@mired.org> wrote: > > Wouldn't be hard to do, either. Just bind *script-name* (or some such) > > to the path in script-opt, and let the client decide if it's the same > > as *file*. > It would indeed be helpful if clojure.main bound a Var to the name of > the .clj file being run, sort of like argv[0] in C. Like Michał > suggested, there's the gen-class solution, but I personally tend avoid > AOT-compiling Clojure code, which rules out gen-class. I was surprised that *command-line-args* didn't include the script name, which would have solved my problem. Of course, my usage is a special case of the more general Unix trick of having programs vary their behavior based on the name they were invoked with. And I just realized another need for wanting the program name: how do I report the program name in error messages? That's probably what argv[0] is used for more than anything else. Maybe the concept "name the program was invoked with" doesn't make sense in a Java environment, what with having to have shell wrappers around AOT code before it can be run anyway. Since clojure code can be run as script, it might make sense there - if people distribute applications a scripts instead of AOT code. 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: Question about how I got run?
On Tue, 16 Feb 2010 02:35:03 +0100 Michał Marczyk wrote: > On 16 February 2010 02:12, Mike Meyer > wrote: > > To bad. It's really handy, especially as it starts trickling into > > system modules. You get one file that provides the simple command line > > usage plus functions that allow user to get to advanced usage. It also > > restores functionality that appears to be available in Java but not > > clojure, in that properly written scripts can then be invoked either > > from the command line, or as a function by an external caller. > > You can use gen-class to make your script runnable by Java. Just be > sure to provide a -main function (or prefix-main, if you change the > method prefix). Might it be worthwhile tweaking clojure.main to run such a function if it's found in a script that it's executing? 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: STM with deeper structure
On Sat, 20 Feb 2010 17:27:34 -0800 (PST)
"sailormoo...@gmail.com" wrote:
> Hi :
>
> Say, I have a (def *a (ref {:b [{:c 5}]})) .
> I want to add 1 to the :c inside, how would I write?
> (Note: the value 5 is in (:b 0 :c), while 0 is the array index)
>
> (dosync (alter *a __ )) ; please help me fill the blank.
>
> Someone mention I can use the zipper library or the walker library,
> but after I checked I still have no idea how to make it.
Your blank should be update-in [:b 0 :c] inc, so the whole thing is:
(dosync (alter *a update-in [:b 0 :c] inc))
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
Map transmogrification functions?
In working through a recent project, I realized that Clojure has a nice collection of functions for working with maps. However, it doesn't seem to have analogues of some of the important sequence tools (filter and map most noticeably, probably others). Given that map will take a map as a collection argument - generating a sequence of entries - it isn't hard to write those analogues. Turning them back into maps is sort of ugly, because there doesn't seem to be a natural way to turn a sequence of entries into a map (someone correct me?), but still not hard. There are some issues with doing this in general - do you use keys, values or entries from the map? If you're modifying instead of filtering, do you modify the key, value or entry? Rolling your own, you can decide what you need when you write it, but trying to generalize them all might get ugly. The nasty part of all this is that I seem to have to specify the resulting map type in the function that turns the sequence of entries back into keys. I.e. - if I want to run the same filter over both a hash-map and a sorted-map and need to preserve the sortedness, I either need two map filter functions, or have to turn the hash-map into a sorted-map after filtering it. Hmm - there doesn't even seem to be an easy way to convert between the two map types. So, the questions: what have I missed in clojure & contrib: Is there a function that accepts a sequence of [key value] vectors and creates a map of some sort? Is there a sane way to say "please give me a creator of the type of this object"? How about a function that accepts a hash-map as an argument and returns a sorted-map of the entries? Thanks, 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: Map with multiple keys?
On Tue, 23 Feb 2010 16:09:29 -0800 (PST)
Base wrote:
> Hi All -
>
> So this may be an extraordinary dumb question (even for me...) but is
> there such a thing as a map with compound keys?
>
> For example lets say that I have a data set that looks like
>
> CatGender item-Id's
> 1M 1 2 3 4 5 6 7 8 9
> 1F 2 4 5 6607 43 54 234
> 2M 1 2 3 4 5 6 7 8 44 6 23 44
> 2F 2 4 6 8 10 12 17 38 55
> 3M 1 2 3 4
> 3F 2 4 6 8 33 45 10 12
> ...
>
> where I would want to do a look up on both the category and the
> gender.
>
> I could do map - in - map, or do something like a (str cat gender) to
> amalgamate 2 fields to set the key but I was just wondering if this
> even existed.
>
> How do you all model this data?
You can use a map-in-map structure, though given that your maps always
have the same two keys, a struct might be a better option:
(defstruct cat-entry :male :female)
{1 (struct cat-entry [1 2 3 4 5 6 7 8 9] [ 2 4 5 6607 43 54 234]),
2 (struct cat-entry [1 2 3 4 5 6 7 8 44 6 23 44] [ 2 4 6 8 10 12 17 38 55]),
3 (struct cat-entry [1 2 3 4] [2 4 6 8 33 45 10 12])}
and access the fourth mail like so ((data 4) :male). Or even, with
(def M :male) ((data 4) m).
Or even store vectors in the map:
{1 [[1 2 3 4 5 6 7 8 9] [ 2 4 5 6607 43 54 234]]),
2 [[1 2 3 4 5 6 7 8 44 6 23 44] [ 2 4 6 8 10 12 17 38 55]]),
3 [[1 2 3 4] [2 4 6 8 33 45 10 12]])}
which makes the access look like (assuming appropriate definitions for
M and F): ((data 4) M)
Alternatively, amalgamation works fine, though you probably want to
amalgamate with vector instead of str. That prevents inadvertent
collisions in cases where the elements in are similar (not a problem
for you). Again, assuming appropriate definitions for M and F:
{[1 M] [ 1 2 3 4 5 6 7 8 9],
[1 F] [ 2 4 5 6607 43 54 234],
[2 M] [ 1 2 3 4 5 6 7 8 44 6 23 44],
[2 F] [ 2 4 6 8 10 12 17 38 55],
[3 M] [ 1 2 3 4],
[3 F] [ 2 4 6 8 33 45 10 12]})
And access looks like (data [4 M]).
Just choose whichever representation is easiest to manipulate.
I just posted a blog entry that uses both techniques - maps in a map
indexed by a vector of words - in solving an interview problem at
http://mired.wordpress.com/2010/02/23/phrase-groups-in-clojure/.
> I was using Incanter's data set $where statements for this but have
> been having performance issues with it and am trying to speed up this
> operation. I have a data set with around 130,000 rows so a map would
> really help pare things down in a hurry...
In that case, you may want to call hash-map on a lazy sequence
extracting the rows from a data set.
> Sorry for the *really bad* question!
It's not really bad. Being able to use arbitrary things for map
indexes is surprising the first time you encounter it.
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: let and nesting
On Thu, 25 Feb 2010 16:28:05 -0800 (PST) kuniklo wrote: > One of my least favorite things about common lisp was the degree of > nesting it required for sequential variable definitions. For common > code like this: > > (let (a vala) > (b valb) > ... do something with a & b... > (let (c (fn a b)) >(d (fn a b)) > ... do something with a, b, c, d... >(let (e (fn ...)) > (f (fn )) You might want to check out let*. > etc. You eventually get a very deeply nested function simply because > the values of variables assigned later in the code depend on values > determined earlier in the code. From what I can this is also the case > in clojure, correct? Nope. Clojure's let is like CL's let* > In contrast, the python/ruby/java approach (which I realize has its > own warts). > a = 1 > b = 2 > c = a * b > d = a + c > e = func(d) In clojure, you'd do: (let [a 1 b 2 c (* a b) d (+ a c) e (func d)] (calculation using a, b, c, d and e)) > I'm new to clojure so I'm wondering - are there idiomatic ways of > reducing the degree of scope-nesting let incurs or do people just tend > to try to avoid that kind of code with smaller sub functions etc? Anything particularly wrong with the example I gave you? 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: Extract tested stuff from REPL, can i ?
On Sat, 27 Feb 2010 03:42:04 -0800 (PST) uap12 wrote: > Hi! > I have installed ClojureBox with Emacs. > I test to write stuff, direct in the REPL, so is there som easy way of > get the function defined out, > i know i should write them in a src-file first but i would be nice > when just testing to be able to > do the other way to.. You can go back to where you wrote them, and cut them to paste into a source file. On the other hand, if you write them in a source file with clojure-mode and slime, then C-c C-c will send the current defn to the slime REPL and C-c C-z will switch to the repl so you can run it. That's almost as convenient as editing in the buffer, and much easier in the long run. 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: difference between if/when
On Sun, 28 Feb 2010 14:18:50 -0800 Richard Newman wrote: > This is an interesting point, though -- does "unless" communicate > something slightly different to* "when not", despite being > functionally identical? And is the distinction important enough to > justify a move towards a confusing Rubyesque undergrowth of equivalent > syntactic sugar? No, no, a thousand times no! Having seen the results of both TMTOWTDI and TOOWTDI, I vote for the latter, every time! This is fundamentally a documentation issue. Yes, a few dozen "Clojure for YXZZY programmers" help a little. But even better would be enhancing find-doc so that you could find "obvious aliases" like those. I.e. - (find-doc "unless") should turn up both if-not and when-not. > Probably not, although `unless` is really no different to `when`: they > both eventually expand into `if` forms. I'm not entirely sure where > the line should be drawn, or why I draw it where I do... inc 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
Milters?
Anyone doing milters in clojure? Are they reasonable to do on the JVM? -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- 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: objects, interfaces and library design
On Wed, 3 Mar 2010 09:47:09 -0800 (PST) cageface wrote: > I've been reading through the examples of "OO" in clojure using multi- > methods and they certainly seem very flexible and powerful. I'm > wondering, however, how people handle interface & library design. If > people can implement "objects" as maps, structs, or just about > anything else you can discriminate on via a dispatch function, how do > you handle code reuse and sharing of libraries. If we're all using our > own home-grown OO systems how do we communicate? I hope that most people aren't using home-grown OO systems for most of their problems - especially given that maps are almost enough for a prototype-based system to start with. That would be working "against the grain", as it were. While it would be nice to have a standard OO system for the cases where that's appropriate, those should be relatively rare. 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: Some basic guidance to designing functional vs. state parts of app
On Wed, 3 Mar 2010 14:20:56 -0800 (PST) Armando Blancas wrote: > > > On Mar 2, 8:34 pm, Sophie wrote: > > Do I design a single "World" ref whose state changes with time to > > different worlds, so adding a new Applicant or even adding a new Skill > > to an existing Applicant results in a new World value? Or is it better > > to have an "Applicants" ref and a "Jobs" ref that refer to different > > sets of those er.. things? > > > > It's simpler to use refs close to the object that will change; that > makes > the code to mutate the value simpler; if the world is the only mutable > object, > then the code to change something in there will increase with the > depth > of the mutation. I'm not sure it's simpler: update-in makes reaching deep into a structure to create a new structure with that one change in it easy, and is probably more efficient than trying to do the same thing by hand. More importantly, if you break your refs up into smaller objects, you should get better concurrency, as you can change two such refs in two different threads without a problem. If you put the two in a structure in the same ref, then you can't update one while the other is being worked on. 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: Data manipulation question
On Fri, 5 Mar 2010 16:07:55 -0800 (PST)
Base wrote:
>
> Hi all -
>
> I am trying to transofrm a data structure and am kind of stuck.
>
> I currently have a list of maps
>
> ( {:animal "dog cat bird" :sound "woof meow chirp" :number-of-feet "4
> 4 2"}
> {:animal "horse" :sound "ne" :number-of-feet "4"}
> {:animal "wolf pig" :sound "howl oink":number-of-feet "4 4"} )
>
> and want to trasform it to:
>
> (
> ({:animal "dog" :sound "woof" :number-of-feet "4" }
>{:animal "cat" :sound "meow" :number-of-feet "4"}
>{:animal "bird" :sound "chirp" :number-of-feet "2"})
>
> ({:animal "horse":sound "n" :number-of-feet "4"})
>
> ({:animal "wolf" :sound "howl" :number-of-feet "4"}
>{:animal "pig" :sound "oink" :number-of-feet "4"})
> )
How about this?
(use '[clojure.contrib.str-utils2 :only [split]])
(defn cook [animals]
(map (fn [{:keys [animal sound number-of-feet]}]
(map #(hash-map :animal %1 :sound %2 :number-of-feet %3)
(split animal #"\s")
(split sound #"\s")
(split number-of-feet #"\s")))
animals))
which gives:
(({:number-of-feet "4", :sound "woof", :animal "dog"}
{:number-of-feet "4", :sound "meow", :animal "cat"}
{:number-of-feet "2", :sound "chirp", :animal "bird"})
({:number-of-feet "4", :sound "ne", :animal "horse"})
({:number-of-feet "4", :sound "howl", :animal "wolf"}
{:number-of-feet "4", :sound "oink", :animal "pig"}))
--
Mike Meyer 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: Long post with some questions about getting started...
On Fri, 19 Mar 2010 07:21:50 -0700 (PDT) Sean Devlin wrote: > > I'm having an interesting (to me) question around a using REPL. Once > > it's shut down, where does this code go? I feel like I'm in the old > > TRS-80 volatile coding days where you write some code, and if you shut > > down you've lost it all. Is this the case? So how do you save your > > code in a REPL? I understand these could be unique per editor so I > > understand if you get irate at me for asking such a silly question... > > To answer your question about the REPL, yes everything is lost when > you close it. However, this isn't the whole story. Once you create a > new project w/ Enclojure, you can send code from a file too the REPL > either from a context menu or keyboard shortcut (Alt+E in windows). > It's standard practice to edit your file, and send the code to the > REPL dynamically. This gets you out of the 1960s and back to 2010. Most clojure-aware environments will have similar functionality: SLIME+SWANK, Eclipse, etc. It's not clear this really gets you out of the 60s, though - it's been standard practice for (file-based *) LISP development for as long as I can remember. Nuts, it worked with Scheme2C and mg on the Amiga in the 80s. 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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
Re: Long post with some questions about getting started...
On Fri, 19 Mar 2010 18:26:24 -0700 Terje Norderhaug wrote: > > > > *) InterLISP and some others were more like SmallTalk, or MS BASIC, in > >that you edited code at the REPL and saved the entire > >workspace. That did add power - I've never seen a file-based LISP > >whose error handler would let me fix the code on the fly and > >continue execution. > > Possibly I am misunderstanding So to clarify: by "file-based LISP" I mean one where the code is stored in text files. If it's read in and parsed, you can still get to the S-expressions, but there's generally no easy way to get them back into the text file; the REPL is just a REPL. The alternative is residential systems (InterLISP is the one I'm most familiar with), where the source code lives in workspaces, which are basically virtual machines running lisp code. To save your work, you saved the memory image of the vm; ascii output of the source was for reading, not editing. The file-based systems I'm used to would let you examine the code in a break, and chose a return value for any arbitrary function on the stack. You generally couldn't edit the code that was being executed. You could reload functions in a break, but that generally didn't replace bindings that were instantiated on the stack. The workspace versions let you edit the code in the workspace, changing it in situ. You could even save the workspace at that point. > "I've never seen a file-based LISP > whose error handler would let me fix the code on the fly and continue > execution" but that sounds like common practice in the REPL break > loop for many lisps. More likely is that I'm just out of date. I obviously haven't seen every LISP around, and in particular quit paying close attention to LISP systems in the early 90s. Clojure brought me back to that world. If that's the case, I have to wonder how many of them grew features comparable to masterscope, the programmers assistant, or even DWIM? 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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
Re: separating ui and content in clojure
On Sat, 20 Mar 2010 08:11:49 -0700 (PDT) strattonbrazil wrote: > I'd like to separate my ui Swing/JOGL from the content, so my code is > relatively unaware of the UI around it. For example, I create a > global context that holds on my content. I then make a UI that when > the user does some interaction like a mouse click or drag, the UI > creates a new context. My OO instincts would be to create a context > and pass it to all my UI objects that receive events and mutate them, > but if I'm dealing with an immutable class if I pass it to each UI > object, when one UI object makes a new context, it isn't reflected in > the other UIs. Basically I want all UIs pointing to the same context > and each UI being able to create a new context that each UI points > to. It seems that when one UI updates the global context reference > with a 'def', the others are still using the old one. You need to update shared data, and that doesn't seem avoidable. In clojure, you do that with either a ref or an atom holding the data, depending on how you need to update it. This will make it thread safe if/when you start running your UI objects in different threads. 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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
Re: separating ui and content in clojure
[Context recovered from top-posting.]
On Sun, 21 Mar 2010 10:31:58 -0700
Josh Stratton wrote:
> On Sat, Mar 20, 2010 at 8:51 AM, Mike Meyer
> wrote:
> > On Sat, 20 Mar 2010 08:11:49 -0700 (PDT)
> > strattonbrazil wrote:
> >
> >> I'd like to separate my ui Swing/JOGL from the content, so my code is
> >> relatively unaware of the UI around it. For example, I create a
> >> global context that holds on my content. I then make a UI that when
> >> the user does some interaction like a mouse click or drag, the UI
> >> creates a new context. My OO instincts would be to create a context
> >> and pass it to all my UI objects that receive events and mutate them,
> >> but if I'm dealing with an immutable class if I pass it to each UI
> >> object, when one UI object makes a new context, it isn't reflected in
> >> the other UIs. Basically I want all UIs pointing to the same context
> >> and each UI being able to create a new context that each UI points
> >> to. It seems that when one UI updates the global context reference
> >> with a 'def', the others are still using the old one.
> >
> > You need to update shared data, and that doesn't seem avoidable. In
> > clojure, you do that with either a ref or an atom holding the data,
> > depending on how you need to update it. This will make it thread safe
> > if/when you start running your UI objects in different threads.
> >
> An atom seems appropriate after reading up on it, but documentation
> seems a little scarce. Reading about atoms on the clojure site gives
> a very small example using just a {}. I've tried piecing it together
> using a struct but am getting
>
> Exception in thread "main" java.lang.IllegalArgumentException: Key
> must be integer (start.clj:0)
>
> Can atoms be only certain types?
>
> let [context (atom (create-context))] ; create-context returns a context
> object
> (def canvas0 (create-canvas 0 context)) ; passing the atomized
> context to a struct
> )
Atoms can only be one type: atom. They can hold objects of arbitrary
type. Context is an atom. If create-canvas expects some other type,
it won't work. You have three options: 1) create-context doesn't
modify the context; just pass in @context to pass in the context the
atom holds. 2) create-context modifies the context, so either a) it
needs to be modified to expect an atom and change it appropriately, or
b) it needs to be modified to return the new value of the context so
it can be used with one of the atom-changing functions.
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
To unsubscribe from this group, send email to
clojure+unsubscribegooglegroups.com or reply to this email with the words
"REMOVE ME" as the subject.
Re: Can I GPL my Clojure project?
Ok, I'm not a copyright lawyer. I have spent a lot of time over the past three decades looking at licenses, and talking them over with lawyers, so I'd have no qualms acting on the advice below. But if you're serious about this, you need to talk to a real copyright lawyer. On Sat, 27 Mar 2010 18:44:15 -0700 (PDT) Eugen Dück wrote: > > 1) Can I GPL my Clojure project? > 2) Can I GPL my Clojure project that also uses clojure-contrib? Yes to both of those. They use the same license - the Eclipse Public License. So the answers will be the same in all cases. In particular, FLOSS license derive their power from copyright. Until you start making *copies* of things that are covered by them, they don't apply. Your Clojure code only has your copyright on it, not anyone elses. So you can license and distribute your code however you please. > 3) Can I ship clojure.jar (and clojure-contrib.jar) with my GPL app? Yes. The mere act of including GPL'ed software on the media doesn't cause create a derived work, so they can have distinct licenses. For example, BSD-licensed systems regularly include GNU sources and binaries in the distribution (usually distinguished so commercial vendors can easily create GPL-free distributions). > 4) Can I AOT clojure-contrib.jar (or parts of it) and ship the > generated classes with my GPL app? If I understand the AOT process correctly (I'm new to the Java world), the answer is no. My assumption is that this creates a single jar that you'd then ship, so the same rules would apply that apply to binaries: it's a derived work, so you can only ship it by complying with both the EPL and the GPL, which the FSF says isn't possible (see http://www.gnu.org/licenses/license-list.html). And to answer the critical question you didn't ask: 5) Can I distribute a jar file for my Clojure project under the GPL? No. When you compile your code, code from clojure (and clojure-contrib if you use it) will be included in the resulting jar file. In particular, any macros you use will expand in place in your code. Either of these make it a derived work, so you have to comply with both licenses, which you can't do. Possibly you could use the LGPL; this is sort of backwards from it's intended use, which is to allow binaries built against LPGL'ed libraries to be distributed without requiring the source to be GPL'ed, so I'm not sure. You can, of course, distribute the jar file and sources under different licenses. Depending on your reasons for wanting to use the GPL, that may or may not meet your needs. 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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
Re: Can I GPL my Clojure project?
[Format recovered from top posting.] On Mon, 29 Mar 2010 17:36:42 -0400 Aaron Cohen wrote: > On Mon, Mar 29, 2010 at 5:24 PM, Phil Hagelberg wrote: > > On Sat, Mar 27, 2010 at 9:55 PM, Mike Meyer > > wrote: > >> 5) Can I distribute a jar file for my Clojure project under the GPL? > >> > >> No. When you compile your code, code from clojure (and clojure-contrib > >> if you use it) will be included in the resulting jar file. In > >> particular, any macros you use will expand in place in your > >> code. Either of these make it a derived work, so you have to comply > >> with both licenses, which you can't do. > > I think this only matters if you're shipping .class files by way of > > AOT. If you ship a jar full of .clj files then you're distributing > > before anything is compiled, so the derivation is done by whoever runs > > the code. In that case you shouldn't be responsible. Yup, that would work. If your jar file only contains your own code, then your license is the only one that needs apply. As I said, I'm new to java; I still think "shared library" when I hear "jar file" - apparently incorrectly. > If you're distributing the jar file you own copyright to it and you > can grant any kind of permissions you want. So you may need to grant > your user's explicit permission to link your code against specific > jars (such as Clojure and Clojure-Contrib), but it's hardly > impossible. Well, you own *a* copyright to it. However, if it includes any other works, then the copyright holder for those works *also* owns a copyright to it. In which case, you're only allowed to distribute it if all copyright holders agree, which for things covered by floss licenses means the licenses are compatible. If you compiled clojure code to put into the jar, then you've incorporated parts of any macros you use. > The GPL v3 has a specific recommended form for adding "Additional > Permissions", it's also possible if you stick to GPLv2, but you're a > little more on your own when it comes to the proper way of saying > precisely what you intend. See > http://www.gnu.org/licenses/gpl-faq.html#GPLIncompatibleLibs Always possible. > I also think that it's possible that "clojure.jar" might fall under > the "System Libraries" exception that is built into both GPLv2 and > GPLv3, but I'm no lawyer. I doubt clojure-contrib would. I suspect functions would, but macros wouldn't. The bison templates weren't (until they moved to LGPL), even though they just provided APIs that matched awk APIs (and prevented me from distributing an otherwise free stat package around '98...). With Macros, like the template, actual bits of the authors code *must* be compiled into the derivative product, whereas libraries could - at least in theory - be replaced by a different implementation of the same library without ever having access to any source but the caller. 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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
Re: Clojure Concurrency Screencast Available
On Tue, 20 Apr 2010 06:47:05 -0700 (PDT) Mark Hamstra wrote: > Craig, I'm not Craig, but he's not answered yet, so... > I enjoyed you presentations, but I have a bit of a tangent question. > I'm still new to slime, so it's not a comfortable environment for me > yet. What I am wondering is how exactly, when operating with the > split code and repl buffers, you are getting code buffer expressions > to evaluate in the repl? Is this a customization, or am I missing > something basic? This is pretty basic. There are commands for sending various bits of code from the code buffer to REPL. They are a standard part of slime, not clojure-specific. Most useful to me are C-M-x, which ships the def around the point to the repl, and C-c C-r, which evaluates the active region. Others can be found with C-h M in the code buffer, which brings up the documentation for the buffer mode. 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: Datatypes and Protocols update
On Sat, 24 Apr 2010 06:51:18 -0700 (PDT) MarkSwanson wrote: > >> You can no > >> longer take a generic approach to information processing. This results > >> in an explosion of needless specificity, and a dearth of reuse." > > > For this reason, I've always found appealing languages which let you > > optionally write getter/setter methods that "hook into" the standard > > field access syntax. This lets you start out with your fields public, > > and let your clients use the standard field access "interface". > > Later, if you realize you need to do something special, you can easily > > add a custom getter without breaking your clients. > > I'd argue that leaky abstractions like getter/setter methods are evil, > and a good article (from a Java/imperative perspective) describing why > can be found here: > http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html?page=1 I think his fundamental assumption - that getter/setters reveal details of the implementation - is wrong. They *can* do that, and possibly in the Java world they normally do do that. But properly used, attributes reveal information about the *state* of the object, not about the implementation. Classic examples would be a queue object with a "length" attribute, or a financial account object with a "balance" attribute. Neither of those attributes reveal information about the implementation of the objects in question. They both reveal information about the state that some client could find useful. They are both values that, if not directly available from the object should be calculated by the object, as calculating the value requires knowledge about the implementation. > I think that the quote above from Rich is another good description of > why getter/setter methods are bad from a functional perspective. Given that your attributes that aren't just random variables from the implementation, but are reasonable things for a client to want to know, then the unattributed inner quote nailed it: languages that don't distinguish between reading the value of an attribute and invoking a zero-argument method - or at least allow you to make the latter look like the former - hide that specificity and encourage reuse. 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
Funcalls vs. lists (Was: Clojure Concurrency Screencast Available)
On Sun, 02 May 2010 13:06:56 +1000
Alex Osborne wrote:
> e writes:
> > Can you imagine how disruptive it would be at this point to do it the
> > other way around? If you were starting out today without any Lisp
> > baggage, it seems TOTALLY obvious to me that lists would have been (1
> > 2 3), and the *calling of a function* would have been the different
> > thing ... now that these other data structures represent themselves
> > symbolically (vectors, sets, maps).
> Interesting, although in the case of idiomatic Clojure it's actually
> very rare to want to use a list literal. Most of the places you'd use a
> list literal in other lisps, a vector probably makes more sense in
> Clojure.
That was my conclusion as well - pragmatically, you want the shorter
construct for the more common use case.
> I'm also not sure the code-is-data thing works so well when
> you reverse quotation like that as it means you'd have quotes on every
> nested level instead of just the outside, which would make macros more
> difficult to write (at least without any other changes), but I may be
> misunderstanding your idea.
I thought that as first, but then realized that you'd still want quote
even if you had this change, because quote is more than just a
symbolic representation of the list. It stops the evaluation of the
contents of the list, which the other symbolic representations don't
do. So [1 2 3 (print :hello)] will print the keyword :hello, then
return [1 2 3 nil], but '(1 2 3 (print :hello)) doesn't print
anything, and returns a list with four elements - 1, 2, 3 and the list
with two elements, the symbol print and the keyword :hello. This
should be compared with '[1 2 3 (print :hello)].
To get behavior similar to the vector constructs, you want to use
list, which works like vector, except returning a list instead of a
vector: (list 1 2 3 (print :hello)). It seems that what's missing here
is a syntax for (list. I'm not sure it's needed, as it never appeared
in LISP, but #[ seems to be the logical candidate:
{ - hash-map #{ - hash-set [ - vector#[ - list
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: Funcalls vs. lists (Was: Clojure Concurrency Screencast Available)
On Sun, 2 May 2010 14:52:17 -0700 (PDT)
Jarkko Oranen wrote:
> On May 2, 11:14 pm, Mike Meyer 620...@mired.org> wrote:
> > On Sun, 02 May 2010 13:06:56 +1000
> > To get behavior similar to the vector constructs, you want to use
> > list, which works like vector, except returning a list instead of a
> > vector: (list 1 2 3 (print :hello)). It seems that what's missing here
> > is a syntax for (list. I'm not sure it's needed, as it never appeared
> > in LISP, but #[ seems to be the logical candidate:
> >
> > { - hash-map #{ - hash-set [ - vector #[ - list
>
> Hmmh. I haven't read the discussion very carefully but it seems there
> might be a fundamental misunderstanding here somewhere.
No, just a failure to look past syntax at the implementation.
> The thing is that (foo bar) *is* a list of two symbols, even if not
> quoted. It just so happens that when such a list is passed to the
> evaluator, it evaluates it as a function call. Similarly, [foo bar] is
> *not* a shortcut for (vector foo bar); it *is* a vector of two
> symbols, and vectors just have different evaluation semantics. The
> same applies to sets and maps.
Presumably because the reader returns those structures, and the
evaluator evaluates the symbols they contain, but doesn't do the
implied function call that it does for lists.
> The best you'd get out of a #[foo bar] is a simple reader macro that
> expands to (list foo bar) and that's really just a waste of macro
> characters, not to mention confusing. Or you would have to have a list
> type that isn't evaluated as a function call. But that path leads to
> insanity.
Well, implementing it that way would be easy, but it wouldn't be
right. #[ should cause the reader to emit a list that the evaluator
doesn't treat as a function invocation, not the code to construct
one. Otherwise, the semantics would be wrong.
But you echoed my main concern about it - 50 years of LISP hasn't
caused anyone to want a shorthand for (list .., otherwise it'd be a
standard CLISP reader macro, indicating that "waste of macro
characters" is probably right.
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: last-var-wins: a simple way to ease upgrade pain
On Wed, 5 May 2010 23:22:06 -0700 gary ng wrote: > On Wed, May 5, 2010 at 10:34 PM, Meikel Brandmeyer wrote: > > I'm deeply suspicious of such a behaviour. Why would + on a > > date mean adding days? Why not hours? minutes? seconds? > > months? years? I would always prefer plus-days over such a > > behaviour, because I wouldn't have to think everytime, what + > > adds. > > But that is only a matter of taste, I fancy. > Convention, mostly. Say in the security trading settlement world, they use > terms like T+3 to mean transaction date + 3 days. Which is why I said, toy > DSL. It is used in an implicit context. Everyone in that business knows what > T+3 means. Just like we know what CC means when looking at email. But that just boils down to a matter of taste, with your taste determined by the industry that dominates your background. So wiring it into a DSL is reasonable, and it would be nice if the system didn't get in the way of doing so. 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: Annoying auto-signature
[format recovered from top postgin.]
> > > On May 7, 2:13 am, Mibu wrote:
> > > Am I the only one driven mad by the new auto-appended signature to
> > > every message in this group ("You received this message because you
> > > are subscribed...")? It started on April 16th. Is there a way a
> > > moderator can stop it?
> > On May 9, 10:04 pm, ka wrote:
> > +1
> On Tue, 11 May 2010 09:08:55 -0700 (PDT)
> Brandon Mason wrote:
> +1 (note them stacking up at the bottom?)
Not if people have the courtesy to edit the text they are following up.
but:
inc
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: How do I run a script? This has me stumped.
On Sat, 15 May 2010 21:54:53 +0200 Peter Schuller wrote: > > I am running the following command line: > > > > c:\apps\jdk1.6.0\bin\java.exe -server -cp "C:\apps\clojure-1.2.0\\lib > > \clojure-1.2.0-master-SNAPSHOT.jar;C:\apps\clojure-1.2.0\\lib\clojure- > > contrib-1.2.0-SNAPSHOT.jar" clojure.main Blah.clj > > > > If Blah.clj does not exist, I get a FileNotFoundException. However, > > if Blah.clj exists, I get nothing. It can contain valid Clojure code, > > invalid text, whatever. I've tried using various combinations of > > flags too. > > I have been starring at the command line and I can't spot what's wrong. Except for the doubled \\'s (and I don't do enough windows to know that that's an error), neither do I. Which leads to the question: what's in Blah.clj? In particular, there's nothing in clojure that automatically run things in the script file; you have to explicitly invoke the main function at the end of the script. If you don't, then invoking it on the command line will just load it, and then exit without running anything. 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: How do I run a script? This has me stumped.
On Sat, 15 May 2010 22:13:17 +0200 Peter Schuller wrote: > > Which leads to the question: what's in Blah.clj? In particular, > > there's nothing in clojure that automatically run things in the script > > file; you have to explicitly invoke the main function at the end of > > the script. If you don't, then invoking it on the command line will > > just load it, and then exit without running anything. > Hmmm? I've been invoking scripts regularly since forever ;) > Back in the 1.0 days there was the clojure.Repl vs. clojure.Script > (IIRC); with 1.1 clojure.main does both things depending on > parameters. For example: > > % echo '(println "test")' > test.clj > % java -cp /usr/local/share/java/classes/clojure.jar clojure.main test.clj > test Exactly. You explicitly invoked a function. println is an odd choice for the main function - except as an example. Compare that to: % echo '(defn my-func [& args] (apply println args))' > test.clj % java -cp ~/.clojure/clojure.jar clojure.main test.clj % Arguably, I invoked "defn", but all that did was compile a function for me - it didn't run said function. To run it, I need to invoke it explicitly at the end of the script: % echo '(my-func *command-line-args*)' >> test.clj % java -cp ~/.clojure/clojure.jar clojure.main test.clj testing (testing) % I'm thinking the problem - since the command line appears to be correct, and starts a repl if no script is provided - is that Blah.clj just defines functions, but doesn't invoke one of them. Without looking at the script, this is just a WAG, but I recall some discussion about this issue earlier. 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: convert this to loop/recur?
On Mon, 17 May 2010 14:36:23 -0700 (PDT) Base wrote: > Hi All - > > I am trying convert a function to use loop/recur and am getting the > dreded > > "java.lang.UnsupportedOperationException: Can only recur from tail > position (repl-1:414)" error > > (at least dreded for newbies...) The "tail" position means it's the last call at the top level of the loop. I.e. - you can't call anything after the recur. In your case > The function takes 2 joda dates and returns a sequence of dates > starting at the first of the month until it is past the second date. > This works using standard recursion but I wanted to use TCO. > > Any help is most appreciated (as usual...!) > > Thanks > > Base > > > (def date-seq > (fn [d1 d2] > (loop [b (-> d1 >(.dayOfMonth) >(.withMinimumValue)) >e d2] > (cons b (if (time/before? b e) >(recur (.plusMonths b 1) e)) In this case, you're calling cons with the result of the recur, which means it happens "after" the recur, which is the error. I suspect your original wasn't tail recursive, since the two loop arguments are two dates (assuming my guesses about time/before? are correct), and the values in the list you returns would be stored on the call stack, to be pasted together by the string of conses you've left to run after each recursive call. To make it tail recursive, you need to make the list you're going to return one of the arguments of the loop, adjust the code for that, then push the cons into the if, sort of like so: (defn date-seq [d1 d2] (loop [b (-> d1 (.dayOfMonth) (.withMinimumValue)) e [d2]] (if (time/before? b (first e)) (recur (.plusMonths b 1) (conj e b)) (reverse b This is just a swag; I'm not familiar enough with Java to reconstruct your arguments... 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: Clojure on Android
[Format recovered from top posting. > On Thu, May 20, 2010 at 3:21 PM, rob levy wrote: > > On Thu, May 20, 2010 at 12:37 PM, David Blubaugh < > > davidblubaugh2...@gmail.com> wrote: > >> Has anyone yet ported clojure to the android cellphones at this > >> time ?? I want to develop applications for the Android cellphones by > >> utilizing a dialect of the lisp programming language > > > > Check-out http://github.com/remvee/clojurehelloandroid > > > > I'm surprised we don't hear more talk of people doing this. It's on my > > list of things to do too (I just got an mp3 player that runs Android 1.6 and > > I'm going to start with Remvee's Hello World example). Me as well, except the Android SDK doesn't run on any of my native desktops, so I'm going the longer way 'round... For a REPL on your phone, try here: http://groups.google.com/group/clojure/browse_thread/thread/14725172c626642c?pli=1 Clojure on Android isn't hard to set up, but performance isn't very good. IIRC, there are two issues: both reflection and GC - which Clojure tends to use heavily - are slow on Dalvik. Possibly Froyo will help with that. 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: do clojure and la(tex) have something in common ?
On Sun, 23 May 2010 06:55:50 -0700 (PDT) faenvie wrote: > today i read this statement in a blog-post: > > "... remarkably (La)TeX is much better suited for composing and > distributing most types of documents than any other modern > word processor on the market that I am aware of. Just like > programming languages tend to converge towards Lisp because > it got things right the first time around, so do the Word > Processors tend to converge towards (La)TeX." Another analog to LISP: most people don't know what they're really dealing with. Even the blog you quoted from got that wrong. (La)TeX is a document processor, not a mere word processor. Which is why it's so good at composing and distributing documents. Of course - again like LISP - this has led to it generally being ignored outside the circles that adopted it early on, and made life hard for it's commercial competitors (Scribe and FrameMaker being the two that come to mind readily). One difference is that TeX didn't get it right first; that would be Scribe. But Scribe was sold and support for the free version vanished, leading to it pretty much withering away. To redraw the parallels: Clojure is cool for a number of reasons, but those that it inherited from LISP aren't unique to it - any LISP should have them. (La)TeX is also cool for a number of reasons, but those that it shares with other document processing languages aren't unique to it, either - any good document processing language should have them. In particular, SGML has many of those features. It also has a lot of cruft for dealing with legacy document types, which make doing a full-featured SGML implementation difficult. Once you've got it, you can do outright magic, but there just aren't that many people who can write the thing in the first place. XML is an "SGML application" with many of the options set so that pretty much any competent programmer can build an XML implementation (it's sometimes called "SGML for dummies"). HTML was sorta-kinda SGML; the SGML standard was amended (via the "web annex") so that HTML would qualify, those increasing the number of SGML documents in the world by many orders of magnitude. > what about combining (la=)tex and clojure for implememting > extraordinary document-processing ? These days, most people generate some form of SGML (usually XML or (X)HTML) instead of (La)TeX, for a number of reasons. One is that the language is easier to deal with in code than TeX, both as input and as output. This means that while there are lots of tools to manipulate and format SGML, there aren't so many to deal with TeX. Second, (La)TeX is really biased toward printed output. So what normally happens is that your tools generate the SGML, then transform that to the format appropriate for the target audience: (x)HTML or pdf for the web or Unix, microsoft .hlp files for Windows, and (La)TeX for printing or to generate a pdf of a printed document, because (La)TeX produces gorgeous printed output. XML, of course, is just S-expression with a *really* ugly syntax. So using LISP languages for generating it is easy and natural. > either by run (A) Clojure scripts from (La)TeX documents > and use Clojures output to generate document's content. This > can be used to read/convert data, generate tables and figures, > do on-the-fly calculations. I don't think anyone has done anything like this. Then again, most people don't use (La)TeX as an authoring language. > or by (B) implementing a clojure-based DSL that can produce > (La)Tex documents. Given a clojure-based DSL that produces SGML, there are a number of SGML applications that can be used to generate (La)TeX documents. Further, they can also produce things that more people are interested in, interactive web documents. The (La)TeX bias towards print bites you if you want interactive documents, as print is a miserable medium for them. People wanting to do them tend to use (x)HTML, because - well, it's design has been driven by two groups of people: One set wanted a good language for doing document processing, and they wrote the standards. Another set wanted a good language for doing network presentation, and they wrote the most popular code. The net result is a language in which it's possible to do good document processing if you want to (though 95% of the people producing web pages don't know that such a thing exists, much less have any ability to produce it), but it *also* has hooks to let you build complete applications in the document, should you want to. There are a number of efforts under way to provide clojure-based tools of either type A or B as you described - at least for some SGML applications. Most of them are aimed at the application-building side of things (mine included). Actually, I haven't looked for any aimed at more general document preparation, but going from an (X)HTML DSL to an SGML one that used docbook shouldn't be that hard. You can read about my DSL for XHTML - though it's set up to make it easy t
Re: do clojure and la(tex) have something in common ?
On Mon, 24 May 2010 11:50:41 -0700 (PDT) faenvie wrote: > hello mike, > hello tim > > thank you for this detailed insights into your experience > and knowledge. > > lately i had to implement a generator for a big catalog of > products and i used docbook for it, but that was not a > satisfying experience at all. docbook locks you into > its predefined document-structures and is difficult to > customize - i really hate this old fashioned xslt stuff. > i believe, that the amount of incidental complexity in my > application is unreasonably high because of docbook. Doesn't surprise me - docbook is a single application of the idea, and meant for technical documents. You want a system that lets you start with nearly arbitrary schema. I suspect that docbook might be suitable as a format to produce for such a system. Then again, it might not. I find the reference to "old fashioned xslt" amusing, considering that how new it is. Or maybe how old I am. Of course, part of the point of XML is that you have a wide variety of tools to pick from for working with it; xslt is just one of them. I've had good experiences just adding an xpath library to a good language. A clojure xpath library that returned result sets as lazy sequences sounds like a really cool way to do this, though that would again be just a single component in such a system. On the topic of literate programming - that seems sort of tangential to what you have in mind. The kind of tool we're talking about should be good for producing many types of documents, including literate programs. A literate programming tool on the other hand only has to deal with one type of document - literate programs. So while such a tool might well be everything you're looking for, it might also wind up being as stifling when dealing with documents outside of it's intended domain as docbook is. For example, Tim mentioned using comments as being one way to do literate programming, though not very well. They are clearly even less suitable for other types of documents. I don't think this should cut the other way - being able to extract just the executable parts of a literate program and feed them to the language processor in the order it wants (the "tangle" command) seems like an excellent litmus test for flexibility in such a system. 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: promoting contrib.string to clojure, feedback requested
On Wed, 26 May 2010 19:47:25 +0200 Peter Schuller wrote: > > chomp => rtrim > > (rtrim "foo\n") => "foo" is much more clear to me, plus it leaves the > > door open for trim and ltrim functions should the need arise. > > I like this. And in general I often fine the entire trio useful, and > adopting the ltrim/trim/rtrim naming makes it nice and tidy. > > While I recognize the perl (or whatever the original is) precedent > from chomp/chop, there is precedent for trim/left trim/right trim too. > What *would* one call trim/ltrim to make them consistent with chomp? Personally, I like the lstrip/strip/rstrip, but that's just because I'm used to them. 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: do clojure and la(tex) have something in common ?
On Thu, 27 May 2010 09:47:58 -0400 Tim Daly wrote: > Bill Hart, from the Sage project, said: > "Another thing I've been enjoying lately is literate >programming. Amazingly it turns out to be faster to >write a literate program than an ordinary program >because debugging takes almost no time." > (http://axiom-developer.org/axiom-website/documentation.html) > > so on balance it might be ~1.5 rather than 3. Who knows? Since the discussion of literate programming has continued, I'll chip in and say that I think Tim has understated the case for it, and Bill mentions part of why that is. Literate programming isn't about creating a program that can live forever; it's about communicating the workings of the program to readers. If your readers are people decades in the future, then your result is programs that live forever. If your readers are everyone else who can see the source, then your result is programs that are easy for others to understand and extend. If your reader is you, as you write the program, then your result is programs that have fewer bugs in their first incarnation - which is the point Bill brought up. Chances are, you don't know who the readers of your program are going to be, so you can potentially get all those benefits. 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: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?
On Mon, 31 May 2010 10:53:45 +0930 Antony Blakey wrote: > > On 31/05/2010, at 10:44 AM, Marc Spitzer wrote: > > also lets not forget about LD_LIBRARY_PATH issues, > No Mac or Windows user would encounter these. You forget that the Mac is a Unix box. It supports LD_LIBRARY_PATH. In an ideal world - where every developer did things right - you'd never need it on any system. We don't live in such a world. In particular, OSX tends to ship with obsolete versions of *very* popular Unix libraries. So much so that you wind up having to choose between building obsolete versions of the tools you want, losing valuable features and bug fixes; or building current versions of libraries in the system, leading to having to make sure your code and only your code finds it - even when you're dynamically loading frameworks that want to use the system version of the same library. On Windows, the problem is so common it's been given the name "DLL hell". 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
Clojure android activity?
Is there still any activity in the clojure-android space? The clojure-android mail list is largely inactive, seems like the developers of lein-droid haven't done anything in months (1.7.0-r4 is still used in the templates), and the numerous references If ind for an android-clojure web site are all dead. That said, things do seem to mostly work for stock android. But accessing API's for android wear seems problematical (see https://github.com/clojure-android/lein-droid/issues/162 for my bug report). -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: apply with constructors
On Wed, 2 Jun 2010 13:33:30 +0200 Konrad Hinsen wrote: > Constructors calls translate directly to Java constructor calls, meaning that > the number of arguments must be known at compile time. > > Assuming your constructor takes a fixed number of arguments, the easiest > solution to your problem is to wrap the constructor in a function: > > (apply (fn [p1 p2] (new Connection.Configuration p1 p2)) params) > > If your class has multiple constructors with different arity, there are ways > to look up the right constructor using reflection, but I have forgotten the > details already. Can you let the fn call figure that out for you? Like so: (apply (fn ([p1 p2] (new Connection.Configuration p1 p2)) ([p1 p2 p3] (new Connection.Configuration p1 p2 p3))) params) I realize that reflection is probably better in this case, but was wondering if this would work. 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: Clojure on the tiobe index
On Fri, 4 Jun 2010 11:59:46 -0700 (PDT) BerlinBrown wrote: > I don't think tiobe is all accurate index of anything. But when you > look at the actual rankings, they seem to line up, especially for the > mainstream languages. > > I could see where Delphi ranks high on the list. "Go" is a little > odd. I suspect Go is getting interest because of Google's success. Compare it to D or similar. If Google were pushing it as the tool for Android, I'd expect it to be just a bit behind Objective-C. I'm not sure what you mean about Delphi. But the definition says this includes a slew of Pascal variants that picked up Delphi features as well as some other Delphi tools. The grouping seems odd, but if you think of it as "all OO Pascal variants", the rank makes a bit more sense. 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: Complex type in clojure
On Tue, 8 Jun 2010 06:33:25 -0700 (PDT) Steven Devijver wrote: > On 8 jun, 05:47, Daniel wrote: > > These notation arguments are compelling. > > > > I'm not convinced. The notation would only work for literals, and how > often would one write literal complex numbers? > > For non-literals the notation would need to support this: > > (* (my-complicated-algo x)+(my-other-complicated-algo y)i (another- > algo z)i) Why? It isn't supported for rationals or exponents. Or are you claiming that because we support "3/4" we should also support (* (my-complicated-algo val)/(my-other-complicated-algo exp) 1/(another-complicated-algo exp2)) with similar problems because we support "1e3"? 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: Complex type in clojure
On Tue, 8 Jun 2010 10:27:28 -0700 (PDT) Steven Devijver wrote: > On 8 jun, 16:38, Mike Meyer 620...@mired.org> wrote: > > > > Why? It isn't supported for rationals or exponents. Or are you > > claiming that because we support "3/4" we should also support > > > > (* (my-complicated-algo val)/(my-other-complicated-algo exp) > > 1/(another-complicated-algo exp2)) > > > > with similar problems because we support "1e3"? > > What would (Math/pow (Math/E (* 2/5 2 Math/PI i))) return? Why is this relevant to a discussion of whether or not support for complex literals is desirable? All but "i" is involved with the semantics of complex values, not the literal. 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: Complex type in clojure
[context tossed due to top posting.] On Tue, 8 Jun 2010 14:12:52 -0700 (PDT) Jason Smith wrote: > Why not just treat is as a vector, do vector math operations on it, > and be done with it? 1+2j is equivalent to [1 2]. 1+2j represents a > 2-D vector, does it not? Not only does this handle imaginaries, but > higher forms, such as [1 2 3 4]. The beauty of Lisp is that once you > accept the basic syntax (atoms and groupings), you don't have to worry > about developing EBNF forms for every arbitrary "human readable" > notation. > > Or I could be totally wrong. I think you're totally wrong. You don't have to worry about an EBNF for every arbitrary notation, but you do need one for the basic types in the language, so you can write them out and read them back in and know what you've got. When you read in an S-expression written by a program, you'd like know with 100% certainty whether the 2-element vector you read in is a Complex or just a random 2-element vector. Which means you need a standard representation over and above the two-element vector to represent a Complex constant. There's no good reason not to make that representation something familiar, especially if doing so will help Clojure better interoperate with other systems. Clojure already has a couple of numeric types that can be represented by a vector. Clojure also has rules making otherwise illegal symbols matching a specific pattern represent each of those types as literals, which deals with this problem (not sure that's *why* this was done, but it does deal with the problem.). Adding another pattern for an otherwise illegal symbol to represent a new numeric type seems like a logical thing to do. Besides which, as has been pointed out, tweaking the reader/writer to do this is relatively trivial compared with working out how complex is to be integrated into the numeric stack, much less doing that integration. 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: Non-tail recursion (Clojure way to hierarchies)
On Tue, 15 Jun 2010 03:24:08 -0700 (PDT) Quzanti wrote: > You can use recur to build a hierarchy. What do you mean by you can't > use it as it is not the last statement? Exactly that. recur in some sense terminates the current call, and hence is required to be the last statement in the call. > I have used recur in all sorts of places in the fn, without noticing > any restrictions, and built hierarchies. The restriction is temporal, not spatial. You can put the recur statement anywhere you want, but there must be no other function waiting on it's return value. Or, if it weren't a special form, then it's value would be the value of the function. So this is legal, with the recur as the last function both temporally and spatially: (defn counter [n & result] (if (zero? n) result (recur (dec n) (conj result n And moving the recur spatially still works: (defn counter2 [n & result] (if (> n 0) (recur (dec n) (conj result n)) result)) But if we invert the conj and recur, so that conj uses the "result" of the recur, it breaks at compile time, even if the recur is spatially the last statement in the function: (defn busted-counter [n] (if (zero? n) [] (conj (recur (dec n)) n))) You can, of course, write this as a conventionally recursive function: (defn recursive-counter [n] (if (zero? n) [] (conj (recursive-counter (dec n)) n))) But this version *isn't* tail recursive - it'll use up n levels of stack. Personally, I like recur. Telling the language "I believe this is a tail recursive call" means it can tell me I was wrong at compile time, rather than after it runs out of stack out run time. I hope it stays around after we get TCE. 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: Enhanced Primitive Support
"Nicolas Oury" wrote: >On the other hand, having boxed by default is a very significant slowdown >(10% on the strange program I tried, that had already a lot of annotations, >probably 20% or more on most programs), that can never be addressed : you >can't write annotations on every single line of your program. Were those real world programs, or arithmetic benchmarks? Most real world programs I see spend so little of their time doing arithmetic that making the math an order of magnitude slower wouldn't make a noticeable difference in overall runtime. Which puts making numbers primitives by default squarely in the realm of premature optimization. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- 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: Enhanced Primitive Support
"Nicolas Oury" wrote: >I tried it on my program. Very few arithmetic, most of it with annotation. >10% Can we see the source? -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- 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: Enhanced Primitive Support
On Sat, 19 Jun 2010 11:00:39 +0100 Nicolas Oury wrote: > There is a bit of arithmetic involved everywhere, and around 2-3 double > operations per function in the part choosing the instance of rule to apply. That still sounds arithmetic-heavy to me. In looking through my code, I find three different classes of algorithm: 1) Things that are hard-core number-crunching, which for me is usually either combinatorics or crypto, where bigint is either a necessity or a major convenience. 2) Searches of various kinds, where most of the code manipulates trees/graphs to be searched with no (explicit) arithmetic, and one function evaluates a node with maybe a half-dozen arithmetic ops, meaning an average of <1 arithmetic op per function. 3) Everything else (web hacks, database stuff, string processing, etc.) where there's basically *no* arithmetic. I guess the real question I should be asking is: Where can I get jar files of the various branches so I can test for myself without having to deploy whatever infrastructure is needed to build clojure these days? Or am I likely to be able to build them with tools found in the BSD ports tree? 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: Enhanced Primitive Support
On Sat, 19 Jun 2010 10:43:36 -0400 David Nolen wrote: > On Sat, Jun 19, 2010 at 5:13 AM, Mike Meyer < > mwm-keyword-googlegroups.620...@mired.org> wrote: > > > > > > Were those real world programs, or arithmetic benchmarks? Most real world > > programs I see spend so little of their time doing arithmetic that making > > the math an order of magnitude slower wouldn't make a noticeable difference > > in overall runtime. > > > > "Most real world programs". You mean like Clojure itself? > > Please look over the implementation of gvec before making statements like > this: This is actually the what I'm trying to figure out. While *my* code may have no explicit arithmetic in it, it's not clear without diving into the guts of clojure how much arithmetic gets done in it's name by things like gvec. 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: Enhanced Primitive Support
While I generally favor correct over fast (worrying about fast before you're correct is a good sign that you're engaged in premature optimization), I'm still trying to figure out the tradeoffs here. Especially since most LISPs & other dynamic languages don't seem to run into this issue - or at least the debate that we're seeing here. IIUC, the problem is that we've got three "kinds" (not types; which normally refers to bit lengths) of integer: primitive, which is what the JVM does it's math with. boxed, which is the primitive wrapped in a Java object, and what Java normally uses. bigint, which is a clojure-specific kind of integer. Other numeric types don't have issues because they don't have all three kinds (is that right? Or could this entire thread be rewritten in terms of primitive vs. boxed floats?). And the bottom line is that for some reason we can't get from primitives (which are required for speed) to bigints (which are required to maximize the domain for which we get correct answers) automatically. Assuming that that's right, the first question that occurs to me is: Does clojure really need java's boxed types? Other than for java interop, of course. Again, other languages seem to get by with the platform primitives (module tweaks to get type information) going to bigints, and to get reasonable performance by throwing away the dynamic nature of the language for the hot spots. Could clojure do something similar, or is this something technical issue with the JVM, similar to the reason we don't get TCE? 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: Enhanced Primitive Support
On Sat, 19 Jun 2010 20:20:48 +0100 Nicolas Oury wrote: > Not "ordinary" code. 10^19 is big. No, Aleph-2 is big. Any non-infinite number you can name in your lifetime is small ;-). Pretty much any time I really need integer speed, I also deal with numbers that can get much larger than 10^19th, because I tend to be doing combinatorics or cryptography. True, this represents a small fraction of all programs. The question I'd really like answered is how much difference does this make for non-numeric clojure code, where only a few percent of the calls to core functions are calls to integer ops. 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: Enhanced Primitive Support
On Sat, 19 Jun 2010 22:27:05 +0100 Nicolas Oury wrote: > On Sat, Jun 19, 2010 at 10:15 PM, Mike Meyer wrote: > > Pretty much any time I really need integer speed, I also deal with > > numbers that can get much larger than 10^19th, because I tend to be > > doing combinatorics or cryptography. > But you would agree that for this kind of domain, it wouldn't be too bad to > be explicit about > wanting bigint. If you write a program that work with XML, you don't ask > clojure data to be > encoded in XML. Yes, I would agree. The real issue is that when I say "gimme bigints", it happens pretty much everywhere, so I don't have to worry about overlooking some quantity that might overflow. I suppose this cuts both ways - when you want primitives, you want them everywhere, so you don't have to worry about overlooking some heavily used quantity somewhere. The difference is, I'm worried about getting the correct answer, but you're worried about performance. You can profile your code to identify where the time is going (in fact, you should have already done that before adding the first annotation) to make sure you don't overlook anything. The only automated tool I've got for finding overflows is - well, to run into them. Having to fix them and repeat the run pretty thoroughly negates any win I might have gotten out of using primitive arithmetic where I could. > > True, this represents a small fraction of all programs. The question > > I'd really like answered is how much difference does this make for > > non-numeric clojure code, where only a few percent of the calls to > > core functions are calls to integer ops. > I tried on some code with 1/2 ops per functions and already quite a dew > annotations. 10% speed-up in a program that spend 80% in Object.hashCode > (which does not get accelerated at all). Not quite what I wanted, for at least one reason (preexisting annotations) and possibly because you should be comparing the two variants of the appropriate branch, instead of comparing that branch with either 1.1 or the current master. In any case, I don't think 10% is enough gain to justify narrowing the range for which naive programs are correct. An order of magnitude would be. A factor of two is a maybe. > I think that's due to the 1/2 ops + the ops hidden in clojure library code. > I'd like to see more results like that and bugs in real programs. > It was a matter of minutes to try. > - pull the branch with git > - compile with ant > - replace your clojure.jar > - recompile. Except you have to do it twice, and get correct timings. It would really help if someone could provide precompiled jars with an appropriate README. 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: Enhanced Primitive Support
On Sat, 19 Jun 2010 20:13:07 -0400 David Nolen wrote: > On Sat, Jun 19, 2010 at 4:10 PM, Michał Marczyk > wrote: > > (defn fact [n] > > (loop [n n r 1] > >(if (zero? n) > > r > > (recur (dec n) (* r n) > > Huh? That doesn't look like it's going to work at all. > > 1) 1 is primitive, we know that, accept it > 2) we don't know the type of n, what will (* r n) be? > 3) BOOM! > > My suggestion is to stop it with the contrived examples. Start showing some > real code, real problems in your real programs. Using loop/recur is already > the beginning of code smell for anything that is not performance sensitive. Oh, come on. I didn't write that example, but it's a perfect reasonable implementation of the factorial loop algorithm. I'd say that you're calling "using loop/recur" a code smell is itself a smell, indicating that loop/recur is broken. 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: Enhanced Primitive Support
On Sat, 19 Jun 2010 20:40:13 -0400 David Nolen wrote: > Mark and Mike you fail to address my deeper question. Maybe because you've failed to ask in your hurry to claim code is non-idiomatic or calling our example rhetoric. > I've been using > many different Clojure libraries all day long with the latest equals > branch. Guess > what? > > No loop/recur bugs. I wouldn't expect anything else, for two reasons: 1) Most clojure code doesn't deal with integers - it deals with symbols, strings, and sequences. Hence it won't run into this problem. 2) The libraries are generally written by experienced users who will have tweaked them for performance - meaning they've typed hinted them, and thus avoided this problem. > When you guys start postIng your broken code that has this problem > then people can start believing it is an issue for working code. I guess a perfectly natural expression of a reasonable algorithm that works under 1.1 and doesn't on the equal branch isn't "broken" because it's the same function we've been using all along. So here's some new examples, pulled in sequence from some of my combinatorics code: (defn count-in [value col] (loop [value value col col res 0] (if (empty? col) res (recur value (rest col) (if (= (first col) value) (inc res) res) (defn ones-n-zeros [vectors] (loop [vectors vectors m-zeros 0 m-ones 0] (if (empty? vectors) [m-zeros m-ones] (let [data (first vectors) zeros (count-in 0 data) ones (count-in 1 data)] (recur (rest vectors) (if (> zeros ones) (inc m-zeros) m-zeros) (if (> ones zeros) (inc m-ones) m-ones)) No, I haven't verified it fails - I've given up trying to check out the branch, as hg convert failed, and git (after reinstalling over a broken version) keeps complaining about "warning: remote HEAD refers to nonexistent ref, unable to checkout." However, my reading of the proposal is that the inc's here will cause the same problems as the *'s in the perfectly reasonable factorial example. Now go ahead and claim that that's not very good code, because an expert would have type hinted it or written it with map & apply or some such, or that there's a contrib library somewhere with a faster implementation of count-in in it. That, after all, is your rhetoric. But that's my point. I want the *obvious* code to work. I'll worry about making it fast after I've made it right. If you want a read-only language that requires an expert to get working code in a reasonable amount of time, you can always write in Perl or C. 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: Enhanced Primitive Support
"Rob Lachlan" wrote: >Actually, Mike, your two functions work just fine. (Equal branch). >Mind you I checked that out over two hours ago, so this information >might be out of date. > >Rob > >On Jun 19, 6:59 pm, Mike Meyer > (defn count-in [value col] >> (loop [value value col col res 0] >> (if (empty? col) >> res >> (recur value (rest col) (if (= (first col) value) (inc res) >> res) >> >> (defn ones-n-zeros [vectors] >> (loop [vectors vectors m-zeros 0 m-ones 0] >> (if (empty? vectors) >> [m-zeros m-ones] >> (let [data (first vectors) >> zeros (count-in 0 data) >> ones (count-in 1 data)] >> (recur (rest vectors) (if (> zeros ones) (inc m-zeros) m-zeros) >> (if (> ones zeros) (inc m-ones) >> m-ones)) -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- 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: Enhanced Primitive Support
"Rob Lachlan" wrote: >Because the compiler is upset that it doesn't know what n is. r is a >long, but n is ???. The following works: > >(defn ^:static fact [^long n] > (loop [n n r 1] >(if (zero? n) > r > (recur (dec n) (* r n) > >Or see Dnolen's version above. But yeah, I wish that it still worked, >because it used to work just fine. Is there reason the compiler can't box r instead of throwing an exception? -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- 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
Factorial (Was: Enhanced Primitive Support)
On Sun, 20 Jun 2010 13:27:01 -0400 David Nolen wrote: > On Sun, Jun 20, 2010 at 12:57 PM, Luke VanderHart > wrote: > > > anything that would mean I'd have to explain the intricacies of > > primitives, boxing, hinting and casting in an "Intro to Clojure" > > course. As much as humanely possible, that should be reserved for the > > "Performance coding in Clojure" sequel. > This begs the question: Is loop/recur an advanced / performance coding > topic? > > (defn fact [n] > (reduce *' (range 1 n))) In this case it isn't, because none of these solutions presented qualify as a "fast" implementation of factorial. As in most cases, you don't get real speed by trivial tweaks like using primitives instead of boxed numbers; you real get speed by changing the algorithm to something fast - and, in clojure, something that will leverage multi-core hardware. 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: Enhanced Primitive Support
"David Nolen" wrote: >On Sun, Jun 20, 2010 at 8:19 PM, Mark Engelberg >wrote: > >> My favorite option of those proposed is: >> +, *, -, inc, dec auto-promote. >> loop/recur is changed so that primitive bindings are boxed. >> +',*',-',inc',dec' give error upon overflow. >> A new construct, loop', is introduced that doesn't box primitives and >> enforces recur with primitive upon penalty of error. > > >Until the discussion on loop/recur I was ok with fast math taking '. But now >that I see that people are proposing to change the behavior of loop/recur >(in way I that think is inconsistent with the behavior of literals under the >equal branch). I'm now firmly on the side that people who want >auto-promotion should use '. The ' (prime) names are mnemonic for "primitive type" math. That doesn't work if you reverse the meanings. In that case the names would be better with something like do + - * / ++ -- (or maybe 1+ 1- or +1 -1 though that requires tweaking the definition of symbol) for primitive math and loop add sub mul div inc dec for boxed math. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- 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: Enhanced Primitive Support
On Tue, 22 Jun 2010 14:34:44 +0100 Nicolas Oury wrote: > On Tue, Jun 22, 2010 at 2:00 PM, Daniel Gagnon wrote: > > > If we base the decision on the average guy not writing high performance > > numeric apps, then we should also base it on the fact that he does not need > > more than a long in 99% of cases either as Rich points out. And longs are a > > much simpler concept to grok. > > +1. The average guy understands that "big numbers" are something special. > The average guy also want to have close to native speed when he first tries > a language, not * 10 or * 20 that. Yes, but we've as yet to see that having auto-promotion as the default buys the average app *10 or *20. The best we've seen is 10-20%, which isn't really enough to justify the reduces range for what "just works". 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: Enhanced Primitive Support
On Mon, 21 Jun 2010 21:44:04 -0700 Mark Engelberg wrote: > The new uber-loop is fantastic. > > So I guess the main point still to be finalized is whether the default > arithmetic ops will auto-promote or error when long addition > overflows. I think calling them "default" gives the wrong idea here. We have two behaviors for the math operators, so we need two sets of names. When the existing set auto-promoted and the "other" set worked with primitives, then calling them ' was a mnemonic (PRIMe implying PRIMitive math). But if it's going to be the other way 'round, then the "new" names don't work as well. I propose (again, since nobody commented on it the first time) that the two sets of ops be: non-autopromoting math: +, -, *, /, ++, -- (if you want to muck with the rules for symbols, the last two could be drawn from [+-]?1[-+]? instead). autopromoting math: add, sub, mul, div, inc, dec No mucking about with namespaces, no settings to toggle behaviors - you use the set you want. When teaching the language, you can use the words and not have to worry about explaining about primitive types, boxing, or anything else. While I'm at it, do we still need the postfix N on bignums? Since both the reader and humans do the right thing even if it's not there, we shouldn't need it for output any more, even there might be times when it's handy for input. 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: Enhanced Primitive Support
On Tue, 22 Jun 2010 10:46:05 -0400 Rich Hickey wrote: > --- > The claim that this primitive stuff is just for numeric-intensive > applications is outrageous and false, and ignores the implementation > of Clojure itself to an embarrassing degree. I've worked my tail off > to reduce the number of allocations inside things like sequences etc > to the absolute minimum. Now down to 1 per step, and with chunks 1/32 > per step. Moving from 1 to 2 or 3 per step would result in a 2x to 3x > slowdown for every consumer of these fns. Actually, I've acknowledged that for a while. What I've been trying to get (and that git clone from github fails for me has made hard to measure myself) is some measurements of how much this costs real - but non-numeric - applications. The one measurement posted was - IIRC - 10-20%. > Everyone has to realize the math you are advocating for the default, > on non-tagged architectures like the JVM and CLR, *must* do an > allocation on every +/-/* etc operation. And such ops are littered > throughout non-numeric data structure code, for indexes, offsets, > bounds etc. Allocating on every math op in something like the > persistent vector would make it completely unusably slow. I disagree with that first statement, and will point to python as the counterexample. Like Clojure, it has immutable integers. It avoids the issue of having to allocate for those ops some of the time by keeping a table of the first N (tunable at interpreter build time) integers that *all* instances of small integers point to. So 5 + 5 doesn't allocate a new object, it returns a pointer to the pre-allocated 10 in that table. > Well, guess what, all of the things I've written in my career have > been hard bits. Those languages were unusable for any of my production > work, for performance reasons. I wrote Clojure so I could stop writing > Java and C#, not Ruby, because I couldn't have used Ruby in the first > place. Which merely means that the language you're writing may not be the language I want. No problem. Personally, given that the default is 64 bits, it's not nearly the issue it was when Python changed (when most of the world used 32 bit ints). I just don't want to get stuck having to use obviously second class names (or having to put up with errors about "rebinding core functions") to get the math I want. > Now you're all sitting on the end of the food chain, eating gazelles > and saying, 'who needs photosynthesis to be easy'? > > ;-) > > I do. And so do you if you appreciate fast gazelles. You wouldn't be > able to use a Clojure written in the default Clojure you are advocating. Would it be Clojure if it didn't run on the JVM? Personally, I could live without the JVM. And the more I learn about the JVM, the more I could live without it! On the other hand, the PyPy folks don't seem to be making much noise either. 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: Enhanced Primitive Support
On Tue, 22 Jun 2010 18:56:30 +0100 Nicolas Oury wrote: > On Tue, Jun 22, 2010 at 6:43 PM, Mike Meyer < > mwm-keyword-googlegroups.620...@mired.org> wrote: > > > > > > Everyone has to realize the math you are advocating for the default, > > > on non-tagged architectures like the JVM and CLR, *must* do an > > > allocation on every +/-/* etc operation. And such ops are littered > > > throughout non-numeric data structure code, for indexes, offsets, > > > bounds etc. Allocating on every math op in something like the > > > persistent vector would make it completely unusably slow. > > > > I disagree with that first statement, and will point to python as the > > counterexample. Like Clojure, it has immutable integers. It avoids the > > issue of having to allocate for those ops some of the time by keeping > > a table of the first N (tunable at interpreter build time) integers > > that *all* instances of small integers point to. So 5 + 5 doesn't > > allocate a new object, it returns a pointer to the pre-allocated 10 in > > that table. > > The JVM can do that for you, if you want. It may have issues with > concurrency though, depending of the way it is implemented. > However, it does not solve the problem of performance of boxed nums, though. > 1. It is only helps for small numbers Don't I recall someone saying that small numbers are the most common ones? *Especially* if you're doing things like vector arithmetic. > 2.It only help GC. And GC is not the main issue, imho. > (pointer dereference, including cache misses, and filling the cache with > garbage is more annoying than GCs, imho. But I am not an expert). Um, it helps avoid some GC by *not doing an allocation*. According to what Rich said, doing the allocation is the performance problem - at least in the internals of clojure. Personally, I believe what Rich wrote. Not only does he have more experience than anyone else with the insides of clojure, but this matches my experience with adding GO-FAST to LISP systems. 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: Enhanced Primitive Support
On Tue, 22 Jun 2010 21:07:39 -0400 Garth Sheldon-Coulson wrote: > I would, however, like to throw some support behind Mike Meyer's suggestion > that the arbitrary precision numeric tower use names like add, sub, mul, > div, inc, dec, while the "default" ops keep the symbolic names. I think it > was Luke who suggested, and I agree, that it would be unfortunate to have to > teach new Clojurians about machine math just to allow them to understand > Clojure math. For new users, and also for people like me, it would be nice > to having names for the arbitrary precision numeric tower that don't sound > subordinated or second-class. That's the point. > I also think Mark's idea of removing support for bigints and bigdecimals > from the default ops is worth discussing. It seems cleaner to me than > overloading the default ops and thereby making people complacent. Did you leave ratios out of the list of things it should support? I'm not so sure about this one. With things as they are, if I pass a bigint to a library routine that does arithmetic on it, it will just work. Yes, if I start with a boxed int and it overflows, I still lose, but we can reduce the lossage a little here. We might even be able to tweak things to make it even better. 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: State of Clojure web development
> 1. Have you written, or are you writing, a web application that uses > Clojure? What does it do? roman candle is a web app designed to let me control X10 plc components from any web-capable device, using the X10 firecracker controller. It's still in very early development, and hasn't been given much attention lately. The intent is more to learn about clojure rather than provide a distributable utility. > 2. Which libraries or frameworks are you using? Which versions? I've always been impressed by the Seaside framework, if only it weren't tied to smalltalk. While there are now some C/C++ frameworks along this line, there don't appear to be any available for Java, much less clojure. So I'm developing a small framework - bitchen' - in parallel with roman candle. This is also more pedagogical than production, in that it's not at all clear how to "port" the seaside model from an OO language to a functional/immutable one like Clojure. Should I decide that I'm going to get serious about clojure, this might eventually become a full-fledged framework. > 3. What made you choose Clojure to develop web applications in? What > are the strengths of Clojure web development? Wanting to provide a better answer to that question. Clojure itself is interesting for it's LISPyness, concurrency facilities, and tight integration with the JVM. > 4. What do you think are the current weaknesses of web development in > Clojure? What could be improved? The tight integration with the JVM. I believe it's brought more pain than happiness. > 5. Anything else you want to comment on? Not really. 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: Enhanced Primitive Support
[Not really about enhanced primitive support - more about optimization on the jvm.] On Tue, 22 Jun 2010 01:47:26 -0400 David Nolen wrote: > Yet consider this, If I'm writing OpenGL code in Penumbra I will have quite > a bit of code that amounts to the following: > > ; 630 msecs > (dotimes [_ 10] > (time >(dotimes [_ 10] > (+ 1 2 > > Yes. With Rich's primitive work we can get to *1 billion arithmetic > operations* in < 2/3 of a second on commodity hardware. Which begs the question - why are you mucking about with SISD algorithms if you need that kind of thing to be fast? IIUC, recent versions of the JVM can access the SIMD instructions that have been available on most commodity hardware for the last couple of years. Why aren't you trying to get to those to get a serious performance boost? Better yet, given that you're using OpenGL and presumably have real graphics hardware available, why aren't you trying to push this stuff out to the vector processor on the GPU where it will really fly? 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: Duplicate key bug in hash-maps
On Fri, 25 Jun 2010 15:36:31 +0200
Michael Wood wrote:
> On 25 June 2010 12:27, Tim Robinson wrote:
> > I tried Clojure via Githhub today.
> >
> > Anyone notice this bug that hadn't existed in Version 1.1
> >
> > user=> #{:item1 {:a "A" :b "B"} :item2 {:a "A" :b "B"}}
> > java.lang.IllegalArgumentException: Duplicate key: {:a "A", :b "B"}
>
> You're trying to put duplicate values into a set.
So? Most places, putting a value that's already in a set into the set
is a nop. Even in clojure that exhibits the above behavior:
user=> #{:a :a}
java.lang.IllegalArgumentException: Duplicate key: :a
user=> (set [:a :a])
#{:a}
user=> (conj #{:a} :a)
#{:a}
user=>
Apparently, duplicate keys in sets are only disallowed in set
literals. Arguably, that must be a mistake on the users part, but
it sure seems to clash with the behavior of sets elsewhere.
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: Duplicate key bug in hash-maps
On Fri, 25 Jun 2010 10:31:57 -0400
Stuart Halloway wrote:
> Duplicate keys in maps/sets are disallowed in literals and factory functions,
> where data is generally literal & inline and therefore likely represents
> coder error:
>
> ; all disallowed
> #{:a :a}
> {:a 1 :a 2}
> (hash-map :a 1 :a 2)
> (hash-set :a :a)
Maps I can see being an error - you lose data in the process.
However, since you can plug variables of unknown provenance into
either the constructor or the literal, that's liable to create a nasty
surprise for someone at some point.
user=> (def a :a)
#'user/b
user=> (def b :a)
#'user/b
user=> (hash-set a b)
java.lang.IllegalArgumentException: Duplicate key: :a (NO_SOURCE_FILE:6)
user=> #{a b}
java.lang.IllegalArgumentException: Duplicate key: :a (NO_SOURCE_FILE:0)
user=>
> They are allowed in other contexts, where the data could come from anywhere:
It could come from anywhere in the two "forbidden" contexts as well.
> ; dumb, but these forms not generally called with a literal
> (set [:a :a])
> (into #{} [:a :a])
>
> I find this behavior consistent and easy to explain, but I was involved in
> the design conversation so maybe I have participant blindness. :-)
My initial reaction was "that's a bit odd, but probably a good idea."
However, given that I can use variables inside the literal and
constructor, I'm leaning the other way.
Or is (set [a b c]) idiomatic usage in this case, and (hash-set a b c)
or #{a b c} to be avoided?
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: Duplicate key bug in hash-maps
On Fri, 25 Jun 2010 11:37:32 -0400 Stuart Halloway wrote: > (2) The need for both flavors. If there wasn't a flavor that rejected > duplicate keys, somebody would surely ask for it. I guess it makes as much sense as anything, given that you don't want to get into -unique or some such. But it does leave me wondering where the duplicate-rejecting version of into is :-). 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: Enhanced primitive support - redux
I'll reiterate a question I asked a while back, but was never answered: Are the bit-bashing operators (bit-*) going to get the same treatment as the arithmetic operators? I would expect that many of the fields that benefit if the latter to be fast would also benefit from the former being fast, and I know that fast algorithms in combinatorics and crypto tend to make use of them. 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: Enhanced primitive support - redux
[Format recovered from top posting.] "Nicolas Oury" wrote: >On Sat, Jun 26, 2010 at 7:59 AM, B Smith-Mannschott >wrote: > >> This was suggested on the previous thread on this topic as well, but >> I don't think it was pointed out that *Java already does this*. Doesn't matter if clojure is boxing them as well. Yes, all the boxes will point to the cache, but you still have different boxes, and allocating those is the problem. >I think I pointed it out, and I reiterate it will probably not improve >performance a lot (Except if you use always the 5 same numbers). Reiteration won't make it true. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- 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: Converting list to Map
On Sat, 26 Jun 2010 15:54:34 -0700 (PDT) hsarvell wrote: > I tried to find something in core / on Google to do this but didn't, > here is what I have anyway: > > (defn lst-to-map [lst] >(reduce > (fn [hsh chunk] > (assoc hsh (first chunk) (last chunk))) > (hash-map) > (partition 2 lst))) > > Is there an easier/shorter way? (apply hash-map lst) 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: the joys of lisp
On Sun, 27 Jun 2010 11:58:16 -0700 (PDT) cageface wrote: > When I read about new "features" in other languages that would be > simple macros in Lisp I just have to smile: > http://docs.python.org/dev/reference/compound_stmts.html#with Many in the Python community consider this an advantage of Python. It means semantic changes only get added to the language after proper consideration by the community, the experts who maintain the language, and the BDFL. Common LISP (or more accurately, the evolution from LISP 1.5 through the many and sundry dialects and thence to Common LISP) is held up as an example of how badly wrong allowing anyone to create statements can go. But yeah, many people in the Python community also want LISP-like macros, extolling the virtues of "with" so often that it was added to the language. And a nice addition it was (seems kinda old these days...). 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: the joys of lisp
On Sun, 27 Jun 2010 12:41:36 -0700 (PDT) cageface wrote: > Python definitely seems to be the product of a very different design > philosophy than Lisp. I've always felt it was too prescriptive. > Omitting features that *might* be misused in an effort to keep the > language simple seems to have backfired on them. Not quite - it's to keep the language *readable*. And if there's a use case for a feature that outweighs the damage done by abusing it, they'll add it. Witness with, list comprehensions, and those never-to-sufficiently-cursed augmented assignment operators. This implies simple only to the extent that it shouldn't get so large that one person can't keep the entire language in their head. And yes, it's gotten a bit larger than most people would like. But that's part of the point of Python 3.0 - removing some of the bits that have been obsoleted by more recent additions, or at least moving them out of the language core. > Too keep up with the > competition they've had to add so many new features to the core > language (list comprehensions, annotations, iterators, with statement, > properties etc) that Python doesn't feel like a small, simple language > to me at all anymore. Anyway, I don't mean to pick on Python because > it's not a bad language. I think this just illustrates that it's > better to build from a simple, flexible core than to bolt on pieces > later. So how does providing a drill press and bolt set (i.e. - macros) to the end user fit into this? > I think you can go too far in the other direction too though. > Certainly Scheme is a very elegant language but omits so much from the > spec that you have dozens of incompatible OO implementations floating > around. I think at a minimum a language should provide a single, > consistent, standard implementation of the following: > > 1. a string/text type > 2. an abstract datatype/object model > 3. container types > 4. concurrency primitives > 5. ffi > > Clojure covers these points well, I think, and I'm not worried about > Clojure fracturing into a babel of incompatible macro-based dialects. Well, there are already multiple OO implementations on top of 1.1. Most of them are more to show that you can do that if you really want to, and I'm not sure how much the additions to 1.2 will obsolete them. 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: Newb Question
On Sun, 27 Jun 2010 11:22:15 -0700 (PDT) José Luis Romero wrote: > Hi! I am learning the core of clojure, and so far, I am loving it. But > I am not a lisp programmer (python, java, among others), but never > functional programming. I am practicing with codingbat.com, coding the > exercises on clojure. I am stuck with loops. I want to concatenate n > times a string. For example, given the parameters 3 and "code" the > output will be "codecodecode". How can I do a loop in order to get > this output. > > I know that this is a very newb question, any help will be > appreciated. You really shouldn't be doing loops in clojure. There's almost always a non-looping construct that solves the same problem. I.e., your string repeat would be: (apply str (repeat 3 "code")) Other than that, there are two "common" looping constructs: dotimes and recur. You can find out about them by asking at the repl: user> (doc dotimes). Except loop points you to the web, so here's a summary: recur terminates a loop that was started by either a "loop" or "defn". recur has the form (recur new-values). An initial loop statement has the form (loop [var value ...] body). Defn you should know :-). The recur statement goes back to loop replacing the value of each var (either in the loop or function arguments) with the new values in the recur statement. You could write your string-repeater as: (defn string-dup [count string-in] (loop [count count resuls string-in] (if (== count 0) result (recur (dec count) (str result string-in) But again, the better way would be (defn string-dup [count string] (apply str (repeat count string))) 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: Clojure's n00b attraction problem
On Sun, 27 Jun 2010 17:58:01 -0400 Greg wrote: > This weekend I've been diving head-first into Clojure, and I've documented a > lot of the sticking points that I've run into as a n00b. > > I'd like to share them with the community here, in the hopes that we might be > able to improve the getting started experience for people considering Clojure: > > http://gregslepak.posterous.com/clojures-n00b-attraction-problem Two issues. Number 1, you touched on a key factor here: > Clojure is a new language, and so far it's an early-adopter's game But failed to realize the implications of that. In particular, that it's still changing rapidly, so newcomers should be advised to stay away from the cutting edge. For no reason I can see, you even decided that: > Clojure 1.1 is already outdated. No, it isn't. It's the current release. There are builds with new features in them, but *they haven't been released yet*, and *there is no guarantee that they ever will be*. You shouldn't be working with them unless you specifically want to experiment with that cutting edge stuff. > The datatype stuff that's in the 1.2 builds is being touted as The > Way Things Should Be Done From Now On™. Many n00bs are aware of > this (I was), That you were exposed to things no newb should see is one of the implications with Clojure being a new language. There's only one mail list, used by everyone from newbies asking questions about installation to developers discussing new features. If the language were more mature, you'd never have been aware of what was going on, so wouldn't have run into this issue. That this means you would have spent a lot of time learning about techniques that the next version is going to obsolete is *another* implication of clojure being a new language. It happens with *all* languages, but is worse with new ones that are still in the rapid growth phase of their development. In summary, this request: > so they want to use 1.2 Should meet with the same response as a newb asking about running FreeBSD-CURRENT, about which the FreeBSD handbook says: As you read this, keep in mind that FreeBSD-CURRENT is the 'bleeding edge' of FreeBSD development. FreeBSD-CURRENT users are expected to have a high degree of technical skill, and should be capable of solving difficult system problems on their own. If you are new to FreeBSD, think twice before installing it. > Yes, staying on the bleeding edge, and in this case using different > versions of Clojure should be clearly outlined somewhere in the > Getting Started Experience. No, it shouldn't. Newbs should be using the latest release. Period. Getting Started documents should cover that, and *only* that. Yes, there should be documentation on getting and running bleeding edge stuff somewhere, but not in any documentation aimed at people who've never used the language before. The other issue is: > Yet another set of choices n00bs are faced with is figuring out how > to actually compile their source into an executable. Executable? We're talking about Java here. It doesn't do executables - it does jar files. There's little reason to build those as a newb, as it's not noticeably harder to run the source than it is to run a jar file - or to import them if you're building libraries. If you want to import your clojure into an existing Java application, then you've probably already got a build system, and you need to figure out how to get clojure into it. If you want to distribute a clojure application as a jar file - then you're no longer a newb. Yes, this issue needs to be dealt with - but it's also not something that belongs in a Getting Started guide. 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: the joys of lisp
On Mon, 28 Jun 2010 11:21:24 -0700 (PDT) cageface wrote: > On Jun 28, 11:09 am, Daniel Gagnon wrote: > > That feature would *not* be a simple macro. It isn't simply a call to .close > > on whatever object, it's an arbitrary cleanup procedure on any object that > > implements the feature. The whole standard library implements it and objects > > know how to clean after themselves. So do most third objects like database > > connexions and what not. > > So in order to make this work in Python the *entire* standard library > had to be modified to support it? That's worse than I thought. No, only those that wanted to take advantage of it. > It's an interesting point though. In a certain sense, a macro is > establishing an interface across a set of objects. In writing a macro > you are implying that there exists a set of objects for which the > macro's transformation is logical. The python "with" statement > required implementation of the implied interface across all valid > arguments, whereas the macro version takes advantage of the fact that > most of the applicable objects just happen to have a .close method. In > both cases you're dealing with "with-able" objects. The difference is > that the "interface" that objects can expose to macros is much richer > because arbitrary syntactic fragments are "objects" in this sense. You're making a false assumption. Most of the valid library objects *didn't* have a ".close" method. The decimal library was tweaked to allow the with statement to create a new context, and automatically restore the previous one. The various forms of locking things were all tweaked so that you could use the with statement to acquire a lock that was released on exit. These things could have been done with a simple macro, but would have required tweaking the library to add a "close" function for the objects, even if the function name made no semantic sense. Either that, or use a different name for the function, and then go through and rewrite "the *entire* standard library" to take advantage of it. > The python approach is superior if you believe, as Guido apparently > does, that the useful set of syntactic constructs is small and well- > bounded. If you think, as most lispers do, that syntactic manipulation > is the essence of expressive power then the work it takes to add *one* > new keyword to a language like python seems farcical. The Python approach leads to more readable code: http://www.mired.org/home/mwm/papers/readability.html 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: Clojure's n00b attraction problem
On Mon, 28 Jun 2010 15:13:27 -0400 Daniel Gagnon wrote: > > This is the question I had on the blog post- what is meant by a "newbie"? > > Specifically, what sort of newbie is Clojure wanting to attract? One of the > > "complaints" the original poster had was that you had a choice of editors. > > Of the pool of potential Clojure users, how many of them are not already > > familiar with one (or more) of vi, emacs, or eclipse/other Java IDE? If not > > 0, then it surely must be very small. That you can adopt Clojure without > > having to learn a new editor is a huge plus in my book (if I have to use > > your development environment to learn your language, I'm highly unlikely to > > learn your language). > How many? Most of the ones who come from a Ruby/Python background where > those editors are not very popular. Um, my experience is that emacs and vi are among the most popular editors for Python, Ruby (and Perl) programmers. Of course, that's just anecdotal, so I have to ask if you have hard evidence to back up your statement. 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: the joys of lisp
On Mon, 28 Jun 2010 12:18:58 -0700 (PDT) cageface wrote: > On Jun 28, 12:04 pm, Mike Meyer 620...@mired.org> wrote: > > The Python approach leads to more readable > > code:http://www.mired.org/home/mwm/papers/readability.html > > You don't seem to be very sympathetic to the Lisp way of doing things. Not true as I understand "the Lisp way". You also need to reread the last paragraph again. > What's your interest in Clojure? It's LISP with a richer set of data structures, and (via it's integration with the JVM) without the problems I had with LISP systems last time I worked with them. It's also got more interesting tools for dealing with concurrency than any other language I'm familiar with. Lately, it seems like the JVM integration comes with more problems than it solves, and makes me wonder about building Clojure with gjc. 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: Clojure's n00b attraction problem
On Mon, 28 Jun 2010 15:17:04 -0400 David Nolen wrote: > There is some truth to what you say. Java does bring quite a bit of > incidental complexity to the table but I think between lein and clj these > are being addressed well. They are not "officially sanctioned" but in the > case of lein, it's use is ubiquitous enough to consider "community > sanctioned". I think you can get started with Clojure without having to deal with Java much at all. I certainly did. Possibly what's needed is *two* Getting Started pages. One would be for Java programmers who want to get a feel for the language and how it integrates into their ongoing projects. The other would be for people who don't know Java, but are interested in the language, which provides the minimal amount of Java instructions to get them working with Clojure. Ok, a third site - for people who don't know Java but want to get to know Clojure and Java at the same time - would help. It should tell them to pick just one to start with :-). Hmm. Look at that. The wiki has a getting started page that covers much of what I think needs to go into the "non-java" version. I think it's to long as is, and needs to be cleaned up (i.e. - drop the discussion of apt-get and macports, and talk about installing from "your systems package system" instead). Would anyone object if I took some of that on? 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: Clojure's n00b attraction problem
On Mon, 28 Jun 2010 16:40:57 -0400 Lee Spector wrote: > > On Jun 28, 2010, at 4:29 PM, Brian Schlining wrote: > > > > Was the CLJ project (http://github.com/liebke/clj) mentioned on this > > thread? It seems like it might be handy for those who want to teach Clojure > > in the classroom. It handles the classpath stuff for you. > > > > Also regarding editors, I've had good luck using Clojure with TextMate, > > jEdit, Netbeans, and IntelliJ IDEA. The quality of the respective editors > > can be a bit rough, but at least there are options for the EMACS/VI > > impaired like myself. > > CLJ might indeed be handy but an editor is essential, and neither this nor > the other options mentioned in the CLJ readme includes one as far as I know. > My minimal requirements for an editor are that it have a interface that will > be natural to any user of the platform and that it provide > language-appropriate indentation. Syntax coloring, auto-completion, and > integrated access to documentation would also be highly desirable, but not > essential. Language-specific indentation isn't *nearly* as important in clojure as paren-matching. Writing in most languages - clojure among them without smart indentation ranges from inconvenient to hard. Writing in a LISP without paren matching starts at hard and quickly escalates to painful. 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: the joys of lisp
On Mon, 28 Jun 2010 13:20:28 -0700 (PDT) cageface wrote: > On Jun 28, 1:10 pm, Mike Meyer 620...@mired.org> wrote: > > Not true as I understand "the Lisp way". You also need to reread the > > last paragraph again. > I actually agree with you that the typical block of lisp code is less > readable than the typical block of python. It bugs me when lisp > advocates present s-expr syntax as the "right" way instead of the > engineering tradeoff that it is. You forgo the niceties of a more > ergonomic, less primitive syntax in exchange for unparalleled > syntactic flexibility and corresponding power it brings. To me this > *is* the "Lisp way" - building up the language to your problem by > defining new constructs that other languages have to implement from > scratch. The difference between clojure's "with-open" and python's > "with" illustrates this pretty clearly, the Java legacy that makes > "with-open" a 95% solution notwithstanding. > > What does the "Lisp way" mean to you? What you're calling "The LISP way" I first met under the name "bottom-up programming" - the only real difference is that LISP lets you muck about with what is syntax in other languages - except you pretty much have to stay with S-expressions in LISP (barring reader macros). But yeah, that's part of it. The part that's relevant to the readability paper is that good LISP style calls for using macros only when required (a quick google turned up http://www.bookshelf.jp/texi/onlisp/onlisp_9.html, and rule 3 at http://www.apl.jhu.edu/~hall/Lisp-Notes/Macros.html, and section 5 at http://www.weitz.de/macros.lisp, etc.). In other words, you should only create what is would be new syntax in other languages when you have to. 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: Clojure's n00b attraction problem
On Mon, 28 Jun 2010 17:42:33 -0400 Daniel Gagnon wrote: > > > > Wrong/Misinformed ideas: > > - Clojure 1.1 is not out of date. While it may seem to an outsider that you > > need to be on 1.2 you would be very wrong. 1.2 certainly brings great things > > to the table but they are built upon having a good understanding of what > > currently exists in 1.1. Staying off the cutting edge really prevents a lot > > of headaches. If you want to be on the cutting edge you are probably > > expecting headaches and maybe even actively involved in fixing them. > Then why is labrepl relying on 1.2? I would say it doesn't - there's a quick tour that shows it *using* 1.2, but the official readme that the tour links to says to download Clojure 1.1. Of course, I couldn't find anything that really looks like a release, so maybe I'm looking in the wrong place. On the other hand, if you're grabbing sources from a repo, then you're (again) using unreleased software, and it's not at all uncommon for people building things like labrepl to work with unreleased versions of things in the role that clojure plays, so that they'll have the 1.2-clojure version of labrepl ready to roll out when clojure 1.2 is released. 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: Clojure's n00b attraction problem
On Mon, 28 Jun 2010 19:54:31 -0700 (PDT) Jason Smith wrote: > I just have to mention that what some people on this thread are asking > for may just not be feasible. The Java legacy behind Clojure can't > realistically be hidden. Nor should it be. > > Clojure is very tied to the JVM, with all its power and all its > complexities. Eclipse and IDEA and NetBeans are facts of life in this > arena. JARs and Maven and classpaths are also facts of life. Yup, and Unix-like systems are very much tied to C and text files. Makefiles and vi (or emacs) and C code and shell scripts are facts of life. Nevertheless, it's possible to use Unix-like systems without knowing anything about those things. And it's likewise possible to use clojure without knowing anything about Eclipse or IDEA or Netbeans or Maven. You can make good use of a Unix-like system knowing just a little bit about executables and PATH. Likewise, you can get good use out of Clojure knowing a little bit about classpaths and jar files. > I don't believe you help someone by working very hard to hide all > that. Java is what it is. I don't think anyone advocated working very hard to hide it all. What was advocated was providing a minimal setup so that someone can get to a clojure repl and maybe run a few scripts without having to learn about the rest of the Java infrastructure. > If you are going to go to all the trouble to work with Clojure, you > might as well be exposed to the reality of a semi-production Clojure > project. Put the waterwings on the kid, but then throw him in the > deep end. If he can't swim, he isn't ready for macros anyway. I thought the goal was to *encourage* people to use clojure. Trying to force the Java infrastructure down their throat at the same time is a good way to send them somewhere else - unless they're already familiar with it. Macros are fun - you have one really deep idea, but once you get it you're ready to play. The Java infrastructure is *work*. You listed half a dozen different things, most of which require learning mostly boring minutia to use, none of which are nearly as much fun as a clojure repl. Yes, you may not be able to build a production quality java system without all that infrastructure. If you want to teach people how to do that, your methods make a lot of sense. But that isn't the goal of a "getting started with clojure" project/doc/whatever. The goal there is to make it easy for them to learn enough clojure to make tackling the rest of the Java infrastructure worthwhile. As was pointed out earlier, you don't teach pilots to fly in a 747. You give them something that's much less powerful - and hence much simpler - to start on. To wit: >From Lee Spector : > Jason: Your teaching methods might be great, but they're not the only > way to go. When I teach Lisp or Scheme I generally start with a REPL, > then move on to code in a single file, and then eventually a couple of > files just to break things up. My students can be playing with ways to > write interesting algorithms that do interesting things (e.g. big > chunks of a standard AI curriculum) long before they would have any > real reason to deal with the kind of setup procedures or environmental > complexity that current Clojure environments You can do all that with the clojure environment I work in. I just created ~/.clojure, dump the jar files I want to work with in it, and then have a script that does 'java -cp ~/.clojure/\* clojure.main "$@"' to run a repl - or run a clojure script. That's sufficient to create executable scripts (#!/usr/bin/env clj), etc. (Ok, I used my Unix infrastructure knowledge to improve it - adding rlwrap and slime and swank-clojure, but those are frills, not necessities). I even managed to access the Java X10 plc libraries and the Sun io libraries they depend on so I can play games with the lights in my house and my garage door opener from clojure - and all I needed to know was "download the jars and put them in ~/.clojure." Yeah, it probably makes Java professionals want to throw up. But it lets me explore clojure, which is all I want at this point. For a class, you'd probably want to put the jar files for the class in a shared place, and tweak the script to look there as well as their private library. 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: Clojure's n00b attraction problem
On Tue, 29 Jun 2010 00:19:26 -0400 Lee Spector wrote: > The editor issue is key when we're talking about an environment for newcomers. Yup. The ideal situation should be to let them use whatever text editor they're comfortable with. You really only need two things for writing clojure code: paren matching, and an auto-indent mode that indents to the same level as the previous line. Any reasonable text editor should have both of those. Not ideal, but good enough to start with. > Yes emacs has built-in paren matching but emacs (like vi) is something > that has to be learned, not all newcomers will know it, I don't want > to force my students to use it (although I use it) But you're willing to force them to use some other editor? > and anyway you really need indentation too (IMHO) and getting emacs > to do Clojure indentation is cumbersome. See, I find this funny. Getting emacs to do clojure indentation is pretty much exactly as hard as getting clojure to use some third party library: dump clojure-mode.el onto your load-path, and then load it. > The single-download environments that I've mentioned for Lisp & > Scheme & Processing (and someone else just said they're also > available for Groovy and Jython) have editors that are good enough > for real use. Considering that I've never seen an IDE that I thought had an editor that was "good enough for real use", I find that statement highly subjective. Basically, you need someone to either a) write an editor for clojure, or b) provide instructions for setting up a suitable java-sourced editor (so it runs everywhere) to do clojure indentation, then bundle all that with clojure and clojure-contrib and a little bit of support? 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
