There are several buggy behaviors of the Enclojure REPL that are
annoying me. Enclojure has gone through several upgrades over the past
year or two without any of these being fixed, despite the fact that
people have reported these problems more than once on the Enclojure
Google Group during that ti
On 12 April 2011 22:04, Joost wrote:
> For now, I think of the pretzel library as the lowest useful level of
> abstraction for input tests. And for low level abstractions, I prefer
> to place a higher value on correctness, extensibility, consistency and
> possibly even performance (in roughly that
On Apr 12, 2011, at 10:29 AM, pba wrote:
> Is it possible to mock multimethods using clojure.contrib.mock ? I'm
> testing a controller implementation and want to verify a defmethod for
> "type A" calls another for "type B" where "type" is the dispatching
> key.
Thus far, I haven't seriously gra
I noticed I hadn't addressed this question earlier, so.
On Apr 9, 3:48 am, James Reeves wrote:
> The problem I have with such a scheme is that it seems more complex to
> use in practise. For instance, let's say I wanted an optional value.
> If predicates that fail a precondition return a truthy
On Apr 10, 7:48 pm, Paul Legato wrote:
> Hi,
>
> I'd like to suggest two enhancements to clojure-contrib.logging:
>
> 1) There should be an easy way to set the current log level threshold
> (DEBUG, WARN, etc.)
I'd like that too. Alas, the complexity of hierarchical logging
libraries, coupled w
On Apr 12, 6:35 pm, James Reeves wrote:
> On 12 April 2011 12:16, Joost wrote:
>
> > An input string of "foobar" is obviously not a number between 10 and
> > 20, so whatever predicate you use to test for that should just return
> > false. That not everybody here agrees on that indicates to me tha
Paul Graham's "On Lisp" has a nice little section on anaphoric macros.
It has a few nice tricks, but generally the Clojure style tends to
avoid them if possible. ie. using if-let instead of an anaphoric-if
macro.
Also, I think the book Rob was referring to is called "Let Over
Lambda" by Hoyte. As
On 12 April 2011 12:16, Joost wrote:
> An input string of "foobar" is obviously not a number between 10 and
> 20, so whatever predicate you use to test for that should just return
> false. That not everybody here agrees on that indicates to me that
> people are trying to shove too much functionali
Is it possible to mock multimethods using clojure.contrib.mock ? I'm
testing a controller implementation and want to verify a defmethod for
"type A" calls another for "type B" where "type" is the dispatching
key.
Thanks.
--
You received this message because you are subscribed to the Google
Group
Sometimes it is useful to have a referentially opaque symbol that you can
refer to when calling a macro. Clojure's design encourages the idiom of let
bindings instead of anaphora to maintain referential transparency, but in
some cases it is preferable to capture a symbol and make use of it. If yo
On Tuesday, April 12, 2011 9:25:25 AM UTC-4, rob wrote:
>
> One Scheme advocate I know has that suggested that it would be more
> hygienic to have gensyms be the rule instead of the exception to the rule
> (you could still get capture by asking to *not* gensym). I'm not certain I
> agree with
Clojure's automatic gensym feature in defmacro is similar to the idea
suggested in Hoyte's Common Lisp book "Let Them Eat Lambda", though I gather
it's not historically originated by Hoyte as similar ideas have been
implemented by others. One Scheme advocate I know has that suggested that
it would
On Tue, Apr 12, 2011 at 8:05 AM, James Reeves wrote:
> On 12 April 2011 12:02, Ken Wesson wrote:
>> Don't be ridiculous. If you're putting that (chain ...) sexp of yours
>> in every separate place where a field is checked for being an integer
>> in a range, then that's duplication. And if you ext
On 12 April 2011 12:02, Ken Wesson wrote:
> Don't be ridiculous. If you're putting that (chain ...) sexp of yours
> in every separate place where a field is checked for being an integer
> in a range, then that's duplication. And if you extract it into a
> function that just takes the endpoints as
Hi,
On 12 Apr., 13:58, limux wrote:
> Yeah, I see, thanks for your very wonderful replies.
> Clojursql does not conflict with clojure.core throung refer-clojure
> with exclude to make its own distinct work well. In my myoa.core, I
> refer clojure.core and clojureql which lead to conflict, becaus
Yeah, I see, thanks for your very wonderful replies.
Clojursql does not conflict with clojure.core throung refer-clojure
with exclude to make its own distinct work well. In my myoa.core, I
refer clojure.core and clojureql which lead to conflict, because I
refer clojureql in a normal way instead of
All this stuff on complexity of validations is interesting, but my
take on most of this (and especially on the pretzel functions) is that
predicates should just test for validity, strictly if possible, and
nothing else, since there are too many ways of combining these tests
into more abstract funct
On Tue, Apr 12, 2011 at 6:34 AM, James Reeves wrote:
> On 12 April 2011 04:31, Ken Wesson wrote:
>> There's a difference between the program parsing the same *object*
>> multiple times, and the program's own source code containing
>> duplication!
>
> But there isn't any duplication
Don't be ridi
On 12 April 2011 04:31, Ken Wesson wrote:
> There's a difference between the program parsing the same *object*
> multiple times, and the program's own source code containing
> duplication!
But there isn't any duplication:
(defn present? [x]
(not (string/blank? x)))
(defn- parse-int [x]
(try
19 matches
Mail list logo
