Hi,
Am Mittwoch, 3. Juli 2013 16:49:43 UTC+2 schrieb Dragan Djuric:
>
> Monads as a Haskell construct is what the previously mentioned laws
> describe. Monads in category theory are defined in a category X as a triple
> (T, n, m) where T is a functor and m and n certan natural transformations
>
Hi Stefan,
On Feb 27, 3:23 pm, Stefan Kamphausen wrote:
> Hi,
>
> extracting forms from the REPL session into some test-magic definitely is
> useful. However, my sessions seem to be structured in a different way and
> only having access to the previous three inputs doesn't seem viable to me.
> I
Hi everyone,
just finished a small hack for swank-clojure (see my fork on github:
github.com/bertschi/swank-clojure)
The repl thread now has access to the last three input forms that were
typed into the repl. These forms are accessible as **1, **2 and **3
respectively. The Common Lisp names +, ++
Hi everyone,
I just did a small hack for swank-clojure which has the repl thread
hold the last three input forms in variables **1, **2 and **3
respectively.
Based on this, I added a slime function slime-extract-test which does
the following:
user> (range 7)
(0 1 2 3 4 5 6)
user> (range 3)
Hi,
to implement letrec in a language with eager evaluation strategy some
kind of mutability is probably needed. Consider for example a self-
referential definition such as
(let [fibo (lazy-cat [1 1] (map + fibo (rest fibo)))]
(take 10 fibo))
This will not work since fibo is not in scope when
Hi Andrew,
the approach suggested by Tassilo looks correct.
Macros are evaluated at compile-time, so you need a termination
condition that can be decided without actually running your form. In
you're case you want run-time delayed evaluation, which is easily
achieved by wrapping the expression int
Hi Benny,
On Dec 3, 9:21 pm, Benny Tsai wrote:
> Hi Nils,
>
> A while back, I also took a stab* at implementing Erlang-style actors in
> Clojure, along with solutions for a few classic concurrency problems
> (Dining Philosophers, Sleeping Barber). I was blown away by how easy it
> was to impleme
On Dec 2, 8:13 pm, "john.holland" wrote:
> Thanks for all the replies. It seems to me that as general solutions to
> stack overflow, trampoline and recur are
> very valuable. I had gotten the mistaken idea that Scheme was somehow
> immune to the problem.
> My experiments in Scheme seemed to ge
Hi Stuart,
thanks for the info. I did not really think about some of these
differences. Basically, it was just a fun exercise ... not (yet)
useful for anything serious.
On Dec 2, 10:14 pm, Stuart Sierra wrote:
> > how do Clojure agents relate to Erlang actors?
>
> There are several important dif
Hi,
how do Clojure agents relate to Erlang actors?
To gain some insights, I tried to implement Erlang style message
passing between agents. The first version is just a very incomplete
sketch (no mailbox, case instead of pattern matching ...), but already
shows that it is quite easily doable:
https
Hi,
the Scheme version of quicksort is not tail-recursive since append is
called on the return value of the recursive calls. Thus, also in
Scheme this eats up your stack. That your Scheme code can sort larger
sequences simple means that your Scheme implementation has a larger
stack than the JVM wi
Hi Roman,
as far as I understand, the Clojure compiler is doing some
optimizations for recursive functions to save the variable lookup.
This means that you have to explicitly write the recursive call as
(#'fact (dec n)) if you want to dynamically rebind the function.
Somehow this doesn't feel righ
ee to not use butlast any more ...
On Nov 24, 11:04 am, Daniel Janus wrote:
> On Wednesday, November 23, 2011 10:42:13 PM UTC, Nils Bertschinger wrote:
> > It solves a
> > common problem, namely to drop the last element of a sequence and
> > reads better in this case than the e
Hi,
you're right that drop-last is more general than butlast. So why does
butlast exist at all?
I would say, that it is there for a very good reasons. It solves a
common problem, namely to drop the last element of a sequence and
reads better in this case than the equivalent idiom using drop-last.
Clojure is a Lisp, so it should be possible to extend it yourself ...
What about something like this?
(defmacro locally-using
"Allows to use symbols from other namespace in the local scope
of the macro body.
Syntax: (locally-using [*] :from
)"
[symbols from ns-name & body]
(assert
Hi Julius,
good catch, I don't know how I missed that???
Just uploaded a fix ... should work now.
Nils
On Nov 20, 5:58 pm, Julius Seporaitis wrote:
> Hello guys,
>
> I would like to try out this library, but ran into a problem with Clojure
> 1.3, 'lein repl' throws an exception, when:
>
> *user
e I'm not an expert in this area, I don't know which kind
of models and probability distributions are useful to describe musical
structure. Let me know if you have an idea, I would be happy to help
putting it into clojure.
Best,
Nils
> -Jeff
> On Nov 18, 12:57 am, Nils Bertschin
On Nov 18, 8:05 am, Konrad Hinsen
wrote:
> --On 17 novembre 2011 15:09:11 -0800 Nils Bertschinger
>
> wrote:
> > The two approaches are somewhat complementary to each other. Your
> > monad does exact inference on discrete distributions by running
> > through all poss
Hi Konrad,
thanks for the link. I know your very nice library and actually use
clojure.contrib.monads to implement my probability monad.
The two approaches are somewhat complementary to each other. Your
monad does exact inference on discrete distributions by running
through all possibilities. Mine
Hi everyone,
inspired by the bher compiler for the probabilistic scheme dialect MIT
Church, I have implemented a version of the probability monad which
uses Metropolis Hastings to draw samples from runs of monadic
programs. You can find the code on github:
https://github.com/bertschi/ProbClojureN
On Sep 3, 2:35 am, Brian Goslinga wrote:
> The future is probably executing in a different thread, so the dynamic
> binding of *ns* probably isn't the user namespace.
Thanks Brian. That's exactly what happens:
user> (future *ns*)
#
user> (deref *1)
#
Thus, I have to either re-bind *ns* or use o
Hi everyone,
it appears that eval works differently when used inside a future. The
following example REPL session shows what I mean:
user> (clojure-version)
"1.2.0-master-SNAPSHOT"
user> (defn my-inc [x] (+ x 1))
#'user/my-inc
user> (eval '(my-inc 1))
2
user> (future (eval '(my-inc 1)))
#
user> (
22 matches
Mail list logo
