Scott Michel <scottm <at> rushg.aero.org> writes:> Out of curiousity, for which CL implementation is this targeted? sbcl? > Or something you're rolling?I wanted to roll out my own lisp, and maybe use some library code from existing lisps (think of loop or format). Adding an LLVM backend to an existing lisp implementation is a nice idea, but currently not planned.> > The reason why I ask is that I expressed an outrageous opinion at > Supercomputing back in November, to wit, that CL is probably the best > language suited for today's multicore problems... but I don't have the > time to hack one of the current implementations to proove the point.interesting, what makes lisp superior in this area over languages with explicit support for parallell computing (like erlang? or Ada) or languages which may be easier auto parallelized (like haskell because of its functional nature).> Although, you'll notice that LLVM amply prooves "Greenbaum's hypothesis" > (IIRC): inside every sufficiently complex program there is an > implmentation of a Lisp interpreter.Nice statement :)
On Tuesday 05 February 2008 12:40:20 thomas weidner wrote:> I wanted to roll out my own lisp, and maybe use some library code from > existing lisps (think of loop or format). Adding an LLVM backend to an > existing lisp implementation is a nice idea, but currently not planned.I am also interested in implementing functional programming languages using LLVM. Although I'm only interested in statically typed ones, there is a lot of work that can be shared. LLVM currently lacks working examples demonstrating the use of garbage collection and exceptions, so that would be a good first port of call. Then we can worry about an intermediate representation that supports closures. If you are familiar with functional programming and, in particular, its benefits in the context of compiler work then you might like to use Gordon's OCaml bindings to LLVM that are bundled with LLVM. They are very easy to use and will make subsequent work vastly easier than trying to write everything in C++. -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/products/?e
Jon Harrop wrote:> If you are familiar with functional programming and, in particular, its > benefits in the context of compiler work then you might like to use Gordon's > OCaml bindings to LLVM that are bundled with LLVM. They are very easy to use > and will make subsequent work vastly easier than trying to write everything > in C++.Or, indeed, the Haskell bindings I've been working on with Lennart Augustsson. They're both safer and easier to use than the OCaml bindings :-) <b
> LLVM currently lacks working examples demonstrating the use of garbage > collection...Hello, if anybody has time, I would recommend putting a big disclaimer at the top of the garbage collection page that explains that, for the most part, garbage collection falls outside of LLVM's domain. Right now LLVM advertises itself as "supporting garbage collecting", which although true, somewhat misses the point. LLVM just happens to not get in the way. The only real garbage collection feature that LLVM provides is accurate stack walking, and even that can be implemented separately through a shadow stack. That the documentation contains llvm.gc intrinsics is a bit of a red herring. You end up doing most of the work yourself. To illustrate, for our own LLVM work we implemented garbage collecting completely without using any LLVM primitives. Granted, we're a conservative collector right now, and once we go accurate we'll investigate the stack-walking. Just a head's up from an beginner/intermediate LLVM programmer. The current state of the GC documentation makes it seem as if: "you just connect the GC and it works". I'm sure that isn't the intention, but judging from some of the posts on this mailing lists over the past months, this seems to be a common expectation. Two cents... Jaap Suter
thomas weidner wrote:>>The reason why I ask is that I expressed an outrageous opinion at >>Supercomputing back in November, to wit, that CL is probably the best >>language suited for today's multicore problems... but I don't have the >>time to hack one of the current implementations to proove the point. > > > interesting, what makes lisp superior in this area over languages with explicit > support for parallell computing (like erlang? or Ada) or languages which may be > easier auto parallelized (like haskell because of its functional nature).Lisp macros make it much easier to "rewrite" the program to both analyze the code and take advantage of certain features. Few, if any, other languages have this feature or plan to implement it. For example, assume that the loop macro could be extended in such a way that one could analyze dependencies within the loop -- if there are no dependencies, you get automagic parallelized code. Similarly, the macro could be extended in such a way as to eliminate the dependencies, again, automagic parallelization. -scooter
thomas weidner wrote:> interesting, what makes lisp superior in this area over languages with explicit > support for parallell computing (like erlang? or Ada) or languages which may be > easier auto parallelized (like haskell because of its functional nature).I almost forgot: there was a huge body of work from the 80's on high performance and parallel Lisps. Lisp was the preferred system programming language for the Connection Machine (CM Lisp.) -scooter
Scott Michel wrote:> thomas weidner wrote: > >>>The reason why I ask is that I expressed an outrageous opinion at >>>Supercomputing back in November, to wit, that CL is probably the best >>>language suited for today's multicore problems... but I don't have the >>>time to hack one of the current implementations to proove the point. >> >> >>interesting, what makes lisp superior in this area over languages with explicit >>support for parallell computing (like erlang? or Ada) or languages which may be >>easier auto parallelized (like haskell because of its functional nature). > > > Lisp macros make it much easier to "rewrite" the program to both analyze > the code and take advantage of certain features. Few, if any, other > languages have this feature or plan to implement it.I realize there might be Lisp macro-like packages for other languages, such as OCaml. Dylan, for all intents and purposes, is A Dead Parrot (as much as it pains me to say so [*]), but was a good example of how to take an Algol-like syntax and incorporate Lisp-like macros in the d-expression paper. For other languages that feature 'eval', such as Python, the AST is relatively complex enough that macros may not ever be viable, i.e., that one could easily perform 'macroexpand-1' before 'eval'. But this is my own personal opinion. Pile on and disgree! -scooter