Speed issues vs. Python

[tristan]

Hi guys,

I'm loving Clojure, but i'm having a lot of trouble writing programs
in it that run as fast as my python equivalents.
One example is code i've written for projecteuler.net problem 87 (for
those who don't want to see any solutions don't click the links
below :))
my python version 
http://github.com/tristan/project-euler-code/blob/4a17bc271b4b2743ee1d5b5692f86f963c6bcc7b/0087.py
runs in ~4 seconds (timed using cygwin "time python 0087.py" whereas
my clojure version 
http://github.com/tristan/project-euler-code/blob/4a17bc271b4b2743ee1d5b5692f86f963c6bcc7b/0087.clj
takes over 20 seconds (time gotten from (time call in the code). This
is quite disheartening for me as well since i wrote the python version
in about a minute and haven't even thought about optimizations yet. It
was just written as a test since i was unhappy with the speed of my
clojure version even after re-writing it a few times and shaving off
about 20 seconds from my original.

I'm sure there must be something i'm doing wrong, or thinking wrongly
about hence why i'm not getting the speed i need. Can anyone suggest
any alternate ways to write this? or anything to speed it up? I really
enjoy programming in Clojure, but speed is starting to become an issue
with me.

Thanks
-Tristan
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Static type guy trying to convert

[Korny Sietsma]

On Thu, Mar 12, 2009 at 11:26 AM, Jon Harrop  wrote:
> IME, the trouble can be well worth it. I once wasted two weeks trying to track
> down bugs in a thousand lines of code using unit tests and never managed it.
> When I finally caved in and tried to leverage the static type system instead,
> I fixed all of the known bugs in 24 hours. I simply rearranged my data
> structures, exactly as I did in the above example, and the OCaml compiler
> would point at lines of code responsible for run-time errors and would tell
> me that they had now been proven redundant and could be removed safely. That
> was an enlightening 24 hours.

"Unit tests" - you keep using that phrase.  I do not think it means
what you think it means. :)

Unit tests aren't something I'd use for tracking down bugs - and I
wouldn't use them to "test" the type of all parameters to a function.
I use unit tests to test all the expected paths that my program will
take, which also means validating that I'll never get an unexpected
type.

For example, if I have a function "foo" I'll have tests that cover
expected calls to "foo" with parameters that are valid.
I'll also have tests around any other functions that call "foo",
usually stubbing or mocking the actual call to "foo", ensuring that
those calls also match the contract of "foo".
And generally I'll have some kind of coverage tool to check that all
non-trivial lines of code are covered by such tests, as well as some
integration tests to check that everything is wired together
correctly.

But maybe you use unit tests some other way?  How do you use unit
tests to track down bugs?

On the static vs dynamic question - I've worked on reasonably complex
projects in Java and in Ruby, and I much prefer the dynamically typed
world - mostly because it makes testing like this dramatically easier
to write.  I do miss some of the IDE magic you get from static typing,
but I'm happy to live with a bit of IDE pain if my code is shorter,
clearer, and easier to test.

- Korny
-- 
Kornelis Sietsma  korny at my surname dot com
kornys on gmail, twitter, facebook, etc.
"Every jumbled pile of person has a thinking part
that wonders what the part that isn't thinking
isn't thinking of"

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: cells/add-watch question

[Timothy Pratley]

And equality time does depend on the size of the data structure too it
seems:

user=> (def v (doall (range 1000)))
user=> (def v2 (doall (range 1000)))
user=> (time (= v2 v))
"Elapsed time: 2.772923 msecs"
user=> (def v (doall (range 10)))
user=> (def v2 (doall (range 10)))
user=> (time (= v2 v))
"Elapsed time: 40.998981 msecs"
user=> (def v2 (doall (range 10)))
user=> (time (= v2 v))
"Elapsed time: 0.182742 msecs"

So forget I spoke!


On Mar 12, 4:07 pm, Raffael Cavallaro 
wrote:
> On Mar 11, 6:57 pm, linh  wrote:
>
> > i didn't think of that.
> > if equality tests is instant, would finding out the difference also be
> > instant?
> > for example, is this instant: (difference new-set old-set) ?
>
> I don't think so:
>
> (defn set-difference-time-test [n]
>   (let [s1 (set (apply hash-map
>                        (take n
>                              (interleave
>                               (map #(keyword (str %))
>                                    (iterate inc 0))
>                               (iterate inc 100)
>         s2 (conj s1 [:foozle "woozle"])]
>     (time (difference s2 s1
>
> user=> (set-difference-time-test 1000)
> "Elapsed time: 1.58 msecs"
> #{[:foozle "woozle"]}
> user=> (set-difference-time-test 1)
> "Elapsed time: 35.435 msecs"
> #{[:foozle "woozle"]}
> user=> (set-difference-time-test 10)
> "Elapsed time: 147.856 msecs"
> #{[:foozle "woozle"]}
> user=> (set-difference-time-test 100)
> "Elapsed time: 1061.1 msecs"
> #{[:foozle "woozle"]}
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: version of -> short-circuiting on nil

[rzeze...@gmail.com]

Not that I have any immediate use for this at the moment, but I +1
your proposal.  I make use of the ?. operating in Groovy, and it can
be helpful.

On Mar 10, 4:08 am, Laurent PETIT  wrote:
> Hello,
>
> 2009/3/10 Jason Wolfe 
>
>
>
>
>
>
>
> > > (let [person (get-the-person)]
> > >   (when-not (nil? person)
> > >     (let [address (.getAddress person)]
> > >       (when-not (nil? address)
> > >          (let [street (.getStreet address)]
> > >             (when-not (nil? street)
> > >                (do-something-finally-with-street street)
>
> > ?-> sounds potentially useful to me, but let me also point out that
> > you could simplify the above to:
>
> > (when-let [person (get-the-person)]
> >  (when-let [address (.getAddress person)]
> >    (when-let [street (.getStreet address)]
> >       (do-something-finally-with-street street
>
> No, because here, you could also short-circuit on the value false , and not
> only nil.
> And it's definitely what I had in a first attempt, and wanted to avoid :
> having to think about variable names and add several nested levels of lets.
>
>
>
> > Not quite
>
> > (?-> (get-the-person) #(.getAddress %) #(.getStreet %) do-something)
>
> > but it's halfway there at least.
>
> > Info on contributing is here:
>
> >http://clojure.org/contributing
>
> > The first step is to get your CA signed and in the mail.
>
> Yes you're right, I already have sent my CA, and will re-read this page.
>
> But I thought that before proposing something (even for clojure-contrib), it
> would be interesting to see if what I would like to propose sounds
> interesting to more than one person :-) and if somebody having commit rights
> on clojure-contrib informally accepts the contrib, before creating an issue
> with the patch attached ?
>
>
>
>
>
> > Thanks,
> > Jason
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: cells/add-watch question

[Raffael Cavallaro]

On Mar 11, 6:57 pm, linh  wrote:
> i didn't think of that.
> if equality tests is instant, would finding out the difference also be
> instant?
> for example, is this instant: (difference new-set old-set) ?

I don't think so:

(defn set-difference-time-test [n]
  (let [s1 (set (apply hash-map
   (take n
 (interleave
  (map #(keyword (str %))
   (iterate inc 0))
  (iterate inc 100)
s2 (conj s1 [:foozle "woozle"])]
(time (difference s2 s1

user=> (set-difference-time-test 1000)
"Elapsed time: 1.58 msecs"
#{[:foozle "woozle"]}
user=> (set-difference-time-test 1)
"Elapsed time: 35.435 msecs"
#{[:foozle "woozle"]}
user=> (set-difference-time-test 10)
"Elapsed time: 147.856 msecs"
#{[:foozle "woozle"]}
user=> (set-difference-time-test 100)
"Elapsed time: 1061.1 msecs"
#{[:foozle "woozle"]}
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Bug in set?

[Raffael Cavallaro]

On Mar 11, 11:43 pm, "Stephen C. Gilardi"  wrote:

> Here are the expressions and results in a simplified notation:
>
> #{a b c} - #{a b} => #{c}
>
> #{a b} - #{a b c} => #{}

ok, so I was misunderstanding how difference works. I thought both
would evaluate to #{c}.

thanks
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from 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: Workflow poll?

[Shawn Hoover]

On Sat, Mar 7, 2009 at 4:53 PM, Mark Engelberg wrote:

>
> I've been using the Clojure-in-a-box setup for Windows, which was
> absolutely instrumental in getting me to try out Clojure.  But if I
> keep downloading the latest versions of Clojure, it drifts out of sync
> with the included SLIME development environment and everything breaks.
>  I haven't yet figured out how to set everything up in such a way that
> everything keeps up-to-date and working.


fyi, I just uploaded a new Clojure Box to http://clojure.bighugh.com with
the latest Clojure, including lazier sequences. In the future I'll consider
adding an update function similar to the Emacs Starter Kit, but it's tricky
anytime the tools trail the language on some breaking change.

 Also, I still haven't
> figured out how to get debugging working in the emacs environment.


swank-clojure doesn't support any emacs built in step/breakpoint debugging,
but it's possible to change the REPL initialization args to open a debug
socket attachable from jswat. I have this in my .emacs
(swank-clojure-config) form (for Clojure Box this would have to be patched
into c:/Program Files/Clojure Box/emacs/site-lisp/default.el):

 (setq swank-clojure-extra-vm-args
   (list "-Xdebug"

"-Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=")))


> And I still don't fully understand how to set up complex projects,
> rather than just one-off scripts.
>

I suggest taking a look at the clojure-contrib and swank-clojure sources.
They're both sizable projects that use several namespaces for organization.

Shawn

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Bug in set?

[Stephen C. Gilardi]

On Mar 11, 2009, at 11:11 PM, Raffael Cavallaro wrote:


user=> (use 'clojure.set)
nil
user=> (set (list [:a 1] [:b 2]))
#{[:b 2] [:a 1]}
user=> (set (list [:a 1] [:b 2] [:c 3]))
#{[:b 2] [:c 3] [:a 1]}
user=> (difference *1 *2)
#{[:c 3]}
user=> (difference (set (list [:a 1] [:b 2])) (set (list [:a 1] [:b 2]
[:c 3])))
#{}

Is this a bug or am I just not understanding how difference is
supposed to work?


*1 gives the most recently evaluated value. *2 gives the one before  
that. The two tests you showed have the arguments to difference swapped.


Here are the expressions and results in a simplified notation:

#{a b c} - #{a b} => #{c}

#{a b} - #{a b c} => #{}

--Steve



smime.p7s
Description: S/MIME cryptographic signature

Re: What is Clojure NOT good for?

[e]

On Wed, Mar 11, 2009 at 6:28 PM, Stuart Sierra
wrote:

>
> Ok, here's a real one: if you need to use a lot of C/C++ libraries,
> for which there are no Java replacements, Clojure won't be much fun,
> because C/C++ interop with Java is not fun.  You'll probably be
> happier with a Lisp/Scheme implementation that compiles to C; several
> such languages exist.
>

this could make it survivable: http://nestedvm.ibex.org/

also, there used to be something called "NoodleGlue", but maybe it was so
good, it is no longer open source . . . .or maybe it just died.  Anyone
know?


>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Bug in set?

[Raffael Cavallaro]

user=> (use 'clojure.set)
nil
user=> (set (list [:a 1] [:b 2]))
#{[:b 2] [:a 1]}
user=> (set (list [:a 1] [:b 2] [:c 3]))
#{[:b 2] [:c 3] [:a 1]}
user=> (difference *1 *2)
#{[:c 3]}
user=> (difference (set (list [:a 1] [:b 2])) (set (list [:a 1] [:b 2]
[:c 3])))
#{}

Is this a bug or am I just not understanding how difference is
supposed to work?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Static type guy trying to convert

[e]

> A while ago, I did some brute force tests on a simple stack-based
> language to get some testable metrics on how many unit tests you need
> to guarantee correctness. With a language of 7 instructions and a
> maximum program size of 8 instructions, there are about 6.7 million
> program permutations. Testing a single random assertion resulted in
> the elimination of 99.997% of all incorrect programs. Adding a second
> assertion resulted in 100% of all incorrect programs being discarded.
>

Even though you only set out to talk about unit testing as a substitute for
static typing, you seem to provide anecdotal evidence of the broader point
that I was making.  Namely, it's quite interesting to me that you can
actually run a syntactically incorrect program in a dynamic language ... at
least in python.  Perhaps in NetBeans clojure you can't, I dunno.  But
either way, assuming it is easier than some claim to get good coverage with
few unit tests, such tests will not only catch type mismatches but other,
more basic errors, too.  In fact, could someone please explain why the topic
is limited mostly to "type systems" or whatever?  What is the significance
of that one type of incorrect program?

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Clojure plugin for IntelliJ IDEA published

[Ilya Sergey]

Hi Mike.

What are you talking about assume compilation of Clojure classes. For
this we have to implement first some script, which will compile some
of your files. You're first who asked for such functionality and this
is really cool. So, we're going to implement it in near-term future.
It seems to be a good tactics to compile all files with namespaces
labeled by :gen-class to the same output path as vanilla java classes
before compiling Java part (to allow the latter refer to appropriate
Clojure classes).

With best reagrds,
Ilya

On Mar 11, 1:35 am, AlamedaMike  wrote:
> Hi Ilya,
>
> I would like to use the IntelliJ IDEA to create a GUI in the forms
> designer and then code the rest of the app in Clojure. I would like
> both Java and Clojure code to be registered in a single project and
> compiled together. If you can do that, you've got yourself another
> sale. Can you tell me the current capabilities / future plans with
> this? Thanks.
>
> Mike
>
> On Mar 10, 2:30 pm, Ilya Sergey  wrote:
>
> > Hi, Howard
>
> > Yes, we support debugging for Clojure scripts (even from libary). To
> > launch debugger, create run configuration (for this you may just press
> > Ctrl-Shift-F10 on appropriate script to be run) and launch it in debug
> > mode (Shift-f9 in Linux/Windows keymap).
> > You may set breakpoints and navigate through call stack. "Evaluate
> > expression" in Clojure-style is not supported now, but it is coming
> > soon.
>
> > With best regards,
> > Ilya
>
> > On Mar 10, 6:44 pm, Howard Lewis Ship  wrote:
>
> > > Is there any kind of debugger support (now, or coming?).
>
> > > On Tue, Mar 10, 2009 at 8:10 AM, Tom Ayerst  wrote:
> > > > Liking it so far.  Can you get jline style functionality into the REPL, 
> > > > I
> > > > really miss it.
>
> > > > Cheers
>
> > > > Tom
>
> > > > 2009/2/27 AndrewC. 
>
> > > >> On Feb 26, 7:08 pm, CuppoJava  wrote:
> > > >> > Hello Ilya,
> > > >> > Thanks for the workaround.
>
> > > >> > I'm glad to hear you're working on a "surround with" feature. Some
> > > >> > other parenthesis commands that I most commonly use is:
> > > >> >   1) Delete next Sexp.
> > > >> >   2) Splice Sexp. (Remove the parenthesis around the current sexp).
> > > >> >   3) Move cursor to next/previous sexp.
>
> > > >> Don't forget Barf and Slurp!
>
> > > >> Barf - eject an Sexp from this Sexp (front and back):
>
> > > >> (a b c) -> (a b) c
> > > >> (a b c) -> a (b c)
>
> > > >> Slurp - incorporate an Sexp into this Sexp (front and back):
>
> > > >> (a b) c -> (a b c)
> > > >> a (b c) -> (a b c)
>
> > > >> Also copy this sexp, cut this sexp.
>
> > > >> All vital!
>
> > > --
> > > Howard M. Lewis Ship
>
> > > Creator Apache Tapestry and Apache HiveMind
>
>
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Static type guy trying to convert

[e]

This is a nice post . . . would the partially static typing come from the
IDE?  That seems like the trend right now, but then you gotta get a good
IDE, and no two would ever be the same, which I think is controversial.

On Wed, Mar 11, 2009 at 4:27 PM, chris  wrote:

>
> I don't think it is impossible to begin adding type inference and
> stronger typing to clojure or any fully dynamic language.
>
> You could begin with a set of runtime tests (such as range of a given
> number or what keys are in a dictionary).  These tests allow you to go
> from an untyped world to a typed world, essentially saying if it
> passes test X then it fullfills the contract for type Y.
>
> Next you can run all the type inference you want within sections of
> your code.  Where types can be inferred they are and where they can't
> be runtime tests are used to ensure they match what one would expect.
>
> In short, I think that it is theoretically possible to add partial
> static typing (Hindley-Milner if you desire) to any fully dynamic
> language.  I also think that it is possible, using this system of an
> extensible type system, to allow eiffel style contracts to be
> partially checked at compile time and partially checked at runtime
> thus getting you the benefits of contract based programming without
> typing your fingers to the bone writing asserts and programming in
> tedious, error prone ways that a machine should be able to generate.
>
> There is significant overhead to learning to use any sort of type
> inference as the errors you get are quite mystifying at first.
>
> In any case, people have built very large, long lived, performant, and
> stable systems with dynamic languages.  They have built these systems
> just as quickly as people building systems with statically (and
> strongly) typed languages and in a lot of cases quicker.  I don't
> think anyone has ever proved that a type system drastically increases
> productivity for experienced programmers, regardless of the types of
> bugs it finds.  So it seems ridiculous to me, in a practical sense, to
> force a given type system for every line of code in a program.
>
> I think that it is also damn useful to have the compiler catch a lot
> of problems.  I personally love working in F# and think C# is a joke
> in terms of amount of code you have to write to get something done.
>
> I don't think that very much of what Jon said was irrelevant or FUD,
> and I don't think that even though emotions are high on this subject
> that the proponents of fully dynamic typing are spewing a bunch of
> nonsense either.
>
> Lets take this discussion forward and think of how we could
> incrementally add the important benefits of strongly typed and
> inferred systems like ML, Haskell, and F# to Clojure while keeping the
> very beautiful and clean syntax and minimal mental overhead of using a
> LISP derivative.
>
> Chris
>
> On Mar 11, 2:12 pm, Jon Harrop  wrote:
> > On Wednesday 11 March 2009 18:35:46 Cosmin Stejerean wrote:
> >
> > > On Wed, Mar 11, 2009 at 1:03 PM, Jon Harrop 
> wrote:
> > > > Another red herring: you are describing a disadvantage of nominal
> over
> > > > structural typing.  Not dynamic vs static typing.
> >
> > > You are correct, my apologies. I was trying to show an example of
> > > situations where what I know and what the compiler wants is different,
> but
> > > as you pointed out my example is only valid in the case of a nominal
> type
> > > system.
> >
> > No problem.
> >
> > The most commonly cited examples in academia are the fix point combinator
> and
> > polymorphically recursive functions, neither of which type directly in
> the
> > Hindley-Milner type system that today's statically-typed FPLs are almost
> all
> > based upon. However, not only do both OCaml and Haskell handle those
> examples
> > fine but the examples themselves are of little practical relevance.
> >
> > --
> > Dr Jon Harrop, Flying Frog Consultancy Ltd.
> http://www.ffconsultancy.com/?e
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Static type guy trying to convert

[James Reeves]

On Mar 12, 12:26 am, Jon Harrop  wrote:
> On Thursday 12 March 2009 00:01:43 James Reeves wrote:
> > This doesn't have to be the case. There is nothing inherently magical
> > about a types that makes them more concise to define than a unit test.
>
> Type inference: you don't write anything and the compiler infers your implicit
> constraints.

That's true enough. You could get away with a few less lines by not
explicitly defining your types. Though you obviously lose some type
safety. I've written code that was implicitly typed that caused subtle
bugs because the types weren't quite what I thought they were. There
are also instances where the compiler requires you to explicitly type
something, especially when you're dealing with GADTs or existential
types.

> Same amount of code but the compiler will now prove that the container can
> never be empty.

It's still a very simple check. Types can only handle very simple
predicates, but simple predicates are also very easy to unit test.

> With unit testing, you must create tests for every function that
> handles the container and try to find cases where it erroneously
> produces an empty result.

But if you're programming correctly, there'll only be a few functions
that modify the container directly. Honestly, it sounds good in
theory, but I've never really run into any problems where this would
have been /that/ useful. Even in Haskell, I can't think of many times
I've needed a type like this.

> I believe brevity is a major benefit.

I find macros and homoiconicity more useful to brevity than type
definitions. I occassionally miss having type inferred monads, but
surprisingly not that often. On the other hand, I miss having
homoiconicity and macros every day I go to work.

> IME, the trouble can be well worth it. I once wasted two weeks trying to track
> down bugs in a thousand lines of code using unit tests and never managed it.
> When I finally caved in and tried to leverage the static type system instead,
> I fixed all of the known bugs in 24 hours.

I've been programming for quite a while, but I can't say I've ever
encountered a problem like that.

There was an interesting Google tech talk I listened to a while ago,
where presenter talks about the relationship between theorems and type
systems (i.e. Curry-Howard Isomorphism) in Haskell. I recall the
presenter briefly musing about whether Lisp macros also have a link to
types, as whenever he programs in Lisp, he seems to find no need for
types.

I'm not sure I agree that macros have any relation to types, but it is
true that I don't seem to miss static typing much. Out of interest,
have you done much work in Lisp? Or in a strongly functional Lisp like
Clojure?

> That will depend very strongly on your application. If you are using the
> applications I described before where static typing offers little advantage
> (essentially because the problem is inherently dynamic) then you would not
> expect to see a difference.

Maybe it's just me, but most problems I've encountered seem to be
solved better in dynamic languages :)

- James
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Question about throwing errors

[David Nolen]

Doesn't error-kit do this?

On Wed, Mar 11, 2009 at 10:15 PM, Mark Engelberg
wrote:

>
> I'm thinking about implementing a backtracking mechanism that throws
> errors as a way to escape out of the current computation and try
> another possibility.  I'd want to create a specific error to escape,
> and the backtracking mechanism should only catch this very specific
> error.
>
> Now, I vaguely recall some thread on here a while ago about how this
> is very hard to do in Clojure, because Clojure wraps the errors inside
> of other errors as they work their way outwards, so you can't just
> catch a very specific error.  I think there was some sort of
> workaround involving catching every error, and looking deep inside the
> stack of errors to find the specific error, and if not found, pass it
> on up the chain.
>
> Am I remembering this "gotcha" correctly?  If so, can someone please
> spell out the workaround for me again?
>
> Thanks.
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from 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: Static type guy trying to convert

[Mark Engelberg]

I know of someone who tracked all his bugs in a year of coding in both
Scheme (dynamic) and ML (static).  He said that there was no real
difference.  The kind of bugs that are caught by static type systems
are also quickly identified upon an initial run with a few basic test
cases in a dynamic type system.  Any bug that was non-trivial to
locate turned out to be a deep, logical error, not a surface issue
that could be caught by a type checker.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Question about throwing errors

[Mark Engelberg]

I'm thinking about implementing a backtracking mechanism that throws
errors as a way to escape out of the current computation and try
another possibility.  I'd want to create a specific error to escape,
and the backtracking mechanism should only catch this very specific
error.

Now, I vaguely recall some thread on here a while ago about how this
is very hard to do in Clojure, because Clojure wraps the errors inside
of other errors as they work their way outwards, so you can't just
catch a very specific error.  I think there was some sort of
workaround involving catching every error, and looking deep inside the
stack of errors to find the specific error, and if not found, pass it
on up the chain.

Am I remembering this "gotcha" correctly?  If so, can someone please
spell out the workaround for me again?

Thanks.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from 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: Static type guy trying to convert

[Jon Harrop]

On Thursday 12 March 2009 00:28:06 Raoul Duke wrote:
> i mean, one of the major benefits, i think, of immutability is that
> you are in so many ways actually reducing the cognitive load that you
> are under when running mental simulations of your program -- which is
> a crucial part of being a programmer.

Yes, I can well believe that for many applications.

-- 
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: keys of struct-maps

[jim]

Thanks. I found a way to accomplish what I needed, but I'll tuck that
patch in my back pocket for later.

Jim

On Mar 11, 5:07 pm, Timothy Pratley  wrote:
> They are not currently exposed, but a trivial patch will achieve what
> you want:http://groups.google.com/group/clojure/web/struct.patch
>
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: What is Clojure NOT good for?

[Korny Sietsma]

Agreed.
An interesting parallel is getting Java developers to use Javascript
well - sure, anyone can look at javascript code and probably work it
out - it's a much smaller jump to javascript syntax than clojure
syntax.

But even so, I know lots of Java coders who never really "get"
javascript stuff like prototypes, meta-programming, and the like. They
hack out procedural code in javascript when they have to, but never
come to terms with things like proper unit testing, oo design, or the
like, because it is (a) different, and (b) doesn't interest them.  It
doesn't help of course that javascript, despite being a good basic
language in many ways, has a lot of "broken windows" - ugly browser
issues or language problems that discourage people from learning more.

The places I see clojure getting traction in larger workplaces is
where it might provide solutions that are hard to do with other
languages - i.e., mostly stuff to do with concurrency and performance.
 It'd be interesting (say) to write something like Kestrel (formerly
Starling), Twitter's message queueing system - this used to be Ruby,
got ported to Scala - I'm sure it'd be a good candidate for clojure.

- Korny

On Tue, Mar 10, 2009 at 11:01 AM, Jeffrey Straszheim
 wrote:
> Well, there is no real replacement for raw intelligence, but I hope we'll
> all agree that attitude and curiosity are also critical.
>
> On Mon, Mar 9, 2009 at 7:33 PM, Phil Hagelberg  wrote:
>>
>> bOR_  writes:
>>
>> > I'm not from the software engineers field, but how difficult is it for
>> > some non-lisp, but java-savvy software writer to pick up a 600-line
>> > clojure program and learn to understand it?
>>
>> I suspect it has more to do with people thinking they can't do it than
>> any actual lack of ability to comprehend. Many people are intimidated by
>> new ideas and think to themselves, "I'm a Java programmer. I shouldn't
>> have to learn a new language." Other people would see it as an
>> opportunity rather than a burden, even if they are otherwise both
>> equally capable programmers, the second person will be able to pull it
>> off. But unfortunately this kind of person is much rarer.
>>
>> > I mean, everyone in this forum managed to learn clojure to some degree
>> > without too much trouble.. including me.
>>
>> Membership to this group is _very_ self-selecting; you can't expect
>> things that are true here to be true across the board.
>>
>> -Phil
>>
>>
>
>
> >
>



-- 
Kornelis Sietsma  korny at my surname dot com
kornys on gmail, twitter, facebook, etc.
"Every jumbled pile of person has a thinking part
that wonders what the part that isn't thinking
isn't thinking of"

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: On the importance of recognizing and using maps

[Cosmin Stejerean]

On Wed, Mar 11, 2009 at 5:34 PM, Chouser  wrote:
[...]

>
> Defining a instance method for a Python class allows you to connect
> some code to your data, which internally uses a type pointer from the
> instance to the class.  In Clojure you can put functions directly in
> the metadata (as clojure.zip does), or put a type tag in the map or in
> the metadata, and use a multimethod dispatching on that to connect
> code to your data.
>
> Similarly, any inheritance in Clojure would normally be defined on a
> keyword (or symbol or collection of either) that is in the map or the
> map's metadata.  In Python, the object knows its class, and the class
> knows about the hierarchy.
>
> I don't know if that leads to any particular conclusion.  I suppose it
> does suggests a trivial program (or a trivial part of a program) in
> Clojure will likely have less code for setting up classes than the
> Python equivalent -- you start with the data you actually need, and
> can add "methods", polymorphism, etc. if needed later.
>


I think it's largely possible to abuse Python to achieve some of the
possibilities you mentioned. At runtime you can add new methods to a class,
you can add new methods directly to an object (hint: use
new.instancemethod), you can change the __bases__ of a given class to inject
behavior, and you can change the class of an object by assigning to
__class__.

I included a small example of using the above techniques that makes it easy
(I think) to separate code and data in Python by composing instances that
provide data with classes that provide behavior at runtime.

http://gist.github.com/77848

-- 
Cosmin Stejerean
http://offbytwo.com

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from 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: Static type guy trying to convert

[Raoul Duke]

> On the other hand, I do seem to get less bugs than with Ruby, so
> perhaps immutability is a more significant factor than static typing
> when it comes to creating robust applications.

in a way, i can totally believe that, and it sounds really good, even
if it isn't true :-)

i mean, one of the major benefits, i think, of immutability is that
you are in so many ways actually reducing the cognitive load that you
are under when running mental simulations of your program -- which is
a crucial part of being a programmer.

maybe?

sincerely.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Static type guy trying to convert

[Jon Harrop]

On Thursday 12 March 2009 00:01:43 James Reeves wrote:
> On Mar 11, 2:31 am, Jon Harrop  wrote:
> > > 2. The whole thing does not need to be complete or even functional for
> > > you to start unit testing.
> >
> > Apples and oranges: unit tests are not the same between dynamic and
> > static code bases because dynamic code bases rely upon a huge number of
> > additional unit tests to serve as a poor man's substitute for static type
> > checking.
>
> This doesn't have to be the case. There is nothing inherently magical
> about a types that makes them more concise to define than a unit test.

Type inference: you don't write anything and the compiler infers your implicit 
constraints.

For example, you know that your container:

  [1; 2; 3]

always contains >0 elements so you rewrite it as:

  1, [2; 3]

Same amount of code but the compiler will now prove that the container can 
never be empty. With unit testing, you must create tests for every function 
that handles the container and try to find cases where it erroneously 
produces an empty result.

> If you wished, you could create something like QuickCheck to
> automatically generate a test based on a type definition:
>
>   (data + Integer -> Integer)
>   (data count [a] -> Integer)
>   (data str   a -> String)
>
> The only benefit of a static type system is that it gives you absolute
> guarantees that a unit test cannot.

I believe brevity is a major benefit. Clarity is another: hover the mouse over 
a definition in F# and you get a tool tip with the inferred type as well as 
any relevant documentation.

> In Haskell, I can be certain that 
> a function will not return an incorrect type. In Clojure, I can merely
> say that it is extremely unlikely the function will return the wrong
> type.
>
> The question is whether the guarantees a good type systems offers
> poses a significant advantage. I've done a fair amount of programming
> in Haskell, but I don't believe the type system offers any real
> advantage over unit tests. Guarantees sound good on paper, but the
> guarantees even a language like Haskell offers are very basic, unless
> you're willing to go to a great deal of trouble.

IME, the trouble can be well worth it. I once wasted two weeks trying to track 
down bugs in a thousand lines of code using unit tests and never managed it. 
When I finally caved in and tried to leverage the static type system instead, 
I fixed all of the known bugs in 24 hours. I simply rearranged my data 
structures, exactly as I did in the above example, and the OCaml compiler 
would point at lines of code responsible for run-time errors and would tell 
me that they had now been proven redundant and could be removed safely. That 
was an enlightening 24 hours.

> You can be certain 
> that a function will only return integers, for example, but can you be
> certain a function will only return even numbers?

Halve it. :-)

> Obviously this test was extremely small, and bares little resemblance
> to real programs, which are exponentially more complex. But it does
> seem to tie into my experience, which is that unit tests are
> surprisingly good at ensuring a program is correct, enough that they
> seem comparable to the security of static types. I haven't noticed any
> significant different in bug rates between Haskell and Clojure, so
> static typing doesn't appear to have made a whole lot of difference.

That will depend very strongly on your application. If you are using the 
applications I described before where static typing offers little advantage 
(essentially because the problem is inherently dynamic) then you would not 
expect to see a difference.

> On the other hand, I do seem to get less bugs than with Ruby, so
> perhaps immutability is a more significant factor than static typing
> when it comes to creating robust applications.

Interesting.

-- 
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Is Clojure's lack of support for forward referencing a feature or a bug?

[Timothy Pratley]

Clojure does support forward referencing (if I understand your
question):
user=> (declare a)
user=> (defn b [x] (a x))
user=> (defn a [x] (b x))
user=> (a 4)
java.lang.StackOverflowError
Note: (declare a) is a synonym for (def a) which works also.

It is also quite trivial to patch the compiler to auto-def symbols as
it finds them instead of throwing an error. That makes it hard to
discover typoed symbols. One strategy to have the best of both worlds
would be to allow auto-def until a non-def call is made, and at that
point warn if there are any unbound. Not quite correct for a fully
dynamic language.


Regards,
Tim.

On Mar 12, 2:23 am, quasar  wrote:
> It seems it makes Clojure source code to be in the order of lowest-to-
> highest abstraction.
> Naive mutual recursion based on top-level functions is impossible.
> I am curious, is it due to the current implementaiton of Reader or by
> design?
>
> Best regards,
> Leonid
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Is Clojure's lack of support for forward referencing a feature or a bug?

[pmf]

On Mar 11, 4:23 pm, quasar  wrote:
> It seems it makes Clojure source code to be in the order of lowest-to-
> highest abstraction.
> Naive mutual recursion based on top-level functions is impossible.
> I am curious, is it due to the current implementaiton of Reader or by
> design?

You can use
  (declare something)


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Another cells library

[Jeffrey Straszheim]

I've put together another cells-like library.  Mine differs from the others
in that it uses ref's and transactions, allowing global integrity checks,
rollbacks, and other features that the agent based cells systems do not
have.

It can be found at:

  http://github.com/straszheimjeffrey/dataflow/tree/master

Comments and criticisms are welcome.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Debugging support for clojure?

[Jerry K]

Also, I've not looked at any of the math code in clojure contrib, but
expressed as such, I wouldn't expect the idiom "(mod (expt n exp) m)"
to be at all fast for reasons largely independent of the numeric
implementation underneath.

Computing the entire power and then reducing it modulo m is going to
be gruesome at the number sizes you'll  expect in cryptographic or
computational number theory applications.  Even if BigInteger were
faster, you're going to be giving that code much less of a workout
using "repeated squaring" or the "binary algorithm."  There seems to
be a decent wikipedia writeup on it at 
http://en.wikipedia.org/wiki/Modular_exponentiation
and if you want more details and options, Shallit and Bach's
"Algorithmic Number Theory" (http://www.amazon.com/Algorithmic-Number-
Theory-Vol-Foundations/dp/0262024055) is a good place to look.

I had thought a while back about digging into building some math code
for clojure contrib for applications like algebra and number theory,
since Clojure's Lispyness makes it well suited for that, but wasn't
sure anybody else was especially interested.  I was also thinking
about throwing together an interval arithmetic package that would have
been useful to me on a now concluded project, but never got around to
it.  Are there Clojurers out there doing math-intensive stuff with
regularity?

Jerry

On Mar 11, 5:41 am, Jeffrey Straszheim 
wrote:
> Probably.  The Java BigInteger classes are not particularly fast, and do not
> seem to be a priority to Sun.  Therefore Clojure is not competitive on large
> integer algorithms.
>
> On Wed, Mar 11, 2009 at 2:21 AM, Tassilo Horn wrote:
>
>
>
> > Phil Hagelberg  writes:
>
> > Hi Phil,
>
> > >> If not, is there better way than inserting gazillions of printlns to
> > >> check why and where a function doesn't do the right thing?
>
> > > Most definitely! Break your functions up into smaller pieces, then
> > > write tests for them using test-is.  If your functions are hard to
> > > test, it's probably because they need to be broken out differently.
>
> > Yeah, might be.  To get started with clojure I tried to translate the
> > Miller-Rabin pseudo prime algorithm from wikipedia.  Basically it seems
> > to work correctly, but the preformance is really bad for numbers above a
> > certain limit.
>
> > Investigated it a bit more (doing the algorithm step by step in the
> > repl) and now I know what's the culprit:  The `expt' function from the
> > math contrib library is dead slow.
>
> > For number theory you often need things like
>
> >    (mod (expt n exp) m)
>
> > where the exponent may be very huge.  Is that something which cannot be
> > done faster in Clojure because of the Java Integer/BigInteger stuff?
> > That would be a shame!  I just fell in love with clojure cause the code
> > looks that concise and right!
>
> > Bye,
> > Tassilo

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Is Clojure's lack of support for forward referencing a feature or a bug?

[quasar]

It seems it makes Clojure source code to be in the order of lowest-to-
highest abstraction.
Naive mutual recursion based on top-level functions is impossible.
I am curious, is it due to the current implementaiton of Reader or by
design?

Best regards,
Leonid

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Static type guy trying to convert

[James Reeves]

On Mar 11, 2:31 am, Jon Harrop  wrote:
> > 2. The whole thing does not need to be complete or even functional for
> > you to start unit testing.
>
> Apples and oranges: unit tests are not the same between dynamic and static
> code bases because dynamic code bases rely upon a huge number of additional
> unit tests to serve as a poor man's substitute for static type checking.

This doesn't have to be the case. There is nothing inherently magical
about a types that makes them more concise to define than a unit test.
If you wished, you could create something like QuickCheck to
automatically generate a test based on a type definition:

  (data + Integer -> Integer)
  (data count [a] -> Integer)
  (data str   a -> String)

The only benefit of a static type system is that it gives you absolute
guarantees that a unit test cannot. In Haskell, I can be certain that
a function will not return an incorrect type. In Clojure, I can merely
say that it is extremely unlikely the function will return the wrong
type.

The question is whether the guarantees a good type systems offers
poses a significant advantage. I've done a fair amount of programming
in Haskell, but I don't believe the type system offers any real
advantage over unit tests. Guarantees sound good on paper, but the
guarantees even a language like Haskell offers are very basic, unless
you're willing to go to a great deal of trouble. You can be certain
that a function will only return integers, for example, but can you be
certain a function will only return even numbers?

A while ago, I did some brute force tests on a simple stack-based
language to get some testable metrics on how many unit tests you need
to guarantee correctness. With a language of 7 instructions and a
maximum program size of 8 instructions, there are about 6.7 million
program permutations. Testing a single random assertion resulted in
the elimination of 99.997% of all incorrect programs. Adding a second
assertion resulted in 100% of all incorrect programs being discarded.

Obviously this test was extremely small, and bares little resemblance
to real programs, which are exponentially more complex. But it does
seem to tie into my experience, which is that unit tests are
surprisingly good at ensuring a program is correct, enough that they
seem comparable to the security of static types. I haven't noticed any
significant different in bug rates between Haskell and Clojure, so
static typing doesn't appear to have made a whole lot of difference.
On the other hand, I do seem to get less bugs than with Ruby, so
perhaps immutability is a more significant factor than static typing
when it comes to creating robust applications.

- James
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: design patterns for event driven applications

[Raoul Duke]

> Unfortunately I don't know of a nice way of expressing an event-driven
> architecture in Clojure, but I'm very interested in what you said
> about accomplishing it in Haskell.

(iiuc?) here is a game example: http://home.doramail.com/ns999/asteroids.html

(which is based off of a haskell version but is in CAL.)

sincerely.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: design patterns for event driven applications

[CuppoJava]

Hi Anatoly,
Unfortunately I don't know of a nice way of expressing an event-driven
architecture in Clojure, but I'm very interested in what you said
about accomplishing it in Haskell.

Would you mind explaining that in some more detail? Perhaps if I
understood it, I can even help come up with a Clojure equivalent.

Thanks very much
 -Patrick
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Accuracy of *file*

[Phil Hagelberg]

I'm interested in getting the location on disk of the current file. It
appears *file* provides this, but unfortunately it doesn't provide an
absolute path.

Inside the file /home/phil/src/mire/src/mire/rooms.clj:

  mire/rooms.clj

I tried using java.io.File so I'd have access to getAbsolutePath, but
this is inaccurate:

  (.getAbsoluteFile (java.io.File. *file*)) =>
  /home/phil/src/mire/mire/rooms.clj

There should be a "src" directory in between "mire" and "mire".

It looks like the value of *file* is relative to the classpath entry
where the file was loaded from, but getAbsoluteFile is assuming it's
relative to the current directory.

How do you get the absolute path for the current file?

-Phil

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from 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 support for clojure?

[Mark Engelberg]

On Wed, Mar 11, 2009 at 12:21 AM, Tassilo Horn  wrote:
> Investigated it a bit more (doing the algorithm step by step in the
> repl) and now I know what's the culprit:  The `expt' function from the
> math contrib library is dead slow.

Dead slow?  Compared to what?  A naive expt function just multiplies
the base over and over again, but the library certainly doesn't do
that.  The expt function in the contrib library does bit-shifting and
bit-anding on the power number to figure out a minimal number of
multiplications to do.  Certainly you're going to be limited a bit by
the fact that Java's BigInteger isn't the fastest implementation, and
Clojure does a bit of dispatching to handle each multiplication, but
the overall expt strategy is fast, so I just don't see how it could be
categorized as "dead slow".

>
> For number theory you often need things like
>
>    (mod (expt n exp) m)

Yes, and to make things like this fast, the trick is to perform the
mod at each multiplication step, rather than waiting until the end.
That is why Java's BigInteger library includes modPow, which you can
use directly from Clojure.  If that's a better fit for your
application, you should use that instead.

Or, you could create your own modPow by copying the expt-int function
from the contrib library, and wrapping mod around each multiplication.
 This might be faster than Java's version if the modulus is small
because BigInteger math can then be avoided altogether.

Incidentally, the BigInteger library includes an isProbablePrime
function as well, which again, you can just use directly from Clojure.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: cells/add-watch question

[linh]

i didn't think of that.
if equality tests is instant, would finding out the difference also be
instant?
for example, is this instant: (difference new-set old-set) ?

On Mar 11, 11:11 pm, Timothy Pratley  wrote:
> > This is beacuse my-atom contains a lot
> > of data and I don't want to search for the change.
>
> Just curious, but shouldn't equality tests in Clojure always be
> instant regardless of data size due to shared structure? I suppose I'm
> curious what 'shared structure' gives and what it doesn't.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from 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: Enjoying test-is

[Jeffrey Straszheim]

Me too!

I'm writing tests right now.

On Wed, Mar 11, 2009 at 6:11 PM, Stuart Sierra
wrote:

>
> On Mar 11, 2:45 am, mikel  wrote:
> > I just wanted to say thanks to Stuart Sierra for test-is.
> On Mar 11, 9:15 am, stephaner  wrote:
> > I use test-is too, this is a very usefull test framework.
>
> You're both very welcome!
> -Stuart Sierra
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: On the importance of recognizing and using maps

[Chouser]

On Wed, Mar 11, 2009 at 1:54 PM, Cosmin Stejerean  wrote:
>
> IMHO a big reason Python programmers don't typically treat objects like is
> maps/dictionaries is that the set of things found in the map (dictionary)
> for that object (__dict__) are just a small subset of the interesting
> attributes of the object. In Python things like class level attributes,
> properties, descriptors and multiple inheritance all add a lot of
> flexibility to defining and using objects that would take a some effort to
> replicate on top of simple maps.

It's interesting to compare a Python class with a dict inside to a
Clojure map with metadata "outside".

Interacting directly with a class dict feels a little dirty, because
you could be circumventing the API provided by the class methods,
making it easy to get the object into a bad state.  Clojure's maps
being immutable reduces the amount of trouble you can cause by dealing
directly with the map.

Defining a instance method for a Python class allows you to connect
some code to your data, which internally uses a type pointer from the
instance to the class.  In Clojure you can put functions directly in
the metadata (as clojure.zip does), or put a type tag in the map or in
the metadata, and use a multimethod dispatching on that to connect
code to your data.

Similarly, any inheritance in Clojure would normally be defined on a
keyword (or symbol or collection of either) that is in the map or the
map's metadata.  In Python, the object knows its class, and the class
knows about the hierarchy.

I don't know if that leads to any particular conclusion.  I suppose it
does suggests a trivial program (or a trivial part of a program) in
Clojure will likely have less code for setting up classes than the
Python equivalent -- you start with the data you actually need, and
can add "methods", polymorphism, etc. if needed later.

--Chouser

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: What is Clojure NOT good for?

[Stuart Sierra]

Ok, here's a real one: if you need to use a lot of C/C++ libraries,
for which there are no Java replacements, Clojure won't be much fun,
because C/C++ interop with Java is not fun.  You'll probably be
happier with a Lisp/Scheme implementation that compiles to C; several
such languages exist.

-Stuart Sierra
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: filter1 interesting?

[Stuart Sierra]

On Wed, Mar 11, 2009 at 9:01 AM, Vagif Verdi 
wrote:
> Is (first (filter ..) lazy like in haskell ?

It's lazy in the sense that it will only consume the sequence up to
first positive result.

If it doesn't find one, it will consume the entire sequence and return
nil.

Therefore, this form is not safe on infinite sequences!
For example,  (first (filter neg? (iterate inc 0)))  never terminates.

-Stuart Sierra
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Enjoying test-is

[Stuart Sierra]

On Mar 11, 2:45 am, mikel  wrote:
> I just wanted to say thanks to Stuart Sierra for test-is.
On Mar 11, 9:15 am, stephaner  wrote:
> I use test-is too, this is a very usefull test framework.

You're both very welcome!
-Stuart Sierra

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: cells/add-watch question

[Timothy Pratley]

> This is beacuse my-atom contains a lot
> of data and I don't want to search for the change.

Just curious, but shouldn't equality tests in Clojure always be
instant regardless of data size due to shared structure? I suppose I'm
curious what 'shared structure' gives and what it doesn't.


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from 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: Request: Can clojure.contrib.walk provide a reduce type operation?

[Stuart Sierra]

On Mar 11, 12:24 pm, Jeffrey Straszheim 
wrote:
> Currently the clojure.contrib.walk code provides a nice way to perform a
> depth first map operation on trees.  However, I need to fold across a tree.
> It would be nice if walk provided this.

Hi Jeffrey,
I agree it would be a useful feature.  I'll look at implementing it,
should be doable.
-Stuart Sierra

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: keys of struct-maps

[Timothy Pratley]

They are not currently exposed, but a trivial patch will achieve what
you want:
http://groups.google.com/group/clojure/web/struct.patch

user=> (defstruct ts :a :b)
#'user/ts
user=> (struct-keys ts)
(:a :b)

Regards,
Tim.


On Mar 12, 5:23 am, jim  wrote:
> Is there a more efficient way of getting the keys of a struct-map
> besides creating an instance and passing it to keys:
>
> >(def ts (create-struct :a :b))
> >(keys (struct ts))
>
> (:a :b)
>
> Thanks,
> Jim
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Static type guy trying to convert

[Joshua]

You can get those warm fuzzies back when you develop in an IDE such as
Netbeans, IntelliJ, or Eclipse. They can compile the code and provide
some feedback. The plugins are kinda young, but they may provide
enough to help make the jump.

Joshua

On Mar 10, 1:16 am, zoltar  wrote:
> Hey everyone. I've been keeping up with developments in Clojure for a
> few months now and have a question for all you long-time static typers
> out there (I know you're there :)
>
> I really like what I read about Clojure and LISP in general and can
> see the potential for great power and flexibility. I know the
> advantages/disadvantages of static vs dynamic languages but I can't
> help feeling like I'm losing something whenever I try Clojure. I am
> admittedly brainwashed after years of C, C++ and Java but I miss the
> warm fuzzies when I know the compiler has checked all the types for me
> and I don't have to worry about a whole class of run-time errors. I'm
> willing to give that up for the advantages Clojure gives me but I was
> wondering how others have dealt with the loss of these static warm
> fuzzies. I always feel a bit lost in Clojure, not knowing what types a
> function expects or what it will return. I suppose this goes away in
> time but any advice is appreciated.
>
> Curtis
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Static type guy trying to convert

[Raffael Cavallaro]

On Mar 11, 4:17 pm, "ntu...@googlemail.com" 
wrote:

> I would appreciate it if you would consider his arguments instead of
> discrediting him. His post is not insulting and contains valid
> arguments. So please don't shoot the messenger.

When the "messenger" is habitually insulting he loses credibility. One
recent example below. There are many others, google for them if you
like:


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Static type guy trying to convert

[Jon Harrop]

On Wednesday 11 March 2009 20:27:15 chris wrote:
> Lets take this discussion forward and think of how we could
> incrementally add the important benefits of strongly typed and
> inferred systems like ML, Haskell, and F# to Clojure while keeping the
> very beautiful and clean syntax and minimal mental overhead of using a
> LISP derivative.

Check out Mark Tarver's Qi language:

  http://www.lambdassociates.org

It provides an optional and extensible static type system built upon Common 
Lisp.

The main problem is that statically typed languages are often chosen for 
performance reasons and, of course, if you built a static language on top of 
a dynamic language then you lose that benefit. However, that is not true of 
all static languages and Haskell in particular is seeing significant uptake 
right now despite its performance issues. So perhaps it would be most 
productive to have Haskell or a Haskell-like DSL within Clojure if you're 
interested in this kind of thing (I have no idea how useful that would 
actually be!).

-- 
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Clojure.main/repl function

[NarayanS]

I am using the clojure.main/repl function to start a new repl in my
application. When I am done i want to close it. Repl has a read-eval-
print going - how can i stop it? Currently i am passing "caught"
option which throws an exception for certain condition and breaks the
loop.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Static type guy trying to convert

[chris]

I don't think it is impossible to begin adding type inference and
stronger typing to clojure or any fully dynamic language.

You could begin with a set of runtime tests (such as range of a given
number or what keys are in a dictionary).  These tests allow you to go
from an untyped world to a typed world, essentially saying if it
passes test X then it fullfills the contract for type Y.

Next you can run all the type inference you want within sections of
your code.  Where types can be inferred they are and where they can't
be runtime tests are used to ensure they match what one would expect.

In short, I think that it is theoretically possible to add partial
static typing (Hindley-Milner if you desire) to any fully dynamic
language.  I also think that it is possible, using this system of an
extensible type system, to allow eiffel style contracts to be
partially checked at compile time and partially checked at runtime
thus getting you the benefits of contract based programming without
typing your fingers to the bone writing asserts and programming in
tedious, error prone ways that a machine should be able to generate.

There is significant overhead to learning to use any sort of type
inference as the errors you get are quite mystifying at first.

In any case, people have built very large, long lived, performant, and
stable systems with dynamic languages.  They have built these systems
just as quickly as people building systems with statically (and
strongly) typed languages and in a lot of cases quicker.  I don't
think anyone has ever proved that a type system drastically increases
productivity for experienced programmers, regardless of the types of
bugs it finds.  So it seems ridiculous to me, in a practical sense, to
force a given type system for every line of code in a program.

I think that it is also damn useful to have the compiler catch a lot
of problems.  I personally love working in F# and think C# is a joke
in terms of amount of code you have to write to get something done.

I don't think that very much of what Jon said was irrelevant or FUD,
and I don't think that even though emotions are high on this subject
that the proponents of fully dynamic typing are spewing a bunch of
nonsense either.

Lets take this discussion forward and think of how we could
incrementally add the important benefits of strongly typed and
inferred systems like ML, Haskell, and F# to Clojure while keeping the
very beautiful and clean syntax and minimal mental overhead of using a
LISP derivative.

Chris

On Mar 11, 2:12 pm, Jon Harrop  wrote:
> On Wednesday 11 March 2009 18:35:46 Cosmin Stejerean wrote:
>
> > On Wed, Mar 11, 2009 at 1:03 PM, Jon Harrop  wrote:
> > > Another red herring: you are describing a disadvantage of nominal over
> > > structural typing.  Not dynamic vs static typing.
>
> > You are correct, my apologies. I was trying to show an example of
> > situations where what I know and what the compiler wants is different, but
> > as you pointed out my example is only valid in the case of a nominal type
> > system.
>
> No problem.
>
> The most commonly cited examples in academia are the fix point combinator and
> polymorphically recursive functions, neither of which type directly in the
> Hindley-Milner type system that today's statically-typed FPLs are almost all
> based upon. However, not only do both OCaml and Haskell handle those examples
> fine but the examples themselves are of little practical relevance.
>
> --
> Dr Jon Harrop, Flying Frog Consultancy Ltd.http://www.ffconsultancy.com/?e
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Dotted method invocations (and other reader niceties) do not work in #= forms

[Chas Emerick]

Replying to my own (old) post -- the reason why all reader
capabilities aren't available in #= forms is that the reader isn't
currently being recursively applied to the body of those forms.  Only
certain aspects of the full reader's functionality (like dotted
constructor invocations) are being recruited there at the moment.
After tinkering, it looks like that's "just" an implementation limit
right now, probably due to the mandate and details of #= forms and
printable reading not being entirely fleshed out yet.

- Chas

On Feb 24, 5:19 pm, Chas Emerick  wrote:
> This works fine:
>
> user/ (read-string "#=(java.lang.Float. \"5\")")
> 5.0
>
> However, these two cases fail:
>
> user/ (read-string "#=(.toCharArray \"foo\")")
> java.lang.Exception: Can't resolve .toCharArray
>
> user/ (read-string "#=(java.lang.Enum/valueOf java.lang.Thread$State  
> \"NEW\")")
> java.lang.ClassCastException
>
> In the first case, it looks like the dotted method invocation isn't  
> being expanded into the (. obj (methodname)) form, so a var named  
> '.toCharArray' is being searched for.
>
> In the second case, I'm guessing that the classname provided as the  
> first argument is being interpreted as a symbol and not a Class.  Just  
> for comparison's sake:
>
> user/ (eval '(java.lang.Enum/valueOf java.lang.Thread$State "NEW"))
> #
>
> (Also puzzling to me is the fact that the ClassCastException is being  
> emitted by clojure's reflection apparatus; this is confusing to me, as  
> Enum/valueOf has no overloads, and in any case, the types of the  
> arguments is known -- Class and String, or in the case where the  
> reader isn't swapping out the symbol for the Thread$State class, a  
> Symbol and String.  That's for another day, though.)
>
> I'm not entirely clear on all of the implications of #=, but it seems  
> like a good deal of the reader functionality isn't available within #=  
> forms.
>
> Is this known and/or expected behaviour?
>
> Thanks,
>
> - Chas
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Static type guy trying to convert

[ntu...@googlemail.com]

On Mar 11, 5:26 am, Raffael Cavallaro 
wrote:
> Some of you may not know of Jon's behvior on comp.lang.lisp so some
> background will be useful here.

I would appreciate it if you would consider his arguments instead of
discrediting him. His post is not insulting and contains valid
arguments. So please don't shoot the messenger.

-nt

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Static type guy trying to convert

[Jon Harrop]

On Wednesday 11 March 2009 18:35:46 Cosmin Stejerean wrote:
> On Wed, Mar 11, 2009 at 1:03 PM, Jon Harrop  wrote:
> > Another red herring: you are describing a disadvantage of nominal over
> > structural typing.  Not dynamic vs static typing.
>
> You are correct, my apologies. I was trying to show an example of
> situations where what I know and what the compiler wants is different, but
> as you pointed out my example is only valid in the case of a nominal type
> system.

No problem.

The most commonly cited examples in academia are the fix point combinator and 
polymorphically recursive functions, neither of which type directly in the 
Hindley-Milner type system that today's statically-typed FPLs are almost all 
based upon. However, not only do both OCaml and Haskell handle those examples 
fine but the examples themselves are of little practical relevance.

-- 
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Request: Can clojure.contrib.walk provide a reduce type operation?

[Jeffrey Straszheim]

Yeah, I figured something like that out, but it was non-obvious.

It might be nice helper function sometime down the road.

On Wed, Mar 11, 2009 at 3:49 PM, Kevin Downey  wrote:

>
> if your walk pushes the items into a Queue, you can just reduce across the
> Queue
>
> On Wed, Mar 11, 2009 at 9:24 AM, Jeffrey Straszheim
>  wrote:
> > Currently the clojure.contrib.walk code provides a nice way to perform a
> > depth first map operation on trees.  However, I need to fold across a
> tree.
> > It would be nice if walk provided this.
> >
> > >
> >
>
>
>
> --
> And what is good, Phaedrus,
> And what is not good—
> Need we ask anyone to tell us these things?
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from 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: Request: Can clojure.contrib.walk provide a reduce type operation?

[Kevin Downey]

if your walk pushes the items into a Queue, you can just reduce across the Queue

On Wed, Mar 11, 2009 at 9:24 AM, Jeffrey Straszheim
 wrote:
> Currently the clojure.contrib.walk code provides a nice way to perform a
> depth first map operation on trees.  However, I need to fold across a tree.
> It would be nice if walk provided this.
>
> >
>



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

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from 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: Static type guy trying to convert

[Cosmin Stejerean]

On Wed, Mar 11, 2009 at 1:03 PM, Jon Harrop  wrote:

>
> On Wednesday 11 March 2009 15:30:01 Cosmin Stejerean wrote:
> > Actually it happens a lot in real code and in many non-trivial programs
> in
> > static typed languages you end up with a proliferation of types that are
> > simply there to make the compiler happy. To me it happens very often
> where
> > I know what I want: to pass an object of type B into a function f that
> > expects type A, because I know that B is sufficiently A-like to allow
> > function f to work.
>
> Another red herring: you are describing a disadvantage of nominal over
> structural typing.  Not dynamic vs static typing.
>

You are correct, my apologies. I was trying to show an example of situations
where what I know and what the compiler wants is different, but as you
pointed out my example is only valid in the case of a nominal type system.

-- 
Cosmin Stejerean
http://offbytwo.com

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from 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: Static type guy trying to convert

[Jon Harrop]

On Wednesday 11 March 2009 18:18:59 Raoul Duke wrote:
> > Another red herring: you are describing a disadvantage of nominal over
> > structural typing.  Not dynamic vs static typing.
>
> there are probably several different arguments being conflated in such
> discussions.
>
> for example, theory vs. practice: there is the theory of what in fact
> are the options for typing, and then there is the practice of what
> programming languages currently exist, and what of all those options
> do they implement. so if there is not a popular "statically typed"
> language which does "duck typing", and most people are only aware of
> "statically typed" languages that don't, then that practice can easily
> lead one to be confused into saying the theory of statically typed
> languages don't work because they don't support "duck typing". or
> statements made can be mistakenly inferred to be talking about the
> theory when they are really talking about the practice.

Exactly, yes.

> in other words, what "statically typed" language do proponents of such
> languages hold up as the one which would most likely be the least
> despicable in the eyes of dyed-in-the-wool "dynamic" language folks?

The least despicable would probably be F# because you can resort to dynamic 
typing so easily: just box everything and use run-time type tests. That is 
not possible in OCaml and Haskell but they have more advanced static type 
system features (e.g. structurally-typed objects and polymorphic variants in 
OCaml) that are used to solve the same problems.

The obvious bad examples are Java and C++ and I don't think it is a 
coincidence that most of these "red herring" examples seem to be drawn from 
problems specific to those two languages.

-- 
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

keys of struct-maps

[jim]

Is there a more efficient way of getting the keys of a struct-map
besides creating an instance and passing it to keys:

>(def ts (create-struct :a :b))
>(keys (struct ts))

(:a :b)

Thanks,
Jim


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: What is Clojure NOT good for?

[Howard Lewis Ship]

I ran into a bit of the "but we can hire Java coders" mentality when I
presented Clojure at a local JUG.

Due to time constraints, I didn't get into it at the time, but my
basic thought is:

"I don't care what you know, I care what you can learn!"

Also, there's the myth of the "immediately productive programmer",
i.e., I can hire this guy and he'll be productive because
he already knows Java and Struts (for example):

Faults with this reasoning:
- Nobody is productive on day 1, few in week 1
- Your internal processes, code libraries, version control, etc. will
get in the way as much as coding language
- I might be productive with a hammer, but that won't help me fix this watch!
- If you hire someone with limited initiative/ambition, don't be
surprised if they're contribution is not stellar
- Why set the stage in terms of the *lowest* level of contribution?



On Mon, Mar 9, 2009 at 10:08 AM, Jay Fields  wrote:
> I've lived through this discussion for the past 3 years while writing web
> applications using Ruby and Rails. Here's what I've learned:
>
> - Using a language that the average stupid programmer can't understand
> virtually guarantees that you'll increase your success chances, since you
> and your team-mates will be of a higher caliber.
> - The world is always going to tell you that using Clojure is a bad idea.
> - If you think using Clojure is a good idea and you and your team are
> excited about using Clojure, it's probably a good idea.
> - If you think using Clojure is great for your application, but bad for your
> company, look for a new company.
> - You aren't going to find a job in your favorite city using your favorite
> language in your favorite domain. Decide what you value the most and go from
> there.
> - Don't hire consultants when using bleeding edge technology.
>
> I could probably go on for hours. The bottom line is, it's entirely
> contextual, and you're smart enough to look at Clojure, so make the smart
> choice on whether it's right for your situation.
>
> Cheers, Jay
>
>
>
> >
>



-- 
Howard M. Lewis Ship

Creator Apache Tapestry and Apache HiveMind

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: cells/add-watch question

[linh]

Thanks Raffael, I'll try that

On Mar 11, 6:42 pm, Raffael Cavallaro 
wrote:
> On Mar 11, 1:24 pm, Raffael Cavallaro 
> wrote:
>
> > ;; this just makes a big map atom where integer keys are associated
> > with integer values
>
> should rather be as follows to get integer keyword keys:
>
> (def my-atom
>      (atom (assoc (apply hash-map
>                          (take 1000
>                                (interleave
>                                 (map #(keyword (str %))
>                                      (iterate inc 0))
>                                 (iterate inc 100
>              :last-update nil)))
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: android app development with clojure

[rob]

That is exciting!  Have you posted any code or advice/instruction on
how one could repeat what you did with Clojure on the Android phone?

Rob

On Feb 6, 12:29 pm, "Remco van 't Veer"  wrote:
> Got startup time down to 5 seconds by completely eliminating the use
> of lispreader and putting of loading the xml, set and zip namespaces.
> There's no clear bottlenecks left to fix.
>
> On Fri, Feb 6, 2009 at 1:06 AM, Remco van 't Veer  wrote:
>
> > I've managed to get to startup time down from 12 seconds to 7 on the
> > emulator and hope get it below 4 seconds tomorrow.  A lot of time is
> > spend in LispReader when the core constants are initialized.  I've
> > altered the compiler to emit type specific code for the basic cases,
> > thus bypassing LispReader.  Need to learn more about GeneratorAdapter,
> > and need sleep, before I can speedup the loading of, for instance, seq
> > contants.
>
> > My changes are available at github;http://github.com/remvee/clojure
>
> > Remco
>
> > On Wed, Feb 4, 2009 at 5:55 PM, Remco van 't Veer  
> > wrote:
> >> Having a lisp to do android app development is definately worth some 
> >> efford.
> >> Kawa already has some android support in svn trunk but it doesn't seem in a
> >> usable state; my experiments break because a lot of expressions do not seem
> >> to compile AOT. The parts that do compile are very fast on the other hand.
>
> >> But if it comes down to app development I would of course prefer clojure
> >> over kawa's schema and scheme over java..
>
> >> I hope to do some tracing to find out what slowing down the startup later
> >> this week and will keep the list in formed. If anybody has any suggestions
> >> please yes pretty please.
>
> >> Remco
>
> >> On Feb 4, 2009 3:59 PM, "igorrumiha"  wrote:
>
> >> On Feb 4, 10:12 am, "Remco van 't Veer"  wrote: >
> >> Caching Reflector.getMethods,...
>
> >> I would also be interested in running Clojure on the Android. I tried
> >> running a "Hello world" application on the emulator but the startup
> >> time od 15 seconds put me off. There is definitely room for
> >> improvement. I don't have much experience in Java (zero would be the
> >> best description) so I don't really know where to start with
> >> profiling.
>
> >> I've run the application through the Instrumentation mechanism and the
> >> trace shows me that much of the time is spent in a huge amount of
> >> calls to some character compare methods (something like 20 calls)
> >> (I don't have the trace with me right now so I don't have the exact
> >> numbers and I don't know the exact method name).
>
> >> I find this curious when I know that all code is compiled ahead of
> >> time. When I get the chance I will recreate that call graph an upload
> >> it to the files section.
>
> >> --
> >> IgorR
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: android app development with clojure

[rob]

Hi Remco,

If you've written up anything, or plan to, on your progress on getting
Clojure going on the Android platform I'm very interested in learning
more.

Thanks!
Rob

On Feb 6, 12:29 pm, "Remco van 't Veer"  wrote:
> Got startup time down to 5 seconds by completely eliminating the use
> of lispreader and putting of loading the xml, set and zip namespaces.
> There's no clear bottlenecks left to fix.
>
> On Fri, Feb 6, 2009 at 1:06 AM, Remco van 't Veer  wrote:
>
> > I've managed to get to startup time down from 12 seconds to 7 on the
> > emulator and hope get it below 4 seconds tomorrow.  A lot of time is
> > spend in LispReader when the core constants are initialized.  I've
> > altered the compiler to emit type specific code for the basic cases,
> > thus bypassing LispReader.  Need to learn more about GeneratorAdapter,
> > and need sleep, before I can speedup the loading of, for instance, seq
> > contants.
>
> > My changes are available at github;http://github.com/remvee/clojure
>
> > Remco
>
> > On Wed, Feb 4, 2009 at 5:55 PM, Remco van 't Veer  
> > wrote:
> >> Having a lisp to do android app development is definately worth some 
> >> efford.
> >> Kawa already has some android support in svn trunk but it doesn't seem in a
> >> usable state; my experiments break because a lot of expressions do not seem
> >> to compile AOT. The parts that do compile are very fast on the other hand.
>
> >> But if it comes down to app development I would of course prefer clojure
> >> over kawa's schema and scheme over java..
>
> >> I hope to do some tracing to find out what slowing down the startup later
> >> this week and will keep the list in formed. If anybody has any suggestions
> >> please yes pretty please.
>
> >> Remco
>
> >> On Feb 4, 2009 3:59 PM, "igorrumiha"  wrote:
>
> >> On Feb 4, 10:12 am, "Remco van 't Veer"  wrote: >
> >> Caching Reflector.getMethods,...
>
> >> I would also be interested in running Clojure on the Android. I tried
> >> running a "Hello world" application on the emulator but the startup
> >> time od 15 seconds put me off. There is definitely room for
> >> improvement. I don't have much experience in Java (zero would be the
> >> best description) so I don't really know where to start with
> >> profiling.
>
> >> I've run the application through the Instrumentation mechanism and the
> >> trace shows me that much of the time is spent in a huge amount of
> >> calls to some character compare methods (something like 20 calls)
> >> (I don't have the trace with me right now so I don't have the exact
> >> numbers and I don't know the exact method name).
>
> >> I find this curious when I know that all code is compiled ahead of
> >> time. When I get the chance I will recreate that call graph an upload
> >> it to the files section.
>
> >> --
> >> IgorR
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Static type guy trying to convert

[Raoul Duke]

> Another red herring: you are describing a disadvantage of nominal over
> structural typing.  Not dynamic vs static typing.

there are probably several different arguments being conflated in such
discussions.

for example, theory vs. practice: there is the theory of what in fact
are the options for typing, and then there is the practice of what
programming languages currently exist, and what of all those options
do they implement. so if there is not a popular "statically typed"
language which does "duck typing", and most people are only aware of
"statically typed" languages that don't, then that practice can easily
lead one to be confused into saying the theory of statically typed
languages don't work because they don't support "duck typing". or
statements made can be mistakenly inferred to be talking about the
theory when they are really talking about the practice.

in other words, what "statically typed" language do proponents of such
languages hold up as the one which would most likely be the least
despicable in the eyes of dyed-in-the-wool "dynamic" language folks?

(fwiw, historically i lean more towards the typed (with inference)
side than not.)

sincerely.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Debugging support for clojure?

[Howard Lewis Ship]

Just updated, working like a charm.

On Tue, Mar 10, 2009 at 5:17 PM, CuppoJava  wrote:
>
> Have you updated to the latest version?
>
> If it's setup properly, you should be able to set breakpoints by
> clicking on the grey column on the left side of your code.
>
> Also, not every line can be breakpointed. Try breakpointing some
> different lines if you're having problems there.
>  -Patrick
> >
>



-- 
Howard M. Lewis Ship

Creator Apache Tapestry and Apache HiveMind

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: What profilers are you using?

[Allen Rohner]

pmf wrote:
> On Mar 11, 4:41 am, Allen Rohner  wrote:
> > Replying to my own question because I figured it out. On the profiler
> > tab, before you hit "start profiling", click the settings checkbox.
> > Edit the "start from class" field. Mine was set to jline.**. After
> > changing it to the appropriate namespace for my app, hit the "start
> > profiling" button. Visualvm starting working reliably for me after
> > that.
>
> Thanks, this works really nice. I tried in vain to get Netbean's
> profiler to work with Clojure, but I'll think I'll stick to jvisualvm
> now.

Just FYI, I am using the standalone download of visualvm from
https://visualvm.dev.java.net/, because I couldn't find visualvm in
the Apple 1.6 JDK

Allen

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Static type guy trying to convert

[Jon Harrop]

On Wednesday 11 March 2009 15:30:01 Cosmin Stejerean wrote:
> Actually it happens a lot in real code and in many non-trivial programs in
> static typed languages you end up with a proliferation of types that are
> simply there to make the compiler happy. To me it happens very often where
> I know what I want: to pass an object of type B into a function f that
> expects type A, because I know that B is sufficiently A-like to allow
> function f to work.

Another red herring: you are describing a disadvantage of nominal over 
structural typing.  Not dynamic vs static typing.

-- 
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: On the importance of recognizing and using maps

[Cosmin Stejerean]

On Wed, Mar 11, 2009 at 12:00 PM, Konrad Hinsen
wrote:

>
> On Mar 8, 2009, at 18:53, Rich Hickey wrote:
>
> > I know people usually think of collections when they see vector/map/
> > set, and they think classes and types define something else. However,
> > the vast majority of class and type instances in various languages are
> > actually maps, and what the class/type defines is a specification of
> > what should be in the map. Many of the languages don't expose the
> > instances as maps as such and in failing to do so greatly deprive the
> > users of the language from writing generic interoperable code.
>
> My own experience is mostly with Python. Python objects are indeed
> essentially maps (Python calls them dictionaries). But even though it
> is easy to obtain the map equivalent of any object (object.__dict__),
> I hardly see this being done. Python programmers tend to use maps and
> objects in very different ways, and that includes experienced
> programmers who are very well aware that objects are just maps plus a
> type tag plus a set of methods.
>


IMHO a big reason Python programmers don't typically treat objects like is
maps/dictionaries is that the set of things found in the map (dictionary)
for that object (__dict__) are just a small subset of the interesting
attributes of the object. In Python things like class level attributes,
properties, descriptors and multiple inheritance all add a lot of
flexibility to defining and using objects that would take a some effort to
replicate on top of simple maps.
The flexibility of Python however does allow you to treat even complex
objects as dictionaries (by implementing __getitem__)  or dictionaries as
objects (by overriding __getattr__ or __getattribute___). I've used these
techniques in places where I need to treat an object like a dictionary for
interop, or places where I wanted to use a dictionary but with the nicer
syntax for attribute access on objects ( a.foo instead of a['foo'] saves 3
keystrokes).

-- 
Cosmin Stejerean
http://offbytwo.com

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from 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: cells/add-watch question

[Raffael Cavallaro]

On Mar 11, 1:24 pm, Raffael Cavallaro 
wrote:

> ;; this just makes a big map atom where integer keys are associated
> with integer values

should rather be as follows to get integer keyword keys:

(def my-atom
 (atom (assoc (apply hash-map
 (take 1000
   (interleave
(map #(keyword (str %))
 (iterate inc 0))
(iterate inc 100
 :last-update nil)))
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: cells/add-watch question

[Raffael Cavallaro]

On Mar 11, 11:20 am, linh  wrote:

> According to the API doc, add-watch must have 4 args: a key, a
> reference,
> its old-state and its new state. What I'm missing here is an addtional
> arg that can be passed in some way to update-fn so that update-fn
> knows what entries in my-atom has changed.
> Is there any way do this?


well you could always add a key :last-update containing the key
changed in the last update. Then your add-watch update function just
reads this key and knows what's been modified. To accomplish this of
course, in your

(swap! my-atom (some-fn...

some-fn would have to include code that  sets the :last-update value
when done. Here's a sketch:

;; this just makes a big map atom where integer keys are associated
with integer values

(def my-atom
 (atom (assoc (apply hash-map
 (take 1000
   (interleave
(iterate inc 0)
(iterate inc 100
 :last-update nil)))


;; this adds a watcher that knows what's been changed
;; by reading the :last-update key and prints it out

(add-watch my-atom :update-watcher
   (fn [me my-atom old new]
 (println "this key was updated" (:last-update new


;; this is the update-function that both changes the desired key
;; and val and also updates the :last-update key

(defn my-atom-swapper [the-atom key newval]
  (let [changed-atom (assoc the-atom key newval)]
(assoc changed-atom :last-update key)))

;; a simple test

(defn test-update-watcher []
  (swap! my-atom my-atom-swapper :10 "ten")
  (:10 @my-atom))
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Static type guy trying to convert

[Jon Harrop]

On Wednesday 11 March 2009 15:05:39 Konrad Hinsen wrote:
> On Mar 11, 2009, at 3:31, Jon Harrop wrote:
> > Most of the reasons given in this thread were red herrings and many
> > of static
> > typing's real issues were not even touched upon:
>
> ...
>
> I'd add two more:
>
> - Metaprogramming is a lot more complicated with static typing. Look
> at MetaOCaml or TemplateHaskell and compare to any Lisp to appreciate
> the difference. Of course, Lisp's syntactic simplicity is also an
> important factor, but type-correctness adds another level of
> complexity to metaprogramming.

I agree that static type checking metaprograms when the compiler is compiled 
does not work well (e.g. in MetaOCaml and Template Haskell) but "static" type 
checking what the run-time compiler generates works very well (e.g. JIT 
compilation in LLVM).

> - Type-related boilerplate code can make a program harder to read in
> some situations. For an example, look at Haskell's monad transformer
> implementations and compare to Clojure's. In the Haskell code,
> wrapping the real data into an algebraic data type that exists only
> for type checking, and the associated unwrapping, seriously
> obfuscates the rather simple structure of the monad transformers.

Yes, that is the best example yet IMHO.

-- 
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: On the importance of recognizing and using maps

[Konrad Hinsen]

On Mar 8, 2009, at 18:53, Rich Hickey wrote:

> I know people usually think of collections when they see vector/map/
> set, and they think classes and types define something else. However,
> the vast majority of class and type instances in various languages are
> actually maps, and what the class/type defines is a specification of
> what should be in the map. Many of the languages don't expose the
> instances as maps as such and in failing to do so greatly deprive the
> users of the language from writing generic interoperable code.

My own experience is mostly with Python. Python objects are indeed  
essentially maps (Python calls them dictionaries). But even though it  
is easy to obtain the map equivalent of any object (object.__dict__),  
I hardly see this being done. Python programmers tend to use maps and  
objects in very different ways, and that includes experienced  
programmers who are very well aware that objects are just maps plus a  
type tag plus a set of methods.

One reason why generic everything-is-a-map code is not very common is  
that the majority of object definitions include specific constraints  
on the maps, most of them of the form "the map must have a key :x  
whose value is an integer". The object's methods don't make sense for  
maps that don't satisfy the constraints, and most generic map  
operations don't make sense on most objects because they are unaware  
of the constraints and in particular don't satisfy them in their  
return values.

The one area where I have seen uses of object.__dict__ is low-level  
data massaging protocols, like serialization or storage in databases.  
And that is indeed a good reason to use just a few fundamental data  
structures to represent everything.

> Finally we have contrib.types, an algebraic data type system where
> constructors generate vectors of unnamed components as instances.
> Again, unnamed positional components are an onion of some algebraic
> data type systems, there's no need to repeat that.

Positional arguments do have their uses. In particular when there is  
only one argument, it would be an unnecessary pain to have to name  
it. On the other hand, I do see your point of having a uniform  
internal representation in the form of maps.

> I'd very much like to see these libraries be interoperable, e.g. to
> store ADTs in a database or query them with Datalog, and I know that
> would be possible if they were all using maps consistently.

One problem I see with storing ADTs (or anything with a type tag) in  
a database is that the metadata and thus the type tag would be lost  
after a storage-retrieval cycle.

Konrad.


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: What profilers are you using?

[pmf]

On Mar 11, 4:41 am, Allen Rohner  wrote:
> Replying to my own question because I figured it out. On the profiler
> tab, before you hit "start profiling", click the settings checkbox.
> Edit the "start from class" field. Mine was set to jline.**. After
> changing it to the appropriate namespace for my app, hit the "start
> profiling" button. Visualvm starting working reliably for me after
> that.

Thanks, this works really nice. I tried in vain to get Netbean's
profiler to work with Clojure, but I'll think I'll stick to jvisualvm
now.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Request: Can clojure.contrib.walk provide a reduce type operation?

[Jeffrey Straszheim]

Currently the clojure.contrib.walk code provides a nice way to perform a
depth first map operation on trees.  However, I need to fold across a tree.
It would be nice if walk provided this.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from 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: Static type guy trying to convert

[Jay Fields]

On Tue, Mar 10, 2009 at 11:44 PM, e  wrote:

>
> > My interest right now in following clojure is to learn ALL the arguments,
> including his.
>

The problems with Jon's criticisms is that they are the same fear,
uncertainty and doubt ideas that are repeated time and time again by static
language zealots. Those of us that understand the value of both static and
dynamic type systems get tired of having the same conversation time and time
again. I hate to play the "I heard this time and time again over the 3 years
of doing Ruby full time" card again, but it truly is a boring discussion
when you realise that the person you are talking to not only hasn't ever
tried to do things your way, but they are also unable to see any other point
of view. The points of zealots are largely irrelevant and they are
uninterested in understanding why, so there's no value in the discussion.

Jon's email has more of the same old mis-information.

> Apples and oranges: unit tests are not the same between dynamic and static
> code bases

This is true, in a dynamic language I can often write cleaner tests because
I don't have to follow the ceremony imposed by a staticly typed language

> because dynamic code bases rely upon a huge number of additional
> unit tests to serve as a poor man's substitute for static type checking.

This is wildly false. In fact, I successfully remove 99% of all code that
relies on any type checking. I always find the code to be cleaner.

> You are assuming that what you know is right and what the compiler wants
are
> different. IME, that is virtually unheard of in real code.

I find it every time I try to create a state or strategy pattern and I have
to write vastly more code to make a compiler happy.

Anyway, there are definitely benefits to both static and dynamic typing.
Never trust anyone that says one is universally better than another.

I'll do my best not to bite again next time.

Cheers, Jay

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: design patterns for event driven applications

[Jeffrey Straszheim]

It is impossible to give a simple answer.  You need to be more specific
about the needs of your application.  Will it need to be concurrent, for
instance?

On Tue, Mar 10, 2009 at 7:49 PM, Anatoly Yakovenko wrote:

>
> I just starting playing around with clojure, and i know nothing of
> java beyond the syntax.  I am trying to implement an interface that
> gets called by some 3rd party application whenver an event occurs.  If
> i was doing this in haskell I would serialize the events in a channel
> and write a parser to parse the events, thus avoiding ugly state
> transition code.
>
> How does one handle this in clojure?
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Static type guy trying to convert

[Cosmin Stejerean]

On Tue, Mar 10, 2009 at 9:31 PM, Jon Harrop  wrote:

[...]

>
> > 2. The whole thing does not need to be complete or even functional for
> > you to start unit testing.
>
> Apples and oranges: unit tests are not the same between dynamic and static
> code bases because dynamic code bases rely upon a huge number of additional
> unit tests to serve as a poor man's substitute for static type checking.
>

I'd love to see some evidence to support this claim of "huge number of
additional unit tests". Unit tests are there to check that a small part of a
program behaves correctly under expected conditions. Static type checking
only guards against a small set of errors in program correctness, primarily
the accidental use of a wrong type. In a dynamically typed language there
are two ways to deal with this: a) add explicit type checks at runtime to
guard against an invalid type b) add unit tests to verify that the explicit
type checks work as expected. The increase in unit testing therefore is
directly related to number of areas where I am concerned about receiving an
improper type that must be explicitly guarded against.

For example in Python strings are iterable, but in a lot of functions that
expect an iterable object receiving a string is often a sign of a mistake,
so I have a few of those functions explicitly check that they are not
dealing with strings. Situations like these are rare however so I've never
seen a significant increase in unit testing to compensate for lack of static
type checking.

[...]

>
> > 4. Not having the static type system means that if it's ever needed,
> > it will be possible for you to do what you know is right instead of
> > what the compiler wants.
>
> You are assuming that what you know is right and what the compiler wants
> are
> different. IME, that is virtually unheard of in real code.
>

Actually it happens a lot in real code and in many non-trivial programs in
static typed languages you end up with a proliferation of types that are
simply there to make the compiler happy. To me it happens very often where I
know what I want: to pass an object of type B into a function f that expects
type A, because I know that B is sufficiently A-like to allow function f to
work.


>
> Most of the reasons given in this thread were red herrings and many of
> static
> typing's real issues were not even touched upon:
>
> . Implementing modern static type systems correctly is really hard.
> Consequently, the vast majority of new languages are dynamically typed
> because that is much easier to implement.
>

I agree that implementing static type systems correctly is hard, and that
dynamic type checking is easier, but I'm not willing to just agree that many
languages use dynamic typing simply because it is easier. For example I
prefer writing code in dynamically typed languages most of the time, so if I
was to write a new language I would make it dynamically typed because that
is my preference, not because it is easier. I can imagine that there is some
subset of language designers that really would prefer to use a statically
typed language but end up not implementing it because of the difficulty, but
I'm not willing to just accept that they are the vast majority.


-- 
Cosmin Stejerean
http://offbytwo.com

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

cells/add-watch question

[linh]

I have a question about cells. I'm not sure how to explain my problem
so maybe the easiest way is to show some code.

Let's say I have this piece of code:

(def my-atom (atom {... big map with many entries ...}))
.
(add-watch my-atom :update update-fn)
.
(swap! my-atom (some-fn ...))

When my-atom changes I want the update-fn to know what has been
changed so that it won't have to compare the old my-atom with new
my-atom to see the changes. This is beacuse my-atom contains a lot
of data and I don't want to search for the change. Is there anyway I
can do this?

According to the API doc, add-watch must have 4 args: a key, a
reference,
its old-state and its new state. What I'm missing here is an addtional
arg that can be passed in some way to update-fn so that update-fn
knows what entries in my-atom has changed.
Is there any way do this?


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from 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: Static type guy trying to convert

[Konrad Hinsen]

On Mar 11, 2009, at 3:31, Jon Harrop wrote:

> Most of the reasons given in this thread were red herrings and many  
> of static
> typing's real issues were not even touched upon:

...

I'd add two more:

- Metaprogramming is a lot more complicated with static typing. Look  
at MetaOCaml or TemplateHaskell and compare to any Lisp to appreciate  
the difference. Of course, Lisp's syntactic simplicity is also an  
important factor, but type-correctness adds another level of  
complexity to metaprogramming.

- Type-related boilerplate code can make a program harder to read in  
some situations. For an example, look at Haskell's monad transformer  
implementations and compare to Clojure's. In the Haskell code,  
wrapping the real data into an algebraic data type that exists only  
for type checking, and the associated unwrapping, seriously  
obfuscates the rather simple structure of the monad transformers.

Konrad.


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from 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: Static type guy trying to convert

[Jon Harrop]

On Wednesday 11 March 2009 04:44:17 e wrote:
> ...Afterall he could have chosen a dynamically typed language for his
> business if he had wanted to...

FWIW, my company ships products written in many different languages including 
dynamic languages and I have been programming in dynamic languages for over 
25 years.

-- 
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Enjoying test-is

[stephaner]

I use test-is too, this is a very usefull test framework. The
framework is very easy to use and provide nice output when tests
fail.
Since I'm still learning Clojure, I do enjoy using the actual versus
expected output of a failed test.

Thanks again Mr. Sierra,


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Static type guy trying to convert

[Laurent PETIT]

2009/3/11 mikel mev...@mac.com

>
>
>
> Saying that something sucks and suggesting that people who like it are
> fools isn't an argument, it's just yanking people's chains to get
> attention.


Are you talking about Linus's speak against cvs, subversion and their users
? :-)


ok, this was just a joke,

-- 
laurent

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

design patterns for event driven applications

[Anatoly Yakovenko]

I just starting playing around with clojure, and i know nothing of
java beyond the syntax.  I am trying to implement an interface that
gets called by some 3rd party application whenver an event occurs.  If
i was doing this in haskell I would serialize the events in a channel
and write a parser to parse the events, thus avoiding ugly state
transition code.

How does one handle this in clojure?

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Debugging support for clojure?

[Jeffrey Straszheim]

Probably.  The Java BigInteger classes are not particularly fast, and do not
seem to be a priority to Sun.  Therefore Clojure is not competitive on large
integer algorithms.

On Wed, Mar 11, 2009 at 2:21 AM, Tassilo Horn wrote:

>
> Phil Hagelberg  writes:
>
> Hi Phil,
>
> >> If not, is there better way than inserting gazillions of printlns to
> >> check why and where a function doesn't do the right thing?
> >
> > Most definitely! Break your functions up into smaller pieces, then
> > write tests for them using test-is.  If your functions are hard to
> > test, it's probably because they need to be broken out differently.
>
> Yeah, might be.  To get started with clojure I tried to translate the
> Miller-Rabin pseudo prime algorithm from wikipedia.  Basically it seems
> to work correctly, but the preformance is really bad for numbers above a
> certain limit.
>
> Investigated it a bit more (doing the algorithm step by step in the
> repl) and now I know what's the culprit:  The `expt' function from the
> math contrib library is dead slow.
>
> For number theory you often need things like
>
>(mod (expt n exp) m)
>
> where the exponent may be very huge.  Is that something which cannot be
> done faster in Clojure because of the Java Integer/BigInteger stuff?
> That would be a shame!  I just fell in love with clojure cause the code
> looks that concise and right!
>
> Bye,
> Tassilo
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Witch Emcas for Windows to use with Clojure

[Marko Kocić]

Or you can compile emacs from CVS for yourself. It's not that hard as
it used do be.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Witch Emcas for Windows to use with Clojure

[anderspe]

Thanks, will test this.
// Anders

On 11 Mar, 12:00, Paul Drummond  wrote:
> Not sure about "XEmacs vs Gnu Emacs" but for GNU Emacs there are some
> options.  By far the best option when starting out is ClojureBox:
>
> http://clojure.bighugh.com/
>
> It's a one-click installer to get you started.  It includes everything
> you need to develop in Clojure with Emacs including Slime.
>
> If you prefer setting everything up yourself you could try EmacsW32:
>
> http://ourcomments.org/Emacs/EmacsW32.html
>
> I am currently evaluating this so I can't recommend it yet but it
> sounds promising.  It includes lots of nice features that should make
> it play nice in Windows.
>
> Paul.
> --
> Iode Software Ltd, registered in England No. 6299803.
>
> Registered Office Address: 12 Sancroft Drive, Houghton-le-Spring, Tyne
> & Wear, DH5 8NE.
>
> This message is intended only for the use of the person(s) ("the
> intended recipient(s)") to whom it is addressed. It may contain
> information which is privileged and confidential within the meaning of
> applicable law. If you are not the intended recipient, please contact
> the sender as soon as possible. The views expressed in this
> communication may not necessarily be the views held by The Company.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Witch Emcas for Windows to use with Clojure

[Paul Drummond]

Not sure about "XEmacs vs Gnu Emacs" but for GNU Emacs there are some
options.  By far the best option when starting out is ClojureBox:

http://clojure.bighugh.com/

It's a one-click installer to get you started.  It includes everything
you need to develop in Clojure with Emacs including Slime.

If you prefer setting everything up yourself you could try EmacsW32:

http://ourcomments.org/Emacs/EmacsW32.html

I am currently evaluating this so I can't recommend it yet but it
sounds promising.  It includes lots of nice features that should make
it play nice in Windows.

Paul.
-- 
Iode Software Ltd, registered in England No. 6299803.

Registered Office Address: 12 Sancroft Drive, Houghton-le-Spring, Tyne
& Wear, DH5 8NE.

This message is intended only for the use of the person(s) ("the
intended recipient(s)") to whom it is addressed. It may contain
information which is privileged and confidential within the meaning of
applicable law. If you are not the intended recipient, please contact
the sender as soon as possible. The views expressed in this
communication may not necessarily be the views held by The Company.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Witch Emcas for Windows to use with Clojure

[anderspe]

Hi!
I thinking of test to use Emacs for Clojure development, but under
Windows i have found 2 diffrent
 XEmacs or Gnu Emacs what is the recommendation, to use... ?!!
Or is it just a matter of tast..

// Anders

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: filter1 interesting?

[Laurent PETIT]

filter is lazy. first is not

3/11 Vagif Verdi 

>
> Is (first (filter ..) lazy like in haskell ?
> I would hate to wait for filter to get all results just to throw them
> out and pick the first one.
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: filter1 interesting?

[Christian Vest Hansen]

On Wed, Mar 11, 2009 at 9:01 AM, Vagif Verdi  wrote:
>
> Is (first (filter ..) lazy like in haskell ?

Yes.

> I would hate to wait for filter to get all results just to throw them
> out and pick the first one.
>
> >
>



-- 
Venlig hilsen / Kind regards,
Christian Vest Hansen.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: filter1 interesting?

[Vagif Verdi]

Is (first (filter ..) lazy like in haskell ?
I would hate to wait for filter to get all results just to throw them
out and pick the first one.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: transposing a small java class in clojure

[rb]

On Mar 10, 8:24 pm, Kevin Downey  wrote:
> I don't know how many arguments the method you are overriding with
> onLogin takes, but the function you define should take one more
> argument then the method you are overiding, the first argument being
> an explicit reference to an instance

That was it!

Here's the working function:

(defn -onLogin [this session request]
  (.severe logger "Logging in, clj")
  FtpletResult/DEFAULT)


Thanks!

Raphaël

>
>
>
> On Tue, Mar 10, 2009 at 12:16 PM, rb  wrote:
>
> > HI Chris,
>
> > thanks for your response, and I'll update the code as you suggest.
> > However, I actually have problems even when the -onLogin function is
> > empty, returns nil, or returns FtpletResult/DEFAULT. It seems it
> > causes trouble once it's defined.
>
> > I'll post an update tomorrow
>
> > Raphaël
>
> > On Mar 10, 6:50 pm, chris  wrote:
> >> I can see one possible difference, depending on how you are loading
> >> the code into the ftp server.
>
> >> In your clojure example you are accessing the logger through a top-
> >> level define.  I believe this will run *during the file loading
> >> process* as static code.
>
> >> In your working java example, you aren't accessing the logger until
> >> the actual onLogin function is called.
>
> >> If the logger is in an odd state (like null) or god forbid the runtime
> >> sets up the logger just before it calls into your function then you
> >> may get different results.  I would recommend calling the getlogger
> >> call in the function perhaps; change the 'def logger' to 'defn logger
> >> []' and work out the resulting details.  This would make the clojure
> >> example a little closer to your java example and at least eliminate
> >> one possible problem.
>
> >> Chris
>
> >> On Mar 10, 7:35 am, rb  wrote:
>
> >> > Hi,
>
> >> > I'm experimenting withhttp://mina.apache.org/ftpserver
> >> > I have written a small java class that gets used by the ftp server,
> >> > and am trying to transpose it to clojure, but unsuccessfully until
> >> > now
>
> >> > The class generated with clojure is detected and used by the server,
> >> > but the code of the method implemented is not run, and even worse, the
> >> > ftp server isn't functional anymore (though I don't see any exception
> >> > raised).
>
> >> > Does anyone have an idea about what I'm doing wrong?
>
> >> > Thanks
>
> >> > Raphaël
>
> >> > Here's the java code:
>
> >> > package com.raphinou;
>
> >> > import java.io.IOException;
> >> > import org.apache.ftpserver.*;
> >> > import org.apache.ftpserver.ftplet.*;
>
> >> > public class Ftplet extends DefaultFtplet {
> >> >     public FtpletResult onLogin(FtpSession session, FtpRequest
> >> > request)
> >> >             throws FtpException, IOException {
> >> >         java.util.logging.Logger logger=
> >> > java.util.logging.Logger.getLogger("com.raphinou");
> >> >         logger.addHandler( new java.util.logging.FileHandler("/tmp/
> >> > ftp.log"));
> >> >         logger.severe("Logging in!!");
> >> >         return FtpletResult.DEFAULT;
> >> >     }
>
> >> > }
>
> >> > and here's the clojure code:
>
> >> >  (ns com.raphinou.ftplet
> >> >   (:gen-class :name com.raphinou.Ftplet
> >> >    :extends org.apache.ftpserver.ftplet.DefaultFtplet)
> >> >   (:import [org.apache.ftpserver.ftplet DefaultFtpReply
> >> > FtpletResult]))
>
> >> > (def logger (java.util.logging.Logger/getLogger "com.raphinou"))
> >> > (.addHandler logger (java.util.logging.FileHandler. "/tmp/ftp.log"))
>
> >> > (defn -onLogin [session request]
> >> >   (.severe logger "Logging in, clj")
> >> >   FtpletResult/DEFAULT)
>
> --
> And what is good, Phaedrus,
> And what is not good—
> Need we ask anyone to tell us these things?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from 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 support for clojure?

[Tassilo Horn]

Phil Hagelberg  writes:

Hi Phil,

>> If not, is there better way than inserting gazillions of printlns to
>> check why and where a function doesn't do the right thing?
>
> Most definitely! Break your functions up into smaller pieces, then
> write tests for them using test-is.  If your functions are hard to
> test, it's probably because they need to be broken out differently.

Yeah, might be.  To get started with clojure I tried to translate the
Miller-Rabin pseudo prime algorithm from wikipedia.  Basically it seems
to work correctly, but the preformance is really bad for numbers above a
certain limit.

Investigated it a bit more (doing the algorithm step by step in the
repl) and now I know what's the culprit:  The `expt' function from the
math contrib library is dead slow.

For number theory you often need things like

(mod (expt n exp) m)

where the exponent may be very huge.  Is that something which cannot be
done faster in Clojure because of the Java Integer/BigInteger stuff?
That would be a shame!  I just fell in love with clojure cause the code
looks that concise and right!

Bye,
Tassilo

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---