On Tue, Dec 21, 2010 at 4:01 PM, Andrew Boekhoff wrote:
>
> (defn [f k x]
> (if (time-to-return? x)
>(k x)
>(g (fn [x*] (k (do-stuff-to x*)))
> x)))
>
> (defn [g k x]
> (if (time-to-return? x)
>(k x)
>(f (fn [x*] (k (do-other-stuff-to x*)))
> x)))
No, great example!
> > Lazy-seq's are often handy in Clojure to subvert the stack limit imposed
> > by the the JVM, but it's not quite the same problem that TCO solves.
>
> Having recently converted some Scheme that leaned heavily on the presence
> of TCO, I'm curious as to what situations you think could not be sol
On Tue, Dec 21, 2010 at 12:08 PM, Andrew Boekhoff wrote:
> > With TCO mutually recursive functions do not consume the stack. The same
> is
> > true for well constructed lazy sequences.
>
> If the functions were:
> (defn f [x] (g x))
> (defn g [x] (f x))
>
> They would operate in constant space wit
On Tue, Dec 21, 2010 at 12:44 PM, nicolas.o...@gmail.com <
nicolas.o...@gmail.com> wrote:
> It's a funy and original trick but on this example at least,
> it seems slower (and it can use a lot of memory, because it retains a
> stack in the heap) than trampoline:
>
> (time (get-value (even 1500
It's a funy and original trick but on this example at least,
it seems slower (and it can use a lot of memory, because it retains a
stack in the heap) than trampoline:
(time (get-value (even 1500)))
"Elapsed time: 1899.881769 msecs"
And a version with trampoline
(defn odd [^long x]
(i
On Tue, Dec 21, 2010 at 12:20 PM, nicolas.o...@gmail.com <
nicolas.o...@gmail.com> wrote:
> I have an example to clarify what I understood of your idea:
>
> (declare odd)
>
> (defn even [x]
>(if (zero? x)
> [true]
> (lazy-seq nil (odd (dec x)
>
> (defn odd [ x]
>
I have an example to clarify what I understood of your idea:
(declare odd)
(defn even [x]
(if (zero? x)
[true]
(lazy-seq nil (odd (dec x)
(defn odd [ x]
(if (zero? x)
[false]
(lazy-seq nil (even (dec x)
(defn get-value [l]
On Tue, Dec 21, 2010 at 12:09 PM, nicolas.o...@gmail.com <
nicolas.o...@gmail.com> wrote:
> > Yes I know, I thought the way I wrote the code was clear about that :)
>
> I am sorry, I did not understand.
>
> So let me try to explicit your transformation (please correct me if I am
> wrong):
> - star
> Yes I know, I thought the way I wrote the code was clear about that :)
I am sorry, I did not understand.
So let me try to explicit your transformation (please correct me if I am wrong):
- start with some mutually recursive functions: a and b, for example
- create a "lazy stack" for the recursiv
> With TCO mutually recursive functions do not consume the stack. The same is
> true for well constructed lazy sequences.
If the functions were:
(defn f [x] (g x))
(defn g [x] (f x))
They would operate in constant space with tail-call optimization.
(defn f [x] (cons x (g x)))
(defn g [x] (cons
On Tue, Dec 21, 2010 at 11:54 AM, nicolas.o...@gmail.com <
nicolas.o...@gmail.com> wrote:
> > With TCO mutually recursive functions do not consume the stack. The same
> is
> > true for well constructed lazy sequences.
> > David
>
> With TCO, mutually *tail* recursive functions do not consume the s
> With TCO mutually recursive functions do not consume the stack. The same is
> true for well constructed lazy sequences.
> David
With TCO, mutually *tail* recursive functions do not consume the stack.
non-tail call always consume the stack in non CPS compiled languages.
(In which, it consumes th
On Tue, Dec 21, 2010 at 11:41 AM, nicolas.o...@gmail.com <
nicolas.o...@gmail.com> wrote:
> > Those are mutual recursive functions. Trying to define them as regular
> > functions will quickly result in a stack overflow.
> > You could use trampoline but in my experience you will take a significant
> Those are mutual recursive functions. Trying to define them as regular
> functions will quickly result in a stack overflow.
> You could use trampoline but in my experience you will take a significant
> performance hit.
> Lazy sequences are a way to efficiently represent mutually recursive
> compu
On Tue, Dec 21, 2010 at 11:28 AM, nicolas.o...@gmail.com <
nicolas.o...@gmail.com> wrote:
> I am not sure I get you. COuld you elaborate a bit more this example,
> please?
> Which tail-call functions are you trying to replace by a and b?
> Nicolas.
>
Those are mutual recursive functions. Trying t
> In my experience lazy-seqs are a reasonable replacement for the lack of TCO,
> and from what I've heard that is one of the reasons they exist.
> (defn a [x]
> (lazy-seq
> (cons x (b (inc x)
> (defn b [x]
> (lazy-seq
> (cons x (a (inc x)
> David
>
I am not sure I get you. C
On Tue, Dec 21, 2010 at 9:12 AM, nicolas.o...@gmail.com <
nicolas.o...@gmail.com> wrote:
> (defn my-map [f l]
> (when l
>(cons (f (first l)) (my-map f (next l)))
>
> You can write a tail recursive version, but it would be equivalent to
> accumulating with a loop and reversing the result.
> Wh
On Tuesday, December 21, 2010 2:55:58 PM UTC+1, Santosh Rajan wrote:
>
> On Tue, Dec 21, 2010 at 3:26 PM, Alessio Stalla
> wrote:
>
> >
> > It could be written on top of Common Lisp. There are natively compiled,
> > multithreaded, cross-platform implementations of it, and building on
> another
>
>
> I am not a Clojure expert. But if I understood Clojure correctly,
> Clojure would not be Clojure if it where natively compiled. Eg. The
> whole lazy seq's are required because of lack of tail call
> optimization in the JVM. Or am I wrong?
>
>
I don't think the lazy seq are necessary because of
On Tue, Dec 21, 2010 at 3:26 PM, Alessio Stalla wrote:
>
> It could be written on top of Common Lisp. There are natively compiled,
> multithreaded, cross-platform implementations of it, and building on another
> Lisp should be much easier than on C/C++. Of course, since Clojure programs
> often r
On Monday, December 20, 2010 8:54:14 PM UTC+1, kaveh_shahbazian wrote:
>
> I understand hosting on a VM has it's own (huge) advantages: GC,
> libraries, proved practices and vast amount of research and community
> effort already available; no doubt on that part.
>
> It is just having a mature an
If you want native with enough reflection to compile clojure,
Objective-C might be a better choice than C++.
--
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
On 20 Dec 2010, at 21:43, Michael Glaesemann wrote:
For me, a native-code implementation of Clojure would be of
interest for interfacing with libraries written in C, C++, and
Fortran. The same goal could probably be achieved otherwise
(compiling Java bytecode to native code, or simply a JVM
Hi Konrad,
Have you tried giws (spelt opposite of swig) .. it automatically generates
all the necessary jni stuff necessary for any java-class .. It takes an xml
file as input and generates any necessary jni-wrappers .. It can only acess
the class member-functions not member-values. I have tried
On Dec 20, 2010, at 15:23, Konrad Hinsen wrote:
> On 20 Dec 2010, at 18:19, Ken Wesson wrote:
>
>> Is it really necessary, though? Hotspot's JIT yields up
>> native-ballpark speeds when you really need them, if you optimize your
>> code appropriately.
>
> For me, a native-code implementation of
On 20 Dec 2010, at 21:28, Timothy Baldridge wrote:
Have fun with that. For C it would be easy-ish to create a pinvoke
like system. But for C++.yehhh.the way C++ is linked is
just wrong. Sometimes linkers can't even link between two different
C would be fine. I wouldn't mind writing
>
>> Is it really necessary, though? Hotspot's JIT yields up
>> native-ballpark speeds when you really need them, if you optimize your
>> code appropriately.
>
> For me, a native-code implementation of Clojure would be of interest for
> interfacing with libraries written in C, C++, and Fortran. The
On 20 Dec 2010, at 18:19, Ken Wesson wrote:
Is it really necessary, though? Hotspot's JIT yields up
native-ballpark speeds when you really need them, if you optimize your
code appropriately.
For me, a native-code implementation of Clojure would be of interest
for interfacing with libraries w
I looked into this a while back. Unfortunetly, Clojure really is
designed to be run on a VM. It makes heavy use of the GC, reflection,
and OOP.
> Clojure is a fantastic language (Although I have just scratched the
> surface) and It would be "nice" to have it natively compiled.
Why would it be nic
I understand hosting on a VM has it's own (huge) advantages: GC,
libraries, proved practices and vast amount of research and community
effort already available; no doubt on that part.
It is just having a mature and well designed cross-platform natively
compiled language (other than C and C++) has
On Mon, 20 Dec 2010 12:19:59 -0500
Ken Wesson wrote:
> Has anyone tried compiling a Clojure project (along with Clojure
> itself) with gcj or jet?
I tried to compile Clojure 1.2 with GCJ. To avoid compilation errors I
had to replace some classes in GNU Classpath with versions from OpenJDK.
Still
On Mon, Dec 20, 2010 at 10:41 AM, nicolas.o...@gmail.com
wrote:
> If you wait for clojure in clojure and then use VMkit (LLVM based
> thing to do Virtual Machine), it can be an interesting project.
> I am not sure if it would be considered as really native, though.
Has anyone tried compiling a Cl
If you wait for clojure in clojure and then use VMkit (LLVM based
thing to do Virtual Machine), it can be an interesting project.
I am not sure if it would be considered as really native, though.
Nicolas.
--
You received this message because you are subscribed to the Google
Groups "Clojure" grou
It's theoretically possible, but not under active investigation at this
time.
-Stuart Sierra
clojure.com
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members a
Clojure is designed to be hosted. So I'm pretty sure that there are no
plan to write a nativ clojure VM but you could try to compile the byte
code with llvm. I here there is a java byte code frontend.
On Dec 20, 8:43 am, kaveh_shahbazian
wrote:
> Is there a natively compiled version of Clojure? I
35 matches
Mail list logo
