coercion automatically calling a user defined coercion multimethod in case of type mismatch with arguments passed to a type hinted function..
Hello everybody, I was just wondering if we could have functions automatically call a multimethod whose dispatch-value would be a vector typename of the current argument and required argument type. and accept the return value of that function as the argument in place of the current argument. I know that the typenames are just hints ..but was wondering if we can make this happen .. I think that would be really usefull.. Just a thought. Thanks Sunil. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Purpose of Macros
I'm watching Richs' excellent Clojure for Java developers videos. One comment he makes puzzles me though. He is elaborating about how powerful macro abstraction is. The specific argument he gives is closing files in Java and how macros save you typing the exact thing. I don't quite get what he means by this. How is a (close-file "file") macro any more efficient/abstract/etc... than a (close-file "file") function? -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Purpose of Macros
I'm watching Richs' excellent Clojure for Java developers videos. One comment he makes puzzles me though. He is elaborating about how powerful macro abstraction is. The specific argument he gives is closing files in Java and how macros save you typing the exact thing. I don't quite get what he means by this. How is a (close-file "file") macro any more efficient/abstract/etc... than a (close-file "file") function? -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Purpose of Macros
In Java, you often have to pair things, e.g. opening a file and
closing it, to avoid leaking resources like file handles.
These pairings are among many cases where Java code contains structure
that you can't extract and reify in your program.
Macros make it possible to extract any such pattern, reify it, and
call it. Instead of a recurring pattern of
FileInputStream x = null;
try {
x = f.open(opts);
doSomethingWith(x);
} finally {
if (x != null) x.close();
}
you can convert all the crud into an abstraction and call it, like this:
(with-open [x (.open f opts)]
(do-something-with x))
All the constant stuff that would be repeated every time you open a
file is gone; just which file, what options, what to call the stream
temporarily, and what to do with the stream remains, along with the
*fact* that you're opening some sort of a closeable stream and using
it.
Macros get you closer to the ideal of specifying every fact in exactly
one place in your code. Here that fact is "how you ensure the file you
open gets closed, including if an exception gets thrown while you're
reading from it". In Java you have to tell the compiler how you do so
over and over again at every I/O site; in Clojure you can tell the
compiler how you do so once, calling this new abstraction with-open,
and then at your I/O sites just tell the compiler with-open.
In this instance, it's already done for you; with-open is part of
core. In other instances you may spot a similar pattern of repetitive
code but one that isn't already addressed in such a manner and then
you can convert it into a callable abstraction yourself.
The big decision point is: function or macro? In fact, the basic
behavior of with-open could be implemented as a function:
(defn with-open-fn [stream f]
(try
(f stream)
(finally
(.close stream
and called like so:
(with-open-fn (.open some-file) #(do-something-with %))
The macro here just acts as syntactic sugar to let you avoid the #(
... % ...) closure around the body of code you want to run on the
stream, and to let you name the stream something other than just %.
In that sort of case it's good to have both the function and the
macro; the macro can expand into a call to the function while having
the nicer syntax.
You absolutely *need* a macro if you need to control whether, when,
and in what order arguments are evaluated (e.g. implementing flow
control structures).
(Interestingly, it's even possible to implement with-open's behavior
as a Java method:
public interface NullaryFn {
Object doIt () throws Exception;
}
public interface UnaryFn {
Object doIt (Object argument) throws Exception;
}
public class WithOpen {
public static Object withOpen (NullaryFn streamMaker, UnaryFn fn)
throws Exception {
Stream x = null;
try {
x = (Stream)(streamMaker.doIt());
return fn.doIt(x);
} finally {
if (x) x.close();
}
}
}
final File f = whatever;
WithOpen.withOpen(
new NullaryFn(){public doIt(){return f.open();}},
new UnaryFn(){public doIt(Object s){return doSomethingWith((Stream)s);}});
Look at that ugly call syntax, though. This is what you get because of
a) Java lacking a decent syntax for closures, b) Java's strong typing
(now you need casts everywhere; generics lets you get rid of that at
the expense of having s and s everywhere instead), and c)
Java's checked exceptions gimmick (now everything gets contaminated
with "throws Exception;").
And your file related code is buried in just as much boilerplate junk
as before, if not even more of it.
Actually, the Clojure code turns into bytecode more or less equivalent
to what you get with the above Java. (It actually wraps exceptions at
function boundaries in RuntimeException instead of declaring throws
Exception on every method; and you may need to type-hint the .open
target to get a straight method call instead of a bunch of calls to
the Reflection API; otherwise, more or less the same.) But the Clojure
compiler lets you write closures with #(.open f) instead of new
NullaryFn{blah, blah, blah} and have global callable entities like
with-open that don't need a SomeClass. prefix tacked on, as well as
leaving out all the type names, casts, and other nonsuch.
And it lets *you* eliminate whole new classes of syntactic salt the
compiler writers couldn't have known about, by writing your own macros
that, in essence, extend the compiler. Any long repetitive structure
of code that *can't* be made much nicer and still work properly by
abstracting it into a function generally *can* be made much nicer and
still work properly by abstracting it into a macro, and sometimes a
macro can make things slightly nicer than a function (e.g., if the
function will generally be called with an inline closure as one of its
arguments, a macro with [other-args & body] parameters is good
syntactic sugar to use, preferably writing the function and then
making the macro emit a call
Re: Purpose of Macros
On Mon, Nov 29, 2010 at 3:29 PM, Ken Wesson wrote: > In Java, you often have to pair things, e.g. opening a file and > closing it, to avoid leaking resources like file handles. > > These pairings are among many cases where Java code contains structure > that you can't extract and reify in your program. Well, most things _can_ be reified in Java but resulting code would be so bloated, cumbersome and often inefficient so I do not try to do that anymore in Java. That is result of such refactoring only makes program even worse (here I wrote about my attempts in this direction http://petrglad.blogspot.com/2010/02/stream-close-template.html). Sorry, just nitpicking. -- Petr Gladkikh -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Symbol evaluation error in let
That was really neat ken ... eval-with-local-vars.. I think it should be part of the core... Sunil. On Sun, Nov 28, 2010 at 8:02 AM, Ken Wesson wrote: > Caveat: since eval-with-local-vars is a macro you won't be able to > directly use it in HOFs. Wrapping it in a closure works, however: > > user=> (let [a 1 b 2] (map #(eval-with-local-vars [a b] %) ['(+ a b) '(* a > b)])) > (3 2) > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Reusing Clojure libraries in Java/Jythom/Scala
Hi, From today, I will not receive updates from this group, so if anyone cares to answer this question, please send me an email: dil...@gmail.com. I do think that this is an important question to many people that liked a lot the Clojure concurrency model but cannot use Clojure in their day to day programs. Cheers, Dilvan On Nov 22, 12:58 pm, Dilvan wrote: > Hi, > > During the discussions of the topic "Jython Interoperability > problem", > Mikhail Kryshen suggested implementations of Clojure data structures > outside Clojure: > > >Clojure's data structures modified for use outside of Clojure: > >http://github.com/krukow/clj-ds > >Persistent analogue of the Java Collections Framework: > >http://code.google.com/p/pcollections/ > > I've been using the Clojure libraries (immutable collections and > Refs) in Java programs (a version of the Manchester OWL-API). Reading > the documentation for the Clojure replacements suggested by Mikhail, > they imply that the implementations inside the official Clojure > libraries are inefficient (in terms of speed and memory) if used in > Java only applications (no Clojure code) AND that, in the future, they > may demand that all of the Clojure machinery be loaded with them. Is > there any official view/police about this issue? > > The question I need to answer is: Should I keep using the Clojure > libraries in my programs or migrate them to some other implementation > of immutable collections + Refs (STM) + (maybe) actors? > > Advices are welcomed :-) > > DIlvanMoreira -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Symbol evaluation error in let
Hi Ken, Just wrapping your macro with the following would save you the trouble of having to enumerate the local variables ... (defmacro eval-with-local-bindings [sexp] `(eval-with-local-vars ~(apply vector (keys &env)) ~sexp)) Sunil. On Mon, Nov 29, 2010 at 6:22 PM, Sunil S Nandihalli < sunil.nandiha...@gmail.com> wrote: > That was really neat ken ... eval-with-local-vars.. I think it should be > part of the core... > Sunil. > > > On Sun, Nov 28, 2010 at 8:02 AM, Ken Wesson wrote: > >> Caveat: since eval-with-local-vars is a macro you won't be able to >> directly use it in HOFs. Wrapping it in a closure works, however: >> >> user=> (let [a 1 b 2] (map #(eval-with-local-vars [a b] %) ['(+ a b) '(* a >> b)])) >> (3 2) >> >> -- >> You received this message because you are subscribed to the Google >> Groups "Clojure" group. >> To post to this group, send email to clojure@googlegroups.com >> Note that posts from new members are moderated - please be patient with >> your first post. >> To unsubscribe from this group, send email to >> clojure+unsubscr...@googlegroups.com >> For more options, visit this group at >> http://groups.google.com/group/clojure?hl=en >> > > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: ANN: Dr. Evil - the evil web debugger
On Nov 22, 6:43 pm, Miki wrote: > >Dr.Evilis a simple web debugger that provides a REPL to your web > > application in a "hidden" location. This is pretty useful, thanks! I tried adding Dr. Evil into a test app, but I'm having trouble switching namespaces in the REPL: => *ns* # => (in-ns 'cv-test-1.core) # => *ns* # It seems to always reset the namespace to clojure.core. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: why not change > < type compare functions do a compare on strings as well?
Performance. > why not change > < type compare functions do a compare on strings as > well? > > (defn > > ([x] true) > ([x y](if (string? x) >(. clojure.lang.Numbers (isPos (.compareTo x y))) >(. clojure.lang.Numbers (gt x y > ([x y & more] > (if (> x y) >(if (next more) >(recur y (first more) (next more)) >(> y (first more))) >false))) > > (defn < > ([x] true) > ([x y](if (string? x) >(. clojure.lang.Numbers (isNeg (.compareTo x y))) >(. clojure.lang.Numbers (gt x y > ([x y & more] > (if (< x y) >(if (next more) >(recur y (first more) (next more)) >(< y (first more))) >false))) > > > It's just cleaner so we can do things like: > > user=> (< "2010-06-11" "2010-11-01") > true > > user=> (< "Banana" "Apple") > false > > make sense? > > Notes: > * I ran a bunch of benchmarks, showing no real impact on performance. > * probably would need to include >= and <= too. > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: dosync style
I'd say the former was more idiomatic Clojure. There's no need to make
refs compatible with atoms (otherwise why have two different
concurrency primitives in the first place).
Additionally, earmuffs (like *this*) should only be used on vars that
you expect to override in a binding, like *out* or *err*. They aren't
for all global vars. You should rename "*counts*" to just "counts".
- James
On 28 November 2010 22:36, Takahiro Hozumi wrote:
> Hi,
> This is trivial question.
> Which style do you like?
>
> (def *counts* (ref {}))
>
> (defn dec-or-dissoc! [key]
> (dosync
> (let [n (@*counts* key)]
> (if (< 1 n)
> (alter *counts* assoc key (dec n))
> (alter *counts* dissoc key)
>
> (defn dec-or-dissoc! [key]
> (dosync
> (alter *counts*
> (fn [m]
> (let [n (m key)]
> (if (< 1 n)
> (assoc m key (dec n))
> (dissoc m key)))
>
> I think former style is normal, but latter is easy to replace ref with
> atom.
> Thanks.
>
> --
> Takahiro Hozumi
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: why not change > < type compare functions do a compare on strings as well?
IMHO, any built-in string compare should support collations. I think this belongs in contrib in string. On Nov 29, 2:59 am, Tim Robinson wrote: > why not change > < type compare functions do a compare on strings as > well? > > (defn > > ([x] true) > ([x y](if (string? x) > (. clojure.lang.Numbers (isPos (.compareTo x y))) > (. clojure.lang.Numbers (gt x y > ([x y & more] > (if (> x y) > (if (next more) > (recur y (first more) (next more)) > (> y (first more))) > false))) > > (defn < > ([x] true) > ([x y](if (string? x) > (. clojure.lang.Numbers (isNeg (.compareTo x y))) > (. clojure.lang.Numbers (gt x y > ([x y & more] > (if (< x y) > (if (next more) > (recur y (first more) (next more)) > (< y (first more))) > false))) > > It's just cleaner so we can do things like: > > user=> (< "2010-06-11" "2010-11-01") > true > > user=> (< "Banana" "Apple") > false > > make sense? > > Notes: > * I ran a bunch of benchmarks, showing no real impact on performance. > * probably would need to include >= and <= too. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: why not change > < type compare functions do a compare on strings as well?
I think it will make more sense to branch on whether something is Comparable or IComparable, than a string. On Mon, Nov 29, 2010 at 08:59, Tim Robinson wrote: > why not change > < type compare functions do a compare on strings as > well? > > (defn > > ([x] true) > ([x y](if (string? x) > (. clojure.lang.Numbers (isPos (.compareTo x y))) > (. clojure.lang.Numbers (gt x y > ([x y & more] > (if (> x y) > (if (next more) > (recur y (first more) (next more)) > (> y (first more))) > false))) > > (defn < > ([x] true) > ([x y](if (string? x) > (. clojure.lang.Numbers (isNeg (.compareTo x y))) > (. clojure.lang.Numbers (gt x y > ([x y & more] > (if (< x y) > (if (next more) > (recur y (first more) (next more)) > (< y (first more))) > false))) > > > It's just cleaner so we can do things like: > > user=> (< "2010-06-11" "2010-11-01") > true > > user=> (< "Banana" "Apple") > false > > make sense? > > Notes: > * I ran a bunch of benchmarks, showing no real impact on performance. > * probably would need to include >= and <= too. > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- 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 Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: dosync style
I must respectfully disagree with James's first point here. The first pattern
(read-ponder-update) is not concurrency-friendly. It isn't about atom vs. ref,
the important distinction is whether all the work can be done in a function
that gets sent *to* the ref. The latter formulation also can be extracted into
a pure function, which is easier to test.
The bang suffix "!" is generally reserved for functions that are not safe in a
transaction. If you are using atoms, you should have the bang, if using refs,
you shouldn't.
Stu
> I'd say the former was more idiomatic Clojure. There's no need to make
> refs compatible with atoms (otherwise why have two different
> concurrency primitives in the first place).
>
> Additionally, earmuffs (like *this*) should only be used on vars that
> you expect to override in a binding, like *out* or *err*. They aren't
> for all global vars. You should rename "*counts*" to just "counts".
>
> - James
>
> On 28 November 2010 22:36, Takahiro Hozumi wrote:
>> Hi,
>> This is trivial question.
>> Which style do you like?
>>
>> (def *counts* (ref {}))
>>
>> (defn dec-or-dissoc! [key]
>> (dosync
>> (let [n (@*counts* key)]
>> (if (< 1 n)
>> (alter *counts* assoc key (dec n))
>> (alter *counts* dissoc key)
>>
>> (defn dec-or-dissoc! [key]
>> (dosync
>> (alter *counts*
>> (fn [m]
>>(let [n (m key)]
>> (if (< 1 n)
>>(assoc m key (dec n))
>>(dissoc m key)))
>>
>> I think former style is normal, but latter is easy to replace ref with
>> atom.
>> Thanks.
>>
>> --
>> Takahiro Hozumi
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with your
>> first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: dosync style
2010/11/29 Stuart Halloway
> I must respectfully disagree with James's first point here. The first
> pattern (read-ponder-update) is not concurrency-friendly. It isn't about
> atom vs. ref, the important distinction is whether all the work can be done
> in a function that gets sent *to* the ref. The latter formulation also can
> be extracted into a pure function, which is easier to test.
>
Yep, and in this case it *seems* that using commute could be useful as well
(and thus one more point for the latter form).
Though, I fail to see from a point of view of "correctness", why the former
form is not concurrency-friendly ?
>
> The bang suffix "!" is generally reserved for functions that are not safe
> in a transaction. If you are using atoms, you should have the bang, if using
> refs, you shouldn't.
>
> Stu
>
> > I'd say the former was more idiomatic Clojure. There's no need to make
> > refs compatible with atoms (otherwise why have two different
> > concurrency primitives in the first place).
> >
> > Additionally, earmuffs (like *this*) should only be used on vars that
> > you expect to override in a binding, like *out* or *err*. They aren't
> > for all global vars. You should rename "*counts*" to just "counts".
> >
> > - James
> >
> > On 28 November 2010 22:36, Takahiro Hozumi
> wrote:
> >> Hi,
> >> This is trivial question.
> >> Which style do you like?
> >>
> >> (def *counts* (ref {}))
> >>
> >> (defn dec-or-dissoc! [key]
> >> (dosync
> >> (let [n (@*counts* key)]
> >> (if (< 1 n)
> >> (alter *counts* assoc key (dec n))
> >> (alter *counts* dissoc key)
> >>
> >> (defn dec-or-dissoc! [key]
> >> (dosync
> >> (alter *counts*
> >> (fn [m]
> >>(let [n (m key)]
> >> (if (< 1 n)
> >>(assoc m key (dec n))
> >>(dissoc m key)))
> >>
> >> I think former style is normal, but latter is easy to replace ref with
> >> atom.
> >> Thanks.
> >>
> >> --
> >> Takahiro Hozumi
> >>
> >> --
> >> You received this message because you are subscribed to the Google
> >> Groups "Clojure" group.
> >> To post to this group, send email to clojure@googlegroups.com
> >> Note that posts from new members are moderated - please be patient with
> your first post.
> >> To unsubscribe from this group, send email to
> >> clojure+unsubscr...@googlegroups.com
> >> For more options, visit this group at
> >> http://groups.google.com/group/clojure?hl=en
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clojure@googlegroups.com
> > Note that posts from new members are moderated - please be patient with
> your first post.
> > To unsubscribe from this group, send email to
> > clojure+unsubscr...@googlegroups.com
> > For more options, visit this group at
> > http://groups.google.com/group/clojure?hl=en
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
>
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: dosync style
I think it is because concurrent stuff can happen between let and
alter in the first example. Is it true that in that case, one would
have to use "ensure" to make the operation correct?
On Nov 29, 5:53 pm, Laurent PETIT wrote:
> 2010/11/29 Stuart Halloway
>
> > I must respectfully disagree with James's first point here. The first
> > pattern (read-ponder-update) is not concurrency-friendly. It isn't about
> > atom vs. ref, the important distinction is whether all the work can be done
> > in a function that gets sent *to* the ref. The latter formulation also can
> > be extracted into a pure function, which is easier to test.
>
> Yep, and in this case it *seems* that using commute could be useful as well
> (and thus one more point for the latter form).
>
> Though, I fail to see from a point of view of "correctness", why the former
> form is not concurrency-friendly ?
>
>
>
>
>
>
>
>
>
> > The bang suffix "!" is generally reserved for functions that are not safe
> > in a transaction. If you are using atoms, you should have the bang, if using
> > refs, you shouldn't.
>
> > Stu
>
> > > I'd say the former was more idiomatic Clojure. There's no need to make
> > > refs compatible with atoms (otherwise why have two different
> > > concurrency primitives in the first place).
>
> > > Additionally, earmuffs (like *this*) should only be used on vars that
> > > you expect to override in a binding, like *out* or *err*. They aren't
> > > for all global vars. You should rename "*counts*" to just "counts".
>
> > > - James
>
> > > On 28 November 2010 22:36, Takahiro Hozumi
> > wrote:
> > >> Hi,
> > >> This is trivial question.
> > >> Which style do you like?
>
> > >> (def *counts* (ref {}))
>
> > >> (defn dec-or-dissoc! [key]
> > >> (dosync
> > >> (let [n (@*counts* key)]
> > >> (if (< 1 n)
> > >> (alter *counts* assoc key (dec n))
> > >> (alter *counts* dissoc key)
>
> > >> (defn dec-or-dissoc! [key]
> > >> (dosync
> > >> (alter *counts*
> > >> (fn [m]
> > >> (let [n (m key)]
> > >> (if (< 1 n)
> > >> (assoc m key (dec n))
> > >> (dissoc m key)))
>
> > >> I think former style is normal, but latter is easy to replace ref with
> > >> atom.
> > >> Thanks.
>
> > >> --
> > >> Takahiro Hozumi
>
> > >> --
> > >> You received this message because you are subscribed to the Google
> > >> Groups "Clojure" group.
> > >> To post to this group, send email to clojure@googlegroups.com
> > >> Note that posts from new members are moderated - please be patient with
> > your first post.
> > >> To unsubscribe from this group, send email to
> > >> clojure+unsubscr...@googlegroups.com > >> >
> > >> For more options, visit this group at
> > >>http://groups.google.com/group/clojure?hl=en
>
> > > --
> > > You received this message because you are subscribed to the Google
> > > Groups "Clojure" group.
> > > To post to this group, send email to clojure@googlegroups.com
> > > Note that posts from new members are moderated - please be patient with
> > your first post.
> > > To unsubscribe from this group, send email to
> > > clojure+unsubscr...@googlegroups.com > > >
> > > For more options, visit this group at
> > >http://groups.google.com/group/clojure?hl=en
>
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clojure@googlegroups.com
> > Note that posts from new members are moderated - please be patient with
> > your first post.
> > To unsubscribe from this group, send email to
> > clojure+unsubscr...@googlegroups.com > >
> > For more options, visit this group at
> >http://groups.google.com/group/clojure?hl=en
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: dosync style
2010/11/29 Jozef Wagner
> I think it is because concurrent stuff can happen between let and
> alter in the first example. Is it true that in that case, one would
> have to use "ensure" to make the operation correct?
>
That's my point (at least the way I understand it, I do not use a lot of
concurrency features of clojure yet) :
you would have to use ensure if you were to rely on the read value for the
computation of another value, but since you alter the ref, there should be
no need to ensure, and the problem would not be with "correctness", more
with "performance" (avoid transaction retries).
Hmm, that's maybe what Stu wanted to say by "concurrency *friendly*", after
all
>
> On Nov 29, 5:53 pm, Laurent PETIT wrote:
> > 2010/11/29 Stuart Halloway
> >
> > > I must respectfully disagree with James's first point here. The first
> > > pattern (read-ponder-update) is not concurrency-friendly. It isn't
> about
> > > atom vs. ref, the important distinction is whether all the work can be
> done
> > > in a function that gets sent *to* the ref. The latter formulation also
> can
> > > be extracted into a pure function, which is easier to test.
> >
> > Yep, and in this case it *seems* that using commute could be useful as
> well
> > (and thus one more point for the latter form).
> >
> > Though, I fail to see from a point of view of "correctness", why the
> former
> > form is not concurrency-friendly ?
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > > The bang suffix "!" is generally reserved for functions that are not
> safe
> > > in a transaction. If you are using atoms, you should have the bang, if
> using
> > > refs, you shouldn't.
> >
> > > Stu
> >
> > > > I'd say the former was more idiomatic Clojure. There's no need to
> make
> > > > refs compatible with atoms (otherwise why have two different
> > > > concurrency primitives in the first place).
> >
> > > > Additionally, earmuffs (like *this*) should only be used on vars that
> > > > you expect to override in a binding, like *out* or *err*. They aren't
> > > > for all global vars. You should rename "*counts*" to just "counts".
> >
> > > > - James
> >
> > > > On 28 November 2010 22:36, Takahiro Hozumi
> > > wrote:
> > > >> Hi,
> > > >> This is trivial question.
> > > >> Which style do you like?
> >
> > > >> (def *counts* (ref {}))
> >
> > > >> (defn dec-or-dissoc! [key]
> > > >> (dosync
> > > >> (let [n (@*counts* key)]
> > > >> (if (< 1 n)
> > > >> (alter *counts* assoc key (dec n))
> > > >> (alter *counts* dissoc key)
> >
> > > >> (defn dec-or-dissoc! [key]
> > > >> (dosync
> > > >> (alter *counts*
> > > >> (fn [m]
> > > >>(let [n (m key)]
> > > >> (if (< 1 n)
> > > >>(assoc m key (dec n))
> > > >>(dissoc m key)))
> >
> > > >> I think former style is normal, but latter is easy to replace ref
> with
> > > >> atom.
> > > >> Thanks.
> >
> > > >> --
> > > >> Takahiro Hozumi
> >
> > > >> --
> > > >> You received this message because you are subscribed to the Google
> > > >> Groups "Clojure" group.
> > > >> To post to this group, send email to clojure@googlegroups.com
> > > >> Note that posts from new members are moderated - please be patient
> with
> > > your first post.
> > > >> To unsubscribe from this group, send email to
> > > >> clojure+unsubscr...@googlegroups.com
> >
> > > >> For more options, visit this group at
> > > >>http://groups.google.com/group/clojure?hl=en
> >
> > > > --
> > > > You received this message because you are subscribed to the Google
> > > > Groups "Clojure" group.
> > > > To post to this group, send email to clojure@googlegroups.com
> > > > Note that posts from new members are moderated - please be patient
> with
> > > your first post.
> > > > To unsubscribe from this group, send email to
> > > > clojure+unsubscr...@googlegroups.com
> >
> > > > For more options, visit this group at
> > > >http://groups.google.com/group/clojure?hl=en
> >
> > > --
> > > You received this message because you are subscribed to the Google
> > > Groups "Clojure" group.
> > > To post to this group, send email to clojure@googlegroups.com
> > > Note that posts from new members are moderated - please be patient with
> > > your first post.
> > > To unsubscribe from this group, send email to
> > > clojure+unsubscr...@googlegroups.com
> >
> > > For more options, visit this group at
> > >http://groups.google.com/group/clojure?hl=en
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
>
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this
Re: ANN: Dr. Evil - the evil web debugger
> This is pretty useful, thanks! Glad someone other than me likes it :) > I tried adding Dr. Evil into a test app, but I'm having trouble > switching namespaces in the REPL: > > => *ns* > # > => (in-ns 'cv-test-1.core) > # > => *ns* > # > > It seems to always reset the namespace to clojure.core. Yeah, it uses "load-string" which IMO default to clojure.core namespace. I've tried some namespace hacking to allow the user to define the namespace, but couldn't make it work (there's a FIXME in the code about that). Currently I using names with namespace - (cv-test-1.core/some-func arg1 arg2). Will try to fix that soon. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: why not change > < type compare functions do a compare on strings as well?
I dunno, Where is this arbitrary point people set where language improvements/ ease-of-use become less important than negligible performance impacts? I ran several benchmarks, with warm up and correct time measurements, and didn't get the impression the change was in anyway significant. Take the existing function. I'm guessing 90+% of all usage is comparing 2 items, or at least not needing to handle a list of monotonically decreasing ordered items. Using the performance argument, I could suggest stripping out the (next more) check and instead break it further down into 2 separate functions. And I would also argue that handling strings, is a more valuable check than handling monotonically decreasing ordered items. Not trying to knock your comment, but unless there's more to your comment not being shared, I'm not sold on it being a real issue. On Nov 29, 7:45 am, Stuart Halloway wrote: > Performance. > > > why not change > < type compare functions do a compare on strings as > > well? > > > (defn > > > ([x] true) > > ([x y](if (string? x) > > (. clojure.lang.Numbers (isPos (.compareTo x y))) > > (. clojure.lang.Numbers (gt x y > > ([x y & more] > > (if (> x y) > > (if (next more) > > (recur y (first more) (next more)) > > (> y (first more))) > > false))) > > > (defn < > > ([x] true) > > ([x y](if (string? x) > > (. clojure.lang.Numbers (isNeg (.compareTo x y))) > > (. clojure.lang.Numbers (gt x y > > ([x y & more] > > (if (< x y) > > (if (next more) > > (recur y (first more) (next more)) > > (< y (first more))) > > false))) > > > It's just cleaner so we can do things like: > > > user=> (< "2010-06-11" "2010-11-01") > > true > > > user=> (< "Banana" "Apple") > > false > > > make sense? > > > Notes: > > * I ran a bunch of benchmarks, showing no real impact on performance. > > * probably would need to include >= and <= too. > > > -- > > You received this message because you are subscribed to the Google > > Groups "Clojure" group. > > To post to this group, send email to clojure@googlegroups.com > > Note that posts from new members are moderated - please be patient with > > your first post. > > To unsubscribe from this group, send email to > > clojure+unsubscr...@googlegroups.com > > For more options, visit this group at > >http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Why isn't there a fold-right?
Hi, Am 28.11.2010 um 21:33 schrieb Asim Jalis: > This looks like map rather than foldr. > > On Sun, Nov 28, 2010 at 7:40 AM, tpeng wrote: >> i have a one: >> (defn lazy-foldr [f coll] >>(lazy-seq >>(if-let [[x & xs] coll] >>(cons x (lazy-foldr f xs) >> >> it seems works so far ;-p This is just mapping the identity over the input seq. ;-p And it also gives a wrong result for an input coll like []. Sincerely Meikel -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: why not change > < type compare functions do a compare on strings as well?
On Mon, Nov 29, 2010 at 2:28 PM, Tim Robinson wrote: > I dunno, > > Where is this arbitrary point people set where language improvements/ > ease-of-use become less important than negligible performance impacts? > I ran several benchmarks, with warm up and correct time measurements, > and didn't get the impression the change was in anyway significant. > Perhaps not significant to you. But to others it means that they can write high performance data structures in Clojure itself that other people can benefit from. To me that's far more compelling than convenient string comparison operators. Consider the implementation of gvec.clj: https://github.com/clojure/clojure/blob/master/src/clj/clojure/gvec.clj. I wonder what "negligible performance impact" you change would have on that? It might more sense to put what you're suggesting in clojure.string. David -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Purpose of Macros
On Mon, Nov 29, 2010 at 6:28 AM, Petr Gladkikh wrote:
> On Mon, Nov 29, 2010 at 3:29 PM, Ken Wesson wrote:
>> In Java, you often have to pair things, e.g. opening a file and
>> closing it, to avoid leaking resources like file handles.
>>
>> These pairings are among many cases where Java code contains structure
>> that you can't extract and reify in your program.
>
> Well, most things _can_ be reified in Java but resulting code would be
> so bloated, cumbersome and often inefficient so I do not try to do
> that anymore in Java. That is result of such refactoring only makes
> program even worse (here I wrote about my attempts in this direction
> http://petrglad.blogspot.com/2010/02/stream-close-template.html).
That's basically what I meant. If you try, at best you end up with crap like
final File f = whatever;
WithOpen.withOpen(
new NullaryFn(){public doIt(){return f.open();}},
new UnaryFn(){public doIt(Object s){return doSomethingWith((Stream)s);}});
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Symbol evaluation error in let
On Mon, Nov 29, 2010 at 8:31 AM, Sunil S Nandihalli wrote: > Hi Ken, > Just wrapping your macro with the following would save you the trouble of > having to enumerate the local variables ... > (defmacro eval-with-local-bindings [sexp] > `(eval-with-local-vars ~(apply vector (keys &env)) ~sexp)) Yeah, nifty. I didn't know about &env when I wrote eval-with-local-vars. :) -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: why not change > < type compare functions do a compare on strings as well?
+1 String comparisons that don't support i18n collations are next to useless, IMO. A bare < or > operator can't "do the right thing" in the general case for strings. Stuart's and David's points about performance are compelling too. On Mon, Nov 29, 2010 at 7:24 AM, Alyssa Kwan wrote: > IMHO, any built-in string compare should support collations. I think > this belongs in contrib in string. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: why not change > < type compare functions do a compare on strings as well?
huh? Making a change to the > function doesn't mean you *can't* write high performance data structures in Clojure. It just means, you *may* need to use a different fn name as opposed to the common one. Similarly I could simply use a different name to accomplish my own function that includes strings, but that's not the point. The point is that the common name should benefit the common user (not typically the folks who appear in this group, but still representing 90+ percent of usage). Many people would benefit by having a cleaner easy-to-use intuitive language. i.e '=' works on strings, so why not '>' ? It's not like I don't get the benefits listed, but I think this group should also consider audiences outside the arena of expert language programmers (who are capable of making functions to suit their needs). IMHO. On Nov 29, 1:23 pm, David Nolen wrote: > On Mon, Nov 29, 2010 at 2:28 PM, Tim Robinson wrote: > > > I dunno, > > > Where is this arbitrary point people set where language improvements/ > > ease-of-use become less important than negligible performance impacts? > > I ran several benchmarks, with warm up and correct time measurements, > > and didn't get the impression the change was in anyway significant. > > Perhaps not significant to you. But to others it means that they can write > high performance data structures in Clojure itself that other people can > benefit from. To me that's far more compelling than convenient string > comparison operators. Consider the implementation of > gvec.clj:https://github.com/clojure/clojure/blob/master/src/clj/clojure/gvec.clj. > I > wonder what "negligible performance impact" you change would have on that? > > It might more sense to put what you're suggesting in clojure.string. > > David -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: dosync style
On Nov 28, 5:36 pm, Takahiro Hozumi wrote: > Which style do you like? This one: > (defn dec-or-dissoc! [key] > (dosync > (alter *counts* > (fn [m] > (let [n (m key)] > (if (< 1 n) > (assoc m key (dec n)) > (dissoc m key))) I like to avoid deref'ing inside alter, instead relying on the value passed in to the altering function. The other one looks more like imperative code. -S -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: coercion automatically calling a user defined coercion multimethod in case of type mismatch with arguments passed to a type hinted function..
Hi Sunil, This is one of those things that seems really useful for development, but ends up being a lot of trouble down the road. For one thing, it's hard to make it perform well. For another, it can lead to unexpected results when you add in inheritance hierarchies and overloaded methods. -S On Nov 29, 3:20 am, Sunil S Nandihalli wrote: > Hello everybody, > I was just wondering if we could have functions automatically call a > multimethod whose dispatch-value would be a vector typename of the current > argument and required argument type. and accept the return value of that > function as the argument in place of the current argument. I know that the > typenames are just hints ..but was wondering if we can make this happen .. I > think that would be really usefull.. Just a thought. > Thanks > Sunil. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: why not change > < type compare functions do a compare on strings as well?
But the facilities for what you want are already there. Define a more generic > < and exclude the ones from core. I'm constantly excluding fns from core which have names I'd rather use in my own source. David On Monday, November 29, 2010, Tim Robinson wrote: > huh? Making a change to the > function doesn't mean you *can't* write > high performance data structures in Clojure. It just means, you *may* > need to use a different fn name as opposed to the common one. > Similarly I could simply use a different name to accomplish my own > function that includes strings, but that's not the point. > > The point is that the common name should benefit the common user (not > typically the folks who appear in this group, but still representing > 90+ percent of usage). Many people would benefit by having a cleaner > easy-to-use intuitive language. i.e '=' works on strings, so why not > '>' ? It's not like I don't get the benefits listed, but I think this > group should also consider audiences outside the arena of expert > language programmers (who are capable of making functions to suit > their needs). IMHO. > > On Nov 29, 1:23 pm, David Nolen wrote: >> On Mon, Nov 29, 2010 at 2:28 PM, Tim Robinson wrote: >> >> > I dunno, >> >> > Where is this arbitrary point people set where language improvements/ >> > ease-of-use become less important than negligible performance impacts? >> > I ran several benchmarks, with warm up and correct time measurements, >> > and didn't get the impression the change was in anyway significant. >> >> Perhaps not significant to you. But to others it means that they can write >> high performance data structures in Clojure itself that other people can >> benefit from. To me that's far more compelling than convenient string >> comparison operators. Consider the implementation of >> gvec.clj:https://github.com/clojure/clojure/blob/master/src/clj/clojure/gvec.clj. >> I >> wonder what "negligible performance impact" you change would have on that? >> >> It might more sense to put what you're suggesting in clojure.string. >> >> David > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: why not change > < type compare functions do a compare on strings as well?
I already do that, but that doesn't help general masses of people who would benefit from consistent & intuitive language constructs. On Nov 29, 5:57 pm, David Nolen wrote: > But the facilities for what you want are already there. Define a more > generic > < and exclude the ones from core. > > I'm constantly excluding fns from core which have names I'd rather use > in my own source. > > David > > On Monday, November 29, 2010, Tim Robinson wrote: > > huh? Making a change to the > function doesn't mean you *can't* write > > high performance data structures in Clojure. It just means, you *may* > > need to use a different fn name as opposed to the common one. > > Similarly I could simply use a different name to accomplish my own > > function that includes strings, but that's not the point. > > > The point is that the common name should benefit the common user (not > > typically the folks who appear in this group, but still representing > > 90+ percent of usage). Many people would benefit by having a cleaner > > easy-to-use intuitive language. i.e '=' works on strings, so why not > > '>' ? It's not like I don't get the benefits listed, but I think this > > group should also consider audiences outside the arena of expert > > language programmers (who are capable of making functions to suit > > their needs). IMHO. > > > On Nov 29, 1:23 pm, David Nolen wrote: > >> On Mon, Nov 29, 2010 at 2:28 PM, Tim Robinson > >> wrote: > > >> > I dunno, > > >> > Where is this arbitrary point people set where language improvements/ > >> > ease-of-use become less important than negligible performance impacts? > >> > I ran several benchmarks, with warm up and correct time measurements, > >> > and didn't get the impression the change was in anyway significant. > > >> Perhaps not significant to you. But to others it means that they can write > >> high performance data structures in Clojure itself that other people can > >> benefit from. To me that's far more compelling than convenient string > >> comparison operators. Consider the implementation of > >> gvec.clj:https://github.com/clojure/clojure/blob/master/src/clj/clojure/gvec.clj. > >> I > >> wonder what "negligible performance impact" you change would have on that? > > >> It might more sense to put what you're suggesting in clojure.string. > > >> David > > > -- > > You received this message because you are subscribed to the Google > > Groups "Clojure" group. > > To post to this group, send email to clojure@googlegroups.com > > Note that posts from new members are moderated - please be patient with > > your first post. > > To unsubscribe from this group, send email to > > clojure+unsubscr...@googlegroups.com > > For more options, visit this group at > >http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this 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 calling set on an existing set shortcircuit the call and return the same set or would it create a new one?
On Mon, Nov 29, 2010 at 8:07 PM, Sunil S Nandihalli
wrote:
> Hello everybody,
> I have a small doubt. Suppose
> (def s #{1 2 3 4 5 6})
> (set s)
> will calling set on an existing set shortcircuit the call and return the
> same set or would it create a new one? I would like to extend the question
> to hash-map and vec..
> thanks,
> Sunil.
Why not just test it for yourself?
user=> (def s #{1 2 3 4 5 6})
#'user/s
user=> (= s (set s))
true
user=> (identical? s (set s))
false
Looks like it creates a new object, in the specific case of sets.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: dosync style
On Mon, Nov 29, 2010 at 7:42 PM, Stuart Sierra wrote: > On Nov 28, 5:36 pm, Takahiro Hozumi wrote: >> Which style do you like? > > This one: > >> (defn dec-or-dissoc! [key] >> (dosync >> (alter *counts* >> (fn [m] >> (let [n (m key)] >> (if (< 1 n) >> (assoc m key (dec n)) >> (dissoc m key))) > > I like to avoid deref'ing inside alter, instead relying on the value > passed in to the altering function. > > The other one looks more like imperative code. +1. As another commenter noted, this has the added benefit that the function passed to alter can be extracted and given its own name reflecting is purpose. In this case, you might write (defn dec-or-dissoc [m k] (let [n (m k)] (if (> n 1) (assoc m k (dec n)) (dissoc m k and then (defn drop-count! [k] (dosync (alter *counts* dec-or-dissoc k))) This makes dec-or-dissoc into a pure function that can be tested easily; the amount of code inside (dosync ... ) is kept to a minimum. A rule of thumb to consider is that a line of code inside (dosync ... ) is 10x as much work to debug as a line of code in a pure function, because of the potential long range interactions whenever you have stateful behavior. If dec-or-dissoc! seems to be doing the wrong thing, it may be a bug in the actual meat of the logic, or a problem with the transaction, or something contaminated *counts* with bogus data that makes dec-or-dissoc! choke (e.g. a nonnumeric value for a key), or it's actually working perfectly and some *other* transaction is screwing up *counts* a moment later. Isolating the meat of the dec-or-dissoc function into a pure function lets you test it separately from all that other crap, and the drop-count! function is so bare-bones you can eyeball debug it and see that it can't possibly be wrong, so if anything is going wrong it's going wrong somewhere else. Another way this facilitates debugging is that we can easily tack a (println k n) in drop-or-dissoc right after let [n ...] and a) generate a console log of the count values at decrement events -- in particular if a nonnumeric value is getting in there it will show up just before the CCE it causes to be thrown and you'll actually see what the nonnumeric object actually was -- and b) the println itself won't be buried in a deeply nested set of functions where it's more likely to be forgotten when it's no longer needed for debugging. :) You can also reuse dec-or-dissoc if you eventually have more cases where you want to decrement and remove numbers in associative structures; whereas dec-or-dissoc! only worked on *counts*, dec-or-dissoc works on any map and (with numeric keys) on vectors too. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: will calling set on an existing set shortcircuit the call and return the same set or would it create a new one?
Thanks Ken,
I didn't realize I could test it so easily. But I would like it to ideally
return the same collection .. Shouldn't be hard to write a wrapper .. But I
think it should be the default behaviour.
Thanks again,
Sunil.
On Tue, Nov 30, 2010 at 7:05 AM, Ken Wesson wrote:
> On Mon, Nov 29, 2010 at 8:07 PM, Sunil S Nandihalli
> wrote:
> > Hello everybody,
> > I have a small doubt. Suppose
> > (def s #{1 2 3 4 5 6})
> > (set s)
> > will calling set on an existing set shortcircuit the call and return the
> > same set or would it create a new one? I would like to extend the
> question
> > to hash-map and vec..
> > thanks,
> > Sunil.
>
> Why not just test it for yourself?
>
> user=> (def s #{1 2 3 4 5 6})
> #'user/s
> user=> (= s (set s))
> true
> user=> (identical? s (set s))
> false
>
> Looks like it creates a new object, in the specific case of sets.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: why not change > < type compare functions do a compare on strings as well?
On Mon, Nov 29, 2010 at 8:05 PM, Tim Robinson wrote: > I already do that, but that doesn't help general masses of people who > would benefit from consistent & intuitive language constructs. I've never wanted such a feature. But perhaps many people do. However from what I've seen the past couple of years, Clojure tends to emphasize performance while providing acceptable fallbacks for those cases where people want something more flexible / dynamic. And things are continuing to move in that direction - not the other way around. David > On Nov 29, 5:57 pm, David Nolen wrote: > > But the facilities for what you want are already there. Define a more > > generic > < and exclude the ones from core. > > > > I'm constantly excluding fns from core which have names I'd rather use > > in my own source. > > > > David > > > > On Monday, November 29, 2010, Tim Robinson > wrote: > > > huh? Making a change to the > function doesn't mean you *can't* write > > > high performance data structures in Clojure. It just means, you *may* > > > need to use a different fn name as opposed to the common one. > > > Similarly I could simply use a different name to accomplish my own > > > function that includes strings, but that's not the point. > > > > > The point is that the common name should benefit the common user (not > > > typically the folks who appear in this group, but still representing > > > 90+ percent of usage). Many people would benefit by having a cleaner > > > easy-to-use intuitive language. i.e '=' works on strings, so why not > > > '>' ? It's not like I don't get the benefits listed, but I think this > > > group should also consider audiences outside the arena of expert > > > language programmers (who are capable of making functions to suit > > > their needs). IMHO. > > > > > On Nov 29, 1:23 pm, David Nolen wrote: > > >> On Mon, Nov 29, 2010 at 2:28 PM, Tim Robinson < > tim.blacks...@gmail.com>wrote: > > > > >> > I dunno, > > > > >> > Where is this arbitrary point people set where language > improvements/ > > >> > ease-of-use become less important than negligible performance > impacts? > > >> > I ran several benchmarks, with warm up and correct time > measurements, > > >> > and didn't get the impression the change was in anyway significant. > > > > >> Perhaps not significant to you. But to others it means that they can > write > > >> high performance data structures in Clojure itself that other people > can > > >> benefit from. To me that's far more compelling than convenient string > > >> comparison operators. Consider the implementation of gvec.clj: > https://github.com/clojure/clojure/blob/master/src/clj/clojure/gvec.clj. I > > >> wonder what "negligible performance impact" you change would have on > that? > > > > >> It might more sense to put what you're suggesting in clojure.string. > > > > >> David > > > > > -- > > > You received this message because you are subscribed to the Google > > > Groups "Clojure" group. > > > To post to this group, send email to clojure@googlegroups.com > > > Note that posts from new members are moderated - please be patient with > your first post. > > > To unsubscribe from this group, send email to > > > clojure+unsubscr...@googlegroups.com > > > For more options, visit this group at > > >http://groups.google.com/group/clojure?hl=en > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: coercion automatically calling a user defined coercion multimethod in case of type mismatch with arguments passed to a type hinted function..
Thanks Stuart. You are probably right. But may be there can be a modified defn-auto-coerce .. Thats just a thought .. May be I will try to implement it . .but would love to hear any pointers you may have in that direction before I go it myself.. I am still an ametuer when it comes to Clojure .. so I want it to be a learning exercise too... Thanks again, Sunil. On Tue, Nov 30, 2010 at 6:14 AM, Stuart Sierra wrote: > Hi Sunil, > > This is one of those things that seems really useful for development, > but ends up being a lot of trouble down the road. For one thing, it's > hard to make it perform well. For another, it can lead to unexpected > results when you add in inheritance hierarchies and overloaded > methods. > > -S > > > On Nov 29, 3:20 am, Sunil S Nandihalli > wrote: > > Hello everybody, > > I was just wondering if we could have functions automatically call a > > multimethod whose dispatch-value would be a vector typename of the > current > > argument and required argument type. and accept the return value of that > > function as the argument in place of the current argument. I know that > the > > typenames are just hints ..but was wondering if we can make this happen > .. I > > think that would be really usefull.. Just a thought. > > Thanks > > Sunil. > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Wolfram: 100 years since Principia Mathematica
On Sat, Nov 27, 2010 at 9:36 PM, Duane Searsmith wrote: > That doesn't make Wolfram a lunatic or a fraud. Remember that > mathematicians like Mandelbrot where also considered frauds at first. mandelbrot came and talked at the place i was working ~5 year ago, during a book tour of his re fractals & the stock market iirc. he had (rip, no offense, i'm just being honest) one of the most horrible presentation styles i've ever encountered. it was as if he were actually born and raised in connecticut and had a very plan and proper american accent but decided his stock market book was too transparently fake (i don't know, i'm just being hyperbolic) and so announced, "i know! i will fake an *impenetrable accent*!" to prevent people from noticing he wasn't making any sense. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
will calling set on an existing set shortcircuit the call and return the same set or would it create a new one?
Hello everybody,
I have a small doubt. Suppose
(def s #{1 2 3 4 5 6})
(set s)
will calling set on an existing set shortcircuit the call and return the
same set or would it create a new one? I would like to extend the question
to hash-map and vec..
thanks,
Sunil.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: why not change > < type compare functions do a compare on strings as well?
2. I agree with having both. 3. Lol. I love that you asked your wife and kids that's where I always go. However, I don't think they represent a reasonable audience. When I say the general masses for intuition, I'm speaking about the average programmer whom reasonably would want to compare things that programmers typically compare: ie. to handle stepping through alphabetical names dynamically, or date-strings checks. It's not like you couldn't do a google search on how to compare datestrings in Java or Clojure and not find a bunch of Question/Answers addressing such. Just my 2 cents. The notion or > < being used to handle string comparisons is not foreign to programming languages, using them for the examples you provided are. On Nov 29, 7:40 pm, Stuart Halloway wrote: > Reasonable people can certainly disagree here, but to elaborate on my earlier > reply: > > 1. If you provide only a primitive feature, and users want a compound, they > can always create it for themselves. On the other hand, if you provide only a > compound, and the user wants the primitive, then they are screwed. So if you > are doing only one, the answer, IMO, is clear. > > 2. That said, one could have both, e.g. math/> and polymorphic/>. Whether > this is a good idea might be explored through community experience. > Namespaces let you have both and use whichever one you prefer unadorned, and > contrib provides a place to give it a try. > > 3. The appeal to intuition is perilous. I just explained the notion of a > string of characters to my wife and daughter (who are not programmers) and > asked them if they thought > or < was meaningful for strings. They answered > "Of course!" and followed with some examples: > > ;; anybody knows this! > (< "seven" "eight") > > ;; specificity > (< "green" "mint") > > ;; excellence > (< "poor" "good" "great") > > ;; descriptive uniqueness > (< "hattie" "the quick brown fox") > > One of the first things they said was "Of course < and > of strings is only > meaningful in context." > > Stu > > > huh? Making a change to the > function doesn't mean you *can't* write > > high performance data structures in Clojure. It just means, you *may* > > need to use a different fn name as opposed to the common one. > > Similarly I could simply use a different name to accomplish my own > > function that includes strings, but that's not the point. > > > The point is that the common name should benefit the common user (not > > typically the folks who appear in this group, but still representing > > 90+ percent of usage). Many people would benefit by having a cleaner > > easy-to-use intuitive language. i.e '=' works on strings, so why not > > '>' ? It's not like I don't get the benefits listed, but I think this > > group should also consider audiences outside the arena of expert > > language programmers (who are capable of making functions to suit > > their needs). IMHO. > > > On Nov 29, 1:23 pm, David Nolen wrote: > >> On Mon, Nov 29, 2010 at 2:28 PM, Tim Robinson > >> wrote: > > >>> I dunno, > > >>> Where is this arbitrary point people set where language improvements/ > >>> ease-of-use become less important than negligible performance impacts? > >>> I ran several benchmarks, with warm up and correct time measurements, > >>> and didn't get the impression the change was in anyway significant. > > >> Perhaps not significant to you. But to others it means that they can write > >> high performance data structures in Clojure itself that other people can > >> benefit from. To me that's far more compelling than convenient string > >> comparison operators. Consider the implementation of > >> gvec.clj:https://github.com/clojure/clojure/blob/master/src/clj/clojure/gvec.clj. > >> I > >> wonder what "negligible performance impact" you change would have on that? > > >> It might more sense to put what you're suggesting in clojure.string. > > >> David > > > -- > > You received this message because you are subscribed to the Google > > Groups "Clojure" group. > > To post to this group, send email to clojure@googlegroups.com > > Note that posts from new members are moderated - please be patient with > > your first post. > > To unsubscribe from this group, send email to > > clojure+unsubscr...@googlegroups.com > > For more options, visit this group at > >http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: sort-by reverse order?
I had some fun with this and added assert-args: (defmacro assert-args [fnname pred msg & pred-msg-pairs] `(when-not ~pred (throw (IllegalArgumentException. ~(str fnname " requires " msg (when (seq pred-msg-pairs) (list* `assert-args fnname pred-msg-pairs))) (def ascending compare) (def descending #(compare %2 %1)) (defn compare-by [& key-cmp-pairs] (assert-args compare-by (even? (count key-cmp-pairs)) "even number of args (keyword, comparator)" (every? #(or (keyword? %) (fn? %)) key-cmp-pairs) "all args to be keywords or functions") (fn [x y] (loop [[k cmp & more] key-cmp-pairs] (let [result (cmp (k x) (k y))] (if (and (zero? result) more) (recur more) result) -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
when to use io! macro?
Hi guys, I've recently discovered the io! macro. Is this something to try to use all the time.. or only in certain situations? Alex -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: why not change > < type compare functions do a compare on strings as well?
I certainly from time to time have to rewrite some comparator for strings for GUI stuff (sort by label, etc.). Even there, sometimes I need to sort without caring about capital letters, sometimes I don't need ... But indeed having some ready to use string comparators in a str package could be interesting. 2010/11/30 Tim Robinson > 2. I agree with having both. > > 3. Lol. I love that you asked your wife and kids that's where I > always go. > > However, I don't think they represent a reasonable audience. When I > say the general masses for intuition, I'm speaking about the average > programmer whom reasonably would want to compare things that > programmers typically compare: ie. to handle stepping through > alphabetical names dynamically, or date-strings checks. It's not like > you couldn't do a google search on how to compare datestrings in Java > or Clojure and not find a bunch of Question/Answers addressing such. > > Just my 2 cents. > > The notion or > < being used to handle string comparisons is not > foreign to programming languages, using them for the examples you > provided are. > > > > On Nov 29, 7:40 pm, Stuart Halloway wrote: > > Reasonable people can certainly disagree here, but to elaborate on my > earlier reply: > > > > 1. If you provide only a primitive feature, and users want a compound, > they can always create it for themselves. On the other hand, if you provide > only a compound, and the user wants the primitive, then they are screwed. So > if you are doing only one, the answer, IMO, is clear. > > > > 2. That said, one could have both, e.g. math/> and polymorphic/>. Whether > this is a good idea might be explored through community experience. > Namespaces let you have both and use whichever one you prefer unadorned, and > contrib provides a place to give it a try. > > > > 3. The appeal to intuition is perilous. I just explained the notion of a > string of characters to my wife and daughter (who are not programmers) and > asked them if they thought > or < was meaningful for strings. They answered > "Of course!" and followed with some examples: > > > > ;; anybody knows this! > > (< "seven" "eight") > > > > ;; specificity > > (< "green" "mint") > > > > ;; excellence > > (< "poor" "good" "great") > > > > ;; descriptive uniqueness > > (< "hattie" "the quick brown fox") > > > > One of the first things they said was "Of course < and > of strings is > only meaningful in context." > > > > Stu > > > > > huh? Making a change to the > function doesn't mean you *can't* write > > > high performance data structures in Clojure. It just means, you *may* > > > need to use a different fn name as opposed to the common one. > > > Similarly I could simply use a different name to accomplish my own > > > function that includes strings, but that's not the point. > > > > > The point is that the common name should benefit the common user (not > > > typically the folks who appear in this group, but still representing > > > 90+ percent of usage). Many people would benefit by having a cleaner > > > easy-to-use intuitive language. i.e '=' works on strings, so why not > > > '>' ? It's not like I don't get the benefits listed, but I think this > > > group should also consider audiences outside the arena of expert > > > language programmers (who are capable of making functions to suit > > > their needs). IMHO. > > > > > On Nov 29, 1:23 pm, David Nolen wrote: > > >> On Mon, Nov 29, 2010 at 2:28 PM, Tim Robinson < > tim.blacks...@gmail.com>wrote: > > > > >>> I dunno, > > > > >>> Where is this arbitrary point people set where language improvements/ > > >>> ease-of-use become less important than negligible performance > impacts? > > >>> I ran several benchmarks, with warm up and correct time measurements, > > >>> and didn't get the impression the change was in anyway significant. > > > > >> Perhaps not significant to you. But to others it means that they can > write > > >> high performance data structures in Clojure itself that other people > can > > >> benefit from. To me that's far more compelling than convenient string > > >> comparison operators. Consider the implementation of gvec.clj: > https://github.com/clojure/clojure/blob/master/src/clj/clojure/gvec.clj. I > > >> wonder what "negligible performance impact" you change would have on > that? > > > > >> It might more sense to put what you're suggesting in clojure.string. > > > > >> David > > > > > -- > > > You received this message because you are subscribed to the Google > > > Groups "Clojure" group. > > > To post to this group, send email to clojure@googlegroups.com > > > Note that posts from new members are moderated - please be patient with > your first post. > > > To unsubscribe from this group, send email to > > > clojure+unsubscr...@googlegroups.com > > > For more options, visit this group at > > >http://groups.google.com/group/clojure?hl=en > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To
