Re: oo
I'm very interested in this thread. I'm having trouble figuring out exactly which situations require prefer-method and which do not. One thing that would help me understand the issues more deeply would be if someone could post the simplest possible multimethod that requires prefer-method to disambiguate. In Rich's list of ideals, I particularly appreciate the desire to be able impose a parent on a child without changing the child. This has come up for me, and I was grateful Clojure had this ability. I didn't see anything in the list of ideals that explains the lack of a next-method, and it's not really clear to me how to reap some of the benefits of inheritance without this. On a somewhat related note, as my code grows, and I'm using more complicated data structures, representing all of them as hash tables is starting to feel a little too, well, unstructured. Can anyone else report from the Clojure trenches on ways to manage this complexity? --~--~-~--~~~---~--~~ You 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: oo
I think I've answered at least part of my own question. This is the
simplest ambiguous case I've found:
ab
| |
--
|
c
user> (defmulti test-prefer :tag)
#'user/test-prefer
user> (defmethod test-prefer ::a [h] "a")
#
user> (defmethod test-prefer ::b [h] "b")
#
user> (derive ::c ::a)
nil
user> (derive ::c ::b)
nil
user> (test-prefer {:tag ::a})
"a"
user> (test-prefer {:tag ::b})
"b"
user> (test-prefer {:tag ::c})
; Evaluation aborted.
user> (prefer-method test-prefer ::a ::b)
#
user> (test-prefer {:tag ::c})
"a"
So if I understand correctly, the crux of the problem is that this
preference information is not part of the actual derive hierarchy.
This gives added flexibility to customize on a method by method basis,
but at a cost.
One cost seems to be that if an outside user wants to write a new
method on this very same type hierarchy, he can only do it if he knows
how the types are derived from one another inside the library so that
he can restate all the necessary precedences with appropriate
prefer-method calls on his own new method.
Another interesting question is whether at least test-prefer is safe
for extension. Here's a potential problem I see. Let's say that in
the above example, type ::c is what is intended to be publicly
visible, and the base classes ::a or ::b just provide the base
implementation for various methods, including prefer-method.
I may come along and want to extend test-prefer to a type ::d which
derives from ::c and ::e, where ::e provides an alternative
implementation.
ab (a and b are intended to be hidden from end-user)
| |
--
|
c e
| |
|
d
(derive ::d ::c)
(derive ::d ::e)
(defmethod test-prefer ::e [h] "e")
Now, as an external user, I know nothing about where test-prefer on
::c gets its behavior. Obviously, I have to disambiguate between
whether test-prefer chooses ::c over ::e, so I may try something like
this:
(prefer-method test-prefer ::c ::e)
But this will not work. I still get an error saying I need to
disambiguate between ::a and ::e. And not knowing anything about ::a,
I could be very confused, and not know how to provide this
information.
Considering how complex the situation can get with single dispatch, I
imagine it gets even more complex in multiple dispatch situations. In
the multimethods example at clojure.org/multimethods, an example is
given of disambiguating between [::shape ::rect] and [::rect ::shape].
But again, if you're writing the bar method from outside of the
library which defines ::shape and ::rect, you might not even know
which is more specific. It might be easier to choose a strategy, such
as more specific on the leftmost taking precedence, than to know the
details of how the various types in the library interact.
Anyway, this is my attempt to digest and restate what I've learned
from this thread and from tinkering around. Any other good examples
that illustrate some of the difficulties?
--~--~-~--~~~---~--~~
You 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: oo
On Mar 27, 2009, at 9:25, Mark Engelberg wrote: > I think I've answered at least part of my own question. This is the > simplest ambiguous case I've found: > > ab > | | > -- > | > c Indeed. An ambiguous situation can occur whenever the type hierarchy graph is not a tree. Since it takes at least three nodes to make a graph that is not a tree, your example is the simplest one possible. > So if I understand correctly, the crux of the problem is that this > preference information is not part of the actual derive hierarchy. That is one way to put it, but I think there are other possible solutions than putting the preference information into the hierarchy. > One cost seems to be that if an outside user wants to write a new > method on this very same type hierarchy, he can only do it if he knows > how the types are derived from one another inside the library so that > he can restate all the necessary precedences with appropriate > prefer-method calls on his own new method. That could be avoided with a set of utility functions/macros for placing types into a hierarchy and for defining multimethods. These utility functions could take care of adding prefer-method calls as necessary. Of course, if this is a frequent need, explicitly language support would be preferable, but at least that would be a way to experiment with design options to figure out what works best. > Now, as an external user, I know nothing about where test-prefer on > ::c gets its behavior. Obviously, I have to disambiguate between > whether test-prefer chooses ::c over ::e, so I may try something like > this: > (prefer-method test-prefer ::c ::e) > > But this will not work. I still get an error saying I need to > disambiguate between ::a and ::e. And not knowing anything about ::a, > I could be very confused, and not know how to provide this > information. True. It would be nice if prefer-method could itself figure out that ::a provides the implementation for ::c. But again that functionality can be added with utility functions, as the hierarchy can be explored using the functions parents, ancestors, and descendants. > Considering how complex the situation can get with single dispatch, I > imagine it gets even more complex in multiple dispatch situations. In > the multimethods example at clojure.org/multimethods, an example is > given of disambiguating between [::shape ::rect] and [::rect ::shape]. > But again, if you're writing the bar method from outside of the > library which defines ::shape and ::rect, you might not even know > which is more specific. It might be easier to choose a strategy, such > as more specific on the leftmost taking precedence, than to know the > details of how the various types in the library interact. I am not so sure about this. I wonder if there is a real-life use case where a client library would need to solve dispatching issues on types in another library about which it doesn't know anything. If there isn't, the problem is not relevant, and if there is, I'd like to see a demonstration that something like left-to-right precedence is indeed a reasonable default. On the other hand, I would definitely like to be able to implement left-to-right precedence myself on top of Clojure's multimethods, and it seems that at the moment this is not possible. 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 -~--~~~~--~~--~--~---
Slime bug
I think I found a bug in swank. When I execute in the SLIME REPL (loop [i 0] (when (< i 50) (println i) (recur (inc i it goes for a while (the last printed number varies greatly), then inevitably throws the exception below. This looks like a but in swank's output stream implementation. Is this the right place to report this bug? I installed SLIME for Clojure following the instructions at http://riddell.us/tutorial/slime_swank/slime_swank.html I'm a Java programmer trying to grok Clojure, so far I am very very impressed. Many kudos to the Clojure folks! Best regards, Curran Kelleher java.lang.StringIndexOutOfBoundsException: String index out of range: 6 (NO_SOURCE_FILE:0) [Thrown class clojure.lang.Compiler$CompilerException] Restarts: 0: [ABORT] Return to SLIME's top level. 1: [CAUSE] Throw cause of this exception Backtrace: 0: clojure.lang.Compiler.eval(Compiler.java:4533) 1: clojure.core$eval__3969.invoke(core.clj:1738) 2: swank.commands.basic$eval_region__650.invoke(basic.clj:35) 3: swank.commands.basic$listener_eval__659.invoke(basic.clj:49) 4: clojure.lang.Var.invoke(Var.java:346) 5: user$eval__1833.invoke(Unknown Source) 6: clojure.lang.Compiler.eval(Compiler.java:4522) 7: clojure.core$eval__3969.invoke(core.clj:1738) 8: swank.core$eval_in_emacs_package__307.invoke(core.clj:55) 9: swank.core$eval_for_emacs__382.invoke(core.clj:123) 10: clojure.lang.Var.invoke(Var.java:354) 11: clojure.lang.AFn.applyToHelper(AFn.java:179) 12: clojure.lang.Var.applyTo(Var.java:463) 13: clojure.core$apply__3228.doInvoke(core.clj:408) 14: clojure.lang.RestFn.invoke(RestFn.java:428) 15: swank.core$eval_from_control__310.invoke(core.clj:62) 16: swank.core$eval_loop__313.invoke(core.clj:67) 17: swank.core$spawn_repl_thread__441$fn__470$fn__472.invoke(core.clj: 168) 18: clojure.lang.AFn.applyToHelper(AFn.java:171) 19: clojure.lang.AFn.applyTo(AFn.java:164) 20: clojure.core$apply__3228.doInvoke(core.clj:408) 21: clojure.lang.RestFn.invoke(RestFn.java:428) 22: swank.core$spawn_repl_thread__441$fn__470.doInvoke(core.clj:165) 23: clojure.lang.RestFn.invoke(RestFn.java:402) 24: clojure.lang.AFn.run(AFn.java:37) 25: java.lang.Thread.run(Thread.java:636) Caused by: String index out of range: 6 [Thrown class java.lang.StringIndexOutOfBoundsException] Restarts: 0: [ABORT] Return to SLIME's top level. Backtrace: 0: java.lang.AbstractStringBuilder.substring (AbstractStringBuilder.java:875) 1: java.lang.StringBuffer.substring(StringBuffer.java:433) 2: swank.util.io$call_on_flush_stream__161$fn__163.invoke(io.clj:25) 3: clojure.proxy.java.io.StringWriter.flush(Unknown Source) 4: clojure.core$flush__4135.invoke(core.clj:2057) 5: clojure.core$prn__4138.doInvoke(core.clj:2066) 6: clojure.lang.RestFn.applyTo(RestFn.java:142) 7: clojure.core$apply__3228.doInvoke(core.clj:408) 8: clojure.lang.RestFn.invoke(RestFn.java:428) 9: clojure.core$println__4144.doInvoke(core.clj:2079) 10: clojure.lang.RestFn.invoke(RestFn.java:413) 11: user$eval__1836.invoke(Unknown Source) 12: clojure.lang.Compiler.eval(Compiler.java:4522) 13: clojure.core$eval__3969.invoke(core.clj:1738) 14: swank.commands.basic$eval_region__650.invoke(basic.clj:35) 15: swank.commands.basic$listener_eval__659.invoke(basic.clj:49) 16: clojure.lang.Var.invoke(Var.java:346) 17: user$eval__1833.invoke(Unknown Source) 18: clojure.lang.Compiler.eval(Compiler.java:4522) 19: clojure.core$eval__3969.invoke(core.clj:1738) 20: swank.core$eval_in_emacs_package__307.invoke(core.clj:55) 21: swank.core$eval_for_emacs__382.invoke(core.clj:123) 22: clojure.lang.Var.invoke(Var.java:354) 23: clojure.lang.AFn.applyToHelper(AFn.java:179) 24: clojure.lang.Var.applyTo(Var.java:463) 25: clojure.core$apply__3228.doInvoke(core.clj:408) 26: clojure.lang.RestFn.invoke(RestFn.java:428) 27: swank.core$eval_from_control__310.invoke(core.clj:62) 28: swank.core$eval_loop__313.invoke(core.clj:67) 29: swank.core$spawn_repl_thread__441$fn__470$fn__472.invoke(core.clj: 168) 30: clojure.lang.AFn.applyToHelper(AFn.java:171) 31: clojure.lang.AFn.applyTo(AFn.java:164) 32: clojure.core$apply__3228.doInvoke(core.clj:408) 33: clojure.lang.RestFn.invoke(RestFn.java:428) 34: swank.core$spawn_repl_thread__441$fn__470.doInvoke(core.clj:165) 35: clojure.lang.RestFn.invoke(RestFn.java:402) 36: clojure.lang.AFn.run(AFn.java:37) 37: java.lang.Thread.run(Thread.java:636) --~--~-~--~~~---~--~~ You 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 -~--~~~~--~~--~--~---
printing a ref with type metadata
Hi,
When I type the following in at the REPL:
(def foo (ref {} :meta {:type :t}))
and then try to print it, I get the following error:
java.lang.ClassCastException: clojure.lang.Ref (NO_SOURCE_FILE:0)
[Thrown class clojure.lang.Compiler$CompilerException]
Is this a bug?
Thanks,
Scott
--~--~-~--~~~---~--~~
You 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: oo
2009/3/27 Konrad Hinsen
>
> On the other hand, I would definitely like to be able to implement
> left-to-right precedence myself on top of Clojure's multimethods, and
> it seems that at the moment this is not possible.
Yes.
And also the ability to redefine the method that tries to determine
candidate dispatch values, so that one could write polymorphic functions not
only based on ahead of time defined data hierarchy graphs.
One solution could be to add more options to defmulti.
Another solution could be to have a *defmulti-flavor* global var that could
have for value some hashmap : { :dispatch-value-matcher function1
:dispatch-value-narrower function2 } that could be bound to a different
flavor for certain multifunctions by library creators.
Without that, for example, I don't know how one could prevent the
combinatorial explosion of the prefer-method calls to make, even inside the
boundaries of a library, even with simple hierarchies without multiple
inheritence, for the following problem:
A, B, C, D, E, F all inherit from Z.
The library implementor wants to provide specialized functions such as:
(defmethod a-method [A B C D] [a b c d] ...)
(defmethod a-method [A B D C] [a b d c] ...)
If the implementor is able to concisely describe the resolution mechanism
with an algorithm (a function), he still will have to implement the results
of his algorithm in terms of prefer-method declarations.
For example, the classic above cited resolution mechanism "the leftmost
specific wins" must be manually hard-coded. And in this special case it gets
even worse for extension purpose as well.
--
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
-~--~~~~--~~--~--~---
questions about clojure.contrib.error-kit
(1) Is there any reasonable way to attach handlers to lazy sequences such that the handlers will still be in place outside the original handler scope, when the sequence is finally evaluated? (It is not obvious to me how to do this without making the handler system part of the language core.) (2) When using continue-with while mapping a sequence, I find myself wanting to simply ignore error conditions (instead of having continue- with contribute nil or some error token to the sequence which I then have to filter out). What is the most idiomatic way to do this? Thanks, Stu --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
PATCH: printing a ref with type metadata
On Mar 27, 2009, at 12:55, Konrad Hinsen wrote: > I'd say yes. Here's what happens: Typing "foo" at the REPL causes a > call to clojure.core/print-method. This is a multimethod that > dispatches on the result of clojure.core/type, which is the value of > the :type tag in the metadata if there is one. Since there is no > implementation for type :t, the default implementation is called, > which is: > > (defmethod print-method :default [o, #^Writer w] > (print-method (vary-meta o #(dissoc % :type)) w)) > > It is the call to vary-meta that fails for a ref. The attached patch fixes the bug. 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 -~--~~~~--~~--~--~--- print-method.patch Description: Binary data
Re: printing a ref with type metadata
On Mar 26, 2009, at 22:44, srader wrote:
> When I type the following in at the REPL:
>
> (def foo (ref {} :meta {:type :t}))
>
> and then try to print it, I get the following error:
>
> java.lang.ClassCastException: clojure.lang.Ref (NO_SOURCE_FILE:0)
> [Thrown class clojure.lang.Compiler$CompilerException]
>
> Is this a bug?
I'd say yes. Here's what happens: Typing "foo" at the REPL causes a
call to clojure.core/print-method. This is a multimethod that
dispatches on the result of clojure.core/type, which is the value of
the :type tag in the metadata if there is one. Since there is no
implementation for type :t, the default implementation is called,
which is:
(defmethod print-method :default [o, #^Writer w]
(print-method (vary-meta o #(dissoc % :type)) w))
It is the call to vary-meta that fails for a ref.
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
-~--~~~~--~~--~--~---
Are there ways to propagate bindings to child threads?
Hi, all. Story: I couldn't understand my "binding" form behavior. (binding [*print-level* 2 *print-length* 2] (some-function)) but, some outputs didn't confirm the bound value. After some investigation on my code and output, I found the reason. - I used pmap Well, I can use "set!", but I think that's not a solution. I could "set!" *print-level* and *print-length. But I couldn't "set!" other defs defined in other ns. (I guess that's not intended use of "set!". right?) And think about something like *out*. I don't know that's intended behavior of "binding" or not. Anyway I think something like thread-propagate-binding is needed. 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: Will Clojure work on AppEngine?
Google will officially announce Java support for AppEngine at the end of May at Google IO: http://ru.ly/T6 Clojure web apps will have access to BigTable and be able to auto-scale based on load. Clojure in the cloud! Robin On Feb 2, 2:35 pm, Mark Derricutt wrote: > I wonder if the Classloader issues that currently affect OSGi would impact > an app-engine style deployment scenario as well. My understanding of the > issue is that each different classloader would pick up its own RT and > compile/generate up different versions of the core classes under each > classloader. ( I'm willing to be totally corrected here, I'm still very new > to clojure, and the issues we're seeing under OSGi ). > > ...and then Buffy staked Edward. The End. > > On Tue, Feb 3, 2009 at 8:26 AM, Robin wrote: > > > I am not an expert on the JVM, but I think Google's runtime will > > disallow uploading precompiled bytecode (jar). The assumption is that > > if you can compile it on their servers, then it is legal and therefore > > safe. I hope they allow the use of ASM library. > > > Obviously this is speculation, but can you foresee any corner cases > > where Clojure's use of ASM might be considered 'unsafe' by Google? > > > Thanks, > > > Robin > > > On Jan 29, 9:33 am, Rich Hickey wrote: > > > On Jan 27, 2:44 pm, Robin wrote: > > > > > Under a huge assumption that Google will soon announce a 'Java > > > > compatible' runtime forAppEngine. Could Clojure work out of the > > > > box? Would Clojure's dynamic generation of ASM/bytecode pose a > > > > security problem for a generic sandboxed environment? If expected > > > > conflicts exist, what kind of adaptation would it take to port > > > > Clojure? > > > > I imagine ahead-of-time compiled Clojure code would pose the least > > > challenge, at it requires no custom classloader or dynamic bytecode. > > > Currently, AOT is enabling both untrusted applets and conversion for > > > Android/Dalvik. > > > > As far as dynamic bytecode, that has a lot to do with the sandbox. > > > > Rich --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
children function for hierarchies
I noticed that core doesn't have a "children" function for hierarchies, although it has "parents", "descendants", and "ancestors". Here's one: (defn children ([tag] (set (filter (fn [t] (contains? (parents t) tag)) (descendants tag ([h tag] (set (filter (fn [t] (contains? (parents h t) tag)) (descendants h tag) The repetition is necessary because clojure.core/global-hierarchy is private. -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: Are there ways to propagate bindings to child threads?
On Fri, Mar 27, 2009 at 4:06 PM, hjlee wrote: > > Hi, all. > > Story: > I couldn't understand my "binding" form behavior. > > (binding [*print-level* 2 *print-length* 2] (some-function)) > > but, some outputs didn't confirm the bound value. > > After some investigation on my code and output, I found the reason. > - I used pmap > > Well, I can use "set!", but I think that's not a solution. > I could "set!" *print-level* and *print-length. > But I couldn't "set!" other defs defined in other ns. > (I guess that's not intended use of "set!". right?) > And think about something like *out*. > > I don't know that's intended behavior of "binding" or not. > Anyway I think something like thread-propagate-binding is needed. Maybe this explains what you are seeing? http://groups.google.com/group/clojure/browse_thread/thread/2bc20199ae5db74d/444619b6093073d5?lnk=gst&q=Unexpected+binding+behavior#444619b6093073d5 -- Michael Wood --~--~-~--~~~---~--~~ You 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 and swank on Android?
After some googling I found out that some people were able to run Clojure on Android phones. Did anyone tried to port swank to Android? It might seem like a good idea to start swank server on the phone, connnect with slime, and have good old live programming environment. Regards, Marko Kocić --~--~-~--~~~---~--~~ You 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: Are there ways to propagate bindings to child threads?
On Fri, Mar 27, 2009 at 10:06 AM, hjlee wrote: > > Hi, all. > > Story: > I couldn't understand my "binding" form behavior. > > (binding [*print-level* 2 *print-length* 2] (some-function)) > > but, some outputs didn't confirm the bound value. > > After some investigation on my code and output, I found the reason. > - I used pmap > > Well, I can use "set!", but I think that's not a solution. > I could "set!" *print-level* and *print-length. > But I couldn't "set!" other defs defined in other ns. > (I guess that's not intended use of "set!". right?) > And think about something like *out*. > You could always propagate the bindings like so: (binding [*print-level* 2 *print-length* 2] (some-function *print-level* *print-length*)) Or write a wrapper function that takes the binding values, rebinds them, and calls some-function. Of course, doing so seems like it exposes a leaky abstraction. You wouldn't necessarily expect that you'd have to write it one way for map and another for pmap, but maybe it is just a case of "programmer beware." Paul --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
extra166y
I'm attempting to run some functions in the parallel library. I've downloaded jsr166y and put it in my classpath. Apparently, all of the functions that the parallel library uses got split into another library called extra166y (and the namespace was changed as well). I figured that it would be a simple matter of changing the imported namespace in parallel.clj, but now I get the following error: Exception in thread "main" java.lang.UnsupportedClassVersionError: Bad version number in .class file (parallel.clj:0) at clojure.lang.Compiler.eval(Compiler.java:4533) at clojure.lang.Compiler.load(Compiler.java:4846) at clojure.lang.RT.loadResourceScript(RT.java:325) at clojure.lang.RT.loadResourceScript(RT.java:316) at clojure.lang.RT.load(RT.java:394) at clojure.lang.RT.load(RT.java:366) at clojure.core$load__5036$fn__5039.invoke(core.clj:3741) at clojure.core$load__5036.doInvoke(core.clj:3740) at clojure.lang.RestFn.invoke(RestFn.java:413) at clojure.core$load_one__4988.invoke(core.clj:3585) at clojure.core$load_lib__5009.doInvoke(core.clj:3622) at clojure.lang.RestFn.applyTo(RestFn.java:147) at clojure.core$apply__3228.doInvoke(core.clj:408) at clojure.lang.RestFn.invoke(RestFn.java:443) at clojure.core$load_libs__5021.doInvoke(core.clj:3648) at clojure.lang.RestFn.applyTo(RestFn.java:142) at clojure.core$apply__3228.doInvoke(core.clj:408) at clojure.lang.RestFn.invoke(RestFn.java:443) at clojure.core$require__5027.doInvoke(core.clj:3708) at clojure.lang.RestFn.invoke(RestFn.java:426) at user$eval__79.invoke(alg.clj:1) at clojure.lang.Compiler.eval(Compiler.java:4522) at clojure.lang.Compiler.load(Compiler.java:4846) at clojure.lang.RT.loadResourceScript(RT.java:325) at clojure.lang.RT.loadResourceScript(RT.java:316) at clojure.lang.RT.load(RT.java:394) at clojure.lang.RT.load(RT.java:366) at clojure.core$load__5036$fn__5039.invoke(core.clj:3741) at clojure.core$load__5036.doInvoke(core.clj:3740) at clojure.lang.RestFn.invoke(RestFn.java:413) at clojure.core$load_one__4988.invoke(core.clj:3585) at clojure.core$load_lib__5009.doInvoke(core.clj:3622) at clojure.lang.RestFn.applyTo(RestFn.java:147) at clojure.core$apply__3228.doInvoke(core.clj:408) at clojure.lang.RestFn.invoke(RestFn.java:443) at clojure.core$load_libs__5021.doInvoke(core.clj:3648) at clojure.lang.RestFn.applyTo(RestFn.java:142) at clojure.core$apply__3228.doInvoke(core.clj:408) at clojure.lang.RestFn.invoke(RestFn.java:443) at clojure.core$require__5027.doInvoke(core.clj:3708) at clojure.lang.RestFn.invoke(RestFn.java:413) at user$eval__76.invoke(main.clj:6) at clojure.lang.Compiler.eval(Compiler.java:4522) at clojure.lang.Compiler.load(Compiler.java:4846) at clojure.lang.Compiler.loadFile(Compiler.java:4813) at clojure.main$load_script__5793.invoke(main.clj:206) at clojure.main$init_opt__5796.invoke(main.clj:211) at clojure.main$initialize__5806.invoke(main.clj:239) at clojure.main$null_opt__5828.invoke(main.clj:264) at clojure.main$legacy_script__5843.invoke(main.clj:295) at clojure.lang.Var.invoke(Var.java:346) at clojure.main.legacy_script(main.java:34) at clojure.lang.Script.main(Script.java:20) Caused by: java.lang.UnsupportedClassVersionError: Bad version number in .class file at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:675) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java: 124) at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) at java.net.URLClassLoader.access$100(URLClassLoader.java:56) at java.net.URLClassLoader$1.run(URLClassLoader.java:195) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at java.lang.ClassLoader.loadClass(ClassLoader.java:316) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:280) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:374) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:242) at clojure.lang.RT.classForName(RT.java:1486) at clojure.core$import__4007.doInvoke(core.clj:1870) at clojure.lang.RestFn.invoke(RestFn.java:413) at clojure.parallel$eval__91.invoke(parallel.clj:38) at clojure.lang.Compiler.eval(Compiler.java:4522) ... 52 more Is there any way to fix this? --~--~-~--~~
Re: extra166y
Hi Jason, If you use the jsr166y from the files section of the group (http:// clojure.googlegroups.com/web/jsr166y.jar) you should be okay. I know this doesn't help with the exception you are getting, but it may get you moving forward. Cheers, Tom http://clojure-log.n01se.net/date/2009-01-31.html#12:19 On Mar 27, 1:55 pm, Jason Baker wrote: > I'm attempting to run some functions in the parallel library. I've > downloaded jsr166y and put it in my classpath. Apparently, all of the > functions that the parallel library uses got split into another > library called extra166y (and the namespace was changed as well). I > figured that it would be a simple matter of changing the imported > namespace in parallel.clj, but now I get the following error: > > Exception in thread "main" java.lang.UnsupportedClassVersionError: Bad > version number in .class file (parallel.clj:0) > at clojure.lang.Compiler.eval(Compiler.java:4533) > at clojure.lang.Compiler.load(Compiler.java:4846) > at clojure.lang.RT.loadResourceScript(RT.java:325) > at clojure.lang.RT.loadResourceScript(RT.java:316) > at clojure.lang.RT.load(RT.java:394) > at clojure.lang.RT.load(RT.java:366) > at clojure.core$load__5036$fn__5039.invoke(core.clj:3741) > at clojure.core$load__5036.doInvoke(core.clj:3740) > at clojure.lang.RestFn.invoke(RestFn.java:413) > at clojure.core$load_one__4988.invoke(core.clj:3585) > at clojure.core$load_lib__5009.doInvoke(core.clj:3622) > at clojure.lang.RestFn.applyTo(RestFn.java:147) > at clojure.core$apply__3228.doInvoke(core.clj:408) > at clojure.lang.RestFn.invoke(RestFn.java:443) > at clojure.core$load_libs__5021.doInvoke(core.clj:3648) > at clojure.lang.RestFn.applyTo(RestFn.java:142) > at clojure.core$apply__3228.doInvoke(core.clj:408) > at clojure.lang.RestFn.invoke(RestFn.java:443) > at clojure.core$require__5027.doInvoke(core.clj:3708) > at clojure.lang.RestFn.invoke(RestFn.java:426) > at user$eval__79.invoke(alg.clj:1) > at clojure.lang.Compiler.eval(Compiler.java:4522) > at clojure.lang.Compiler.load(Compiler.java:4846) > at clojure.lang.RT.loadResourceScript(RT.java:325) > at clojure.lang.RT.loadResourceScript(RT.java:316) > at clojure.lang.RT.load(RT.java:394) > at clojure.lang.RT.load(RT.java:366) > at clojure.core$load__5036$fn__5039.invoke(core.clj:3741) > at clojure.core$load__5036.doInvoke(core.clj:3740) > at clojure.lang.RestFn.invoke(RestFn.java:413) > at clojure.core$load_one__4988.invoke(core.clj:3585) > at clojure.core$load_lib__5009.doInvoke(core.clj:3622) > at clojure.lang.RestFn.applyTo(RestFn.java:147) > at clojure.core$apply__3228.doInvoke(core.clj:408) > at clojure.lang.RestFn.invoke(RestFn.java:443) > at clojure.core$load_libs__5021.doInvoke(core.clj:3648) > at clojure.lang.RestFn.applyTo(RestFn.java:142) > at clojure.core$apply__3228.doInvoke(core.clj:408) > at clojure.lang.RestFn.invoke(RestFn.java:443) > at clojure.core$require__5027.doInvoke(core.clj:3708) > at clojure.lang.RestFn.invoke(RestFn.java:413) > at user$eval__76.invoke(main.clj:6) > at clojure.lang.Compiler.eval(Compiler.java:4522) > at clojure.lang.Compiler.load(Compiler.java:4846) > at clojure.lang.Compiler.loadFile(Compiler.java:4813) > at clojure.main$load_script__5793.invoke(main.clj:206) > at clojure.main$init_opt__5796.invoke(main.clj:211) > at clojure.main$initialize__5806.invoke(main.clj:239) > at clojure.main$null_opt__5828.invoke(main.clj:264) > at clojure.main$legacy_script__5843.invoke(main.clj:295) > at clojure.lang.Var.invoke(Var.java:346) > at clojure.main.legacy_script(main.java:34) > at clojure.lang.Script.main(Script.java:20) > Caused by: java.lang.UnsupportedClassVersionError: Bad version number > in .class file > at java.lang.ClassLoader.defineClass1(Native Method) > at java.lang.ClassLoader.defineClass(ClassLoader.java:675) > at java.security.SecureClassLoader.defineClass(SecureClassLoader.java: > 124) > at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) > at java.net.URLClassLoader.access$100(URLClassLoader.java:56) > at java.net.URLClassLoader$1.run(URLClassLoader.java:195) > at java.security.AccessController.doPrivileged(Native Method) > at java.net.URLClassLoader.findClass(URLClassLoader.java:188) > at java.lang.ClassLoader.loadClass(ClassLoader.java:316) > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:280) > at java.lang.ClassLoader.loadClass(ClassLoader.java:306) > at java.lang.ClassLoader.loadClass(ClassLoader.java:251) > at java.lang.ClassLoader.loa
Scala vs Clojure
Can anyone who has tried both of these languages to a decent degree compare them in practical terms? In other words, I am not interested in the technical aspects of the languages themselves (e.g. dynamic vs static typing) but things like IDE support, tools (lexers and parsers), standard libraries, books and their quality, existing commercial applications and the commercial viability of shipping products targeted at their programmers (e.g. libraries)? I've never done anything significant on the JVM so I'm interested in picking one of these two languages and shipping a product for it. I've done a lot of commercial work with F# over the past 2 years but all Microsoft-related sales have died this year so I'm looking to diversify... Many thanks, -- 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: oo
On Mar 27, 5:56 am, Konrad Hinsen wrote: > On Mar 27, 2009, at 9:25, Mark Engelberg wrote: > > Considering how complex the situation can get with single dispatch, I > > imagine it gets even more complex in multiple dispatch situations. In > > the multimethods example at clojure.org/multimethods, an example is > > given of disambiguating between [::shape ::rect] and [::rect ::shape]. > > But again, if you're writing the bar method from outside of the > > library which defines ::shape and ::rect, you might not even know > > which is more specific. It might be easier to choose a strategy, such > > as more specific on the leftmost taking precedence, than to know the > > details of how the various types in the library interact. > > I am not so sure about this. I wonder if there is a real-life use > case where a client library would need to solve dispatching issues on > types in another library about which it doesn't know anything. No, because such a library won't get used. If I offered a customer a library with the caveat that his people might run into unexpected dispatch conflicts that could be solved simply by reading the library sources, he'd say, "thanks, I'll pass." > If > there isn't, the problem is not relevant, and if there is, I'd like > to see a demonstration that something like left-to-right precedence > is indeed a reasonable default. I can tell you about large software projects in which left-to-right precedence worked well. "Demonstrate"? That's a lot of code to recapitulate! There is nothing magical about left-to-right precedence, except that *you know in advance what it is*. You can reason about it, because you know what it is. You can predict what kinds of uses will be a problem, and therefore can avoid those problems. For purposes of writing reusable and extensible subsystems, *any* defined order is better than no defined order. > On the other hand, I would definitely like to be able to implement > left-to-right precedence myself on top of Clojure's multimethods, and > it seems that at the moment this is not possible. There it is: it's fine if Clojure doesn't define a default and universal traversal order for MultiFn dispatch, as long as I can define such an order when I need it. prefer-method isn't quite enough, because it only works on dispatch values that are already defined. In order to make a safely-extensible library, I need to be able to prescribe a traversal order over dispatch values that haven't yet been created. I have a separate issue with prefer-method, in that it defines traversal order implicitly, in a way that is hard to digest. That is, you can't look in one place to find out what the traversal is; you instead have to search out all the prefer-method calls and piece the order together from examining each of them. That's tangential to the present discussion, though. If none of these considerations moves Rich much, that's okay. He gave us the tools we need to write our own solutions. --~--~-~--~~~---~--~~ You 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: PATCH: printing a ref with type metadata
Thanks for the explanation and the patch. But instead of patching print-method, maybe vary-meta should be patched to handle refs? Scott On Mar 27, 7:07 am, Konrad Hinsen wrote: > On Mar 27, 2009, at 12:55, Konrad Hinsen wrote: > > > I'd say yes. Here's what happens: Typing "foo" at the REPL causes a > > call to clojure.core/print-method. This is a multimethod that > > dispatches on the result of clojure.core/type, which is the value of > > the :type tag in the metadata if there is one. Since there is no > > implementation for type :t, the default implementation is called, > > which is: > > > (defmethod print-method :default [o, #^Writer w] > > (print-method (vary-meta o #(dissoc % :type)) w)) > > > It is the call to vary-meta that fails for a ref. > > The attached patch fixes the bug. > > Konrad. > > print-method.patch > < 1KViewDownload > > --~--~-~--~~~---~--~~ You 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: oo
On Fri, Mar 27, 2009 at 4:58 PM, mikel wrote:
>
>
>
> On Mar 27, 5:56 am, Konrad Hinsen wrote:
>> On Mar 27, 2009, at 9:25, Mark Engelberg wrote:
>
>> > Considering how complex the situation can get with single dispatch, I
>> > imagine it gets even more complex in multiple dispatch situations. In
>> > the multimethods example at clojure.org/multimethods, an example is
>> > given of disambiguating between [::shape ::rect] and [::rect ::shape].
>> > But again, if you're writing the bar method from outside of the
>> > library which defines ::shape and ::rect, you might not even know
>> > which is more specific. It might be easier to choose a strategy, such
>> > as more specific on the leftmost taking precedence, than to know the
>> > details of how the various types in the library interact.
>>
>> I am not so sure about this. I wonder if there is a real-life use
>> case where a client library would need to solve dispatching issues on
>> types in another library about which it doesn't know anything.
>
> No, because such a library won't get used. If I offered a customer a
> library with the caveat that his people might run into unexpected
> dispatch conflicts that could be solved simply by reading the library
> sources, he'd say, "thanks, I'll pass."
>
>> If
>> there isn't, the problem is not relevant, and if there is, I'd like
>> to see a demonstration that something like left-to-right precedence
>> is indeed a reasonable default.
>
> I can tell you about large software projects in which left-to-right
> precedence worked well. "Demonstrate"? That's a lot of code to
> recapitulate!
>
> There is nothing magical about left-to-right precedence, except that
> *you know in advance what it is*. You can reason about it, because you
> know what it is. You can predict what kinds of uses will be a problem,
> and therefore can avoid those problems. For purposes of writing
> reusable and extensible subsystems, *any* defined order is better than
> no defined order.
>
>> On the other hand, I would definitely like to be able to implement
>> left-to-right precedence myself on top of Clojure's multimethods, and
>> it seems that at the moment this is not possible.
>
> There it is: it's fine if Clojure doesn't define a default and
> universal traversal order for MultiFn dispatch, as long as I can
> define such an order when I need it. prefer-method isn't quite enough,
> because it only works on dispatch values that are already defined. In
> order to make a safely-extensible library, I need to be able to
> prescribe a traversal order over dispatch values that haven't yet been
> created.
>
> I have a separate issue with prefer-method, in that it defines
> traversal order implicitly, in a way that is hard to digest. That is,
> you can't look in one place to find out what the traversal is; you
> instead have to search out all the prefer-method calls and piece the
> order together from examining each of them. That's tangential to the
> present discussion, though.
>
There is prefers:
(prefers print-method)
-> {clojure.lang.ISeq #{clojure.lang.IPersistentCollection
java.util.Collection}, clojure.lang.IPersistentList
#{clojure.lang.ISeq}}
> If none of these considerations moves Rich much, that's okay. He gave
> us the tools we need to write our own solutions.
Hang tight - I hear your concerns and am thinking about them.
Rich
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
Characters allowed in symbols
The Clojure documentation, under "Reader", gives a list of characters allowed in a symbol name. The characters, <, >, and = are not included in this list. How is it then that <, <=, >, >=, =, etc. are symbols? (I assume they are symbols because I can write (< 3 4), etc.) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Characters allowed in symbols
On Fri, Mar 27, 2009 at 5:51 PM, ke...@ksvanhorn.com wrote: > > The Clojure documentation, under "Reader", gives a list of characters > allowed in a symbol name. The characters, <, >, and = are not > included in this list. How is it then that <, <=, >, >=, =, etc. are > symbols? (I assume they are symbols because I can write (< 3 4), > etc.) Looks like the documentation is out of date: user> (def <>= 3) #'user/<>= user> <>= 3 Cheers, Victor R. > > > --~--~-~--~~~---~--~~ You 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: oo
On Mar 25, 3:44 am, Konrad Hinsen wrote: > I haven't thought much about extending types yet. It could mean > opening the can of worms associated with inheritance and all that. I > am waiting for a concrete situation where extension would be useful > to think about how best to do it. The main thread of this conversation has wandered off into multiple dispatch and various approaches to dealing with that, but the topic you touch on here is also interesting. It's probably about time I experimented with your types library. I've been using my own extremely simple model library, but I've been eyeballing clojure.contrib.types, meaning to see if I like it better. (Why would I use either one? Because I want a convenient way to write definitions in source code that say what fields are to be expected and allowed in application data.) --~--~-~--~~~---~--~~ You 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 -~--~~~~--~~--~--~---
"(binding ...)" form and "pmap" (was: Are there ways to propagate bindings to child threads?)
I wrote a question, but I think my point was not clear. I wanted some trace output of my codes, but my code uses heavily liked structure. After I found out there are vars that controls output, I tried that. Let's consider below codes. (I made runnable example.) (The main differenece from real code and example is that - printing of args/returns done by "trace" library, not by the 'pmaped' function itself) - Not much relation to lazy things. - Not much relation to closure. ;; BEGIN --- ;; this is *EXAMPLE* codes. ;; So don't ask things like why pass a range instead of a number. (defn pmaped [r] (println "pmaped - called with - " r) ;; think as trace output (Thread/sleep (rand 200)) (let [ret (reduce + r)] (println "pmaped returns - " ret) ret)) (defn some-fn ([] (some-fn 100)) ([n] (let [square (fn [x] (* x x)) rs (map range (range n))] (reduce + (pmap pmaped rs) ;; END - ; Consider this (binding [*print-length* 2] (some-fn 10)) ; Some time needed to figure out why above code does not work as I expected. ; That's because I used pmap. ; Environment of threads created(or picked in pool) by pmap do not keep that of caller. ; But am I wrong to expect pmap to behave similar to map? ; Yes I expect order of side effects differs, but not the effects itself. ;; My (non-)solution - (binding [*print-length* 2 pmap map] ;; ^^ (some-fn 10)) ;; But how about this? (borrowed from another group thread.) (use 'clojure.contrib.duck-streams) (defmacro with-out-as [f & body] `(with-open [w# (writer ~f)] (binding [*out* w#] ~...@body))) (with-out-as "/tmp/trace.out" (some-fn 10)) ; That means if I can use macros like above, ; I have to be sure all called functions do not use multi-threading facilities, ; which is not practical. --~--~-~--~~~---~--~~ You 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 -~--~~~~--~~--~--~---
Loading clojure in a custom ClassLoader
Hi,
I want a Java application to support evaluation of older and newer
clojure scripts that may not run on the same clojure versions/
releases. I want to support this without restarting the application.
The approach I'm trying is to load clojure from its own classloader.
My idea is to GC the classloader whenever a clojure version is not
required anymore. Rinse and repeat.
At this point, it doesn't work.
Clojure is NOT in the classpath. I use a custom URLClassLoader which
is given the right clojure path dynamically. However, clojure throws
an Exception because it seems to disregard the classloader it is being
loaded with. Instead, it uses the system class loader (or a child or
the system class loader). Moreover, I can't call RT.addURL because the
exception is thrown from static initializer blocks. The exception is
shown below.
Example code which throws:
// urls contain path to clojure
URLClassLoader classLoader = new URLClassLoader(urls);
// Below: doesn't work
Class.forName("clojure.core__init", true, classLoader);
Class.forName("clojure.lang.RT", true, classLoader);
Class.forName("clojure.lang.Compiler", true, classLoader);
// This works but throws whenever _methClojureLoad is called
clazz = classLoader.loadClass("clojure.lang.Compiler");
_methClojureLoad = clazz.getMethod("load", Reader.class, String.class,
String.class);
Am I wasting my time with this approach? Is there even a way to do
what I want?
Thanks,
Max
Exception in thread "main" java.lang.ExceptionInInitializerError
at clojure.core__init.(Unknown Source)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Unknown Source)
at DocumentMgr.loadClojure(DocumentMgr.java:198)
at DocumentMgr.newDocument(DocumentMgr.java:73)
at Application.start(Application.java:105)
at Application.main(Application.java:41)
Caused by: java.lang.RuntimeException: java.io.FileNotFoundException:
Could not locate clojure/core__init.class or clojure/core.clj on
classpath:
at clojure.lang.RT.(RT.java:290)
... 7 more
Caused by: java.io.FileNotFoundException: Could not locate clojure/
core__init.class or clojure/core.clj on classpath:
at clojure.lang.RT.load(RT.java:409)
at clojure.lang.RT.load(RT.java:376)
at clojure.lang.RT.doInit(RT.java:413)
at clojure.lang.RT.(RT.java:286)
... 7 more
--~--~-~--~~~---~--~~
You 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: Scala vs Clojure
I sure hope this topic doesn't start a flamewar. I've used both languages, with Clojure being used more. Scala is more mature than Clojure, so you really have to put that in perspective when comparing the languages. Scala's IDE support is superior to Clojure's but not for long as all three major IDE's are having plugins developed for them and I'd say Enclojure is close to production-ready. As for tools, both languages are doing okay there as they both have the support of Java libraries. Clojure is more directly compatible /from/ Java than Scala. Clojure's standard library is evolving fast and should soon outweigh Scalas. There is a single book written for Clojure that will ship in a few months. Scala has one book as well with several being written. But Clojure is only 2 years old! We know Clojure was used in some hospital software a while back, as for Scala I can't say. I like both languages. I like Clojure better. Clojure is awesome. On Mar 27, 3:20 pm, Jon Harrop wrote: > Can anyone who has tried both of these languages to a decent degree compare > them in practical terms? In other words, I am not interested in the technical > aspects of the languages themselves (e.g. dynamic vs static typing) but > things like IDE support, tools (lexers and parsers), standard libraries, > books and their quality, existing commercial applications and the commercial > viability of shipping products targeted at their programmers (e.g. > libraries)? > > I've never done anything significant on the JVM so I'm interested in picking > one of these two languages and shipping a product for it. I've done a lot of > commercial work with F# over the past 2 years but all Microsoft-related sales > have died this year so I'm looking to diversify... > > Many thanks, > -- > 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 -~--~~~~--~~--~--~---
