Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Creating a Non-Trivial Lisp Game in 2018

defungames.com

Post reply on HN
Print view View original

11–20 of 28 posts

Re: Creating a Non-Trivial Lisp Game in 2018

#11

Post by gameswithgo »

mthom wrote: post #8
drmeister wrote: post #6

My group is developing Clasp (github.com/clasp-developers/clasp.git). It's a Common Lisp implementation that interoperates with C++ and uses llvm as the backend. It's something you might want to look at because it could change your options in the following ways: (1) Clasp interoperates with C++ - C++ libraries like graphics and physics engines can be easily exposed within Clasp Common Lisp. (See https://github.com/cl…

Wonderful and inspiring work! I wonder if it would be possible to create a similar interop story with the Rust programming language, which also targets LLVM -- ideally without having to redo all the hard work that went into Clasp. I have a Prolog interpreter/compiler I'm developing in Rust right now. One of my aims (eventually) is to compile Prolog to fast native code with it. It would be nice to have convenient acce…

Rust can already talk C ABI so I think the dream is already reality.

Re: Creating a Non-Trivial Lisp Game in 2018

#12

Post by gameswithgo »

drmeister wrote: post #6

My group is developing Clasp (github.com/clasp-developers/clasp.git). It's a Common Lisp implementation that interoperates with C++ and uses llvm as the backend. It's something you might want to look at because it could change your options in the following ways: (1) Clasp interoperates with C++ - C++ libraries like graphics and physics engines can be easily exposed within Clasp Common Lisp. (See https://github.com/cl…

Does clasp still support all the metaprogramming features of lisp while using llvm, and how does it do it?

Re: Creating a Non-Trivial Lisp Game in 2018

#13

Post by armitron »

gameswithgo wrote: post #12
drmeister wrote: post #6

My group is developing Clasp (github.com/clasp-developers/clasp.git). It's a Common Lisp implementation that interoperates with C++ and uses llvm as the backend. It's something you might want to look at because it could change your options in the following ways: (1) Clasp interoperates with C++ - C++ libraries like graphics and physics engines can be easily exposed within Clasp Common Lisp. (See https://github.com/cl…

Does clasp still support all the metaprogramming features of lisp while using llvm, and how does it do it?

Given that clasp is a Common Lisp - that passes 97%+ of CL ANSI tests on par with other CL implementations like SBCL - then answer is obviously yes.

You need to go into more detail about why you think llvm would make a difference. Common Lisp is usually compiled to native code and the compiler is - unlike most other languages that compile to native code - exposed and available at runtime. When you program interactively in a natively-compiled Common Lisp implementation like clasp or SBCL or ClozureCL, your code is compiled to native code on the spot. You can even customize the code generation via compiler macros. LLVM is just another compiler backend that can slot in so in that regard, conceptually it's seamless.

Re: Creating a Non-Trivial Lisp Game in 2018

#14

Post by armitron »

gameswithgo wrote: post #11
mthom wrote: post #8

Earlier quoted context omitted.

Wonderful and inspiring work! I wonder if it would be possible to create a similar interop story with the Rust programming language, which also targets LLVM -- ideally without having to redo all the hard work that went into Clasp. I have a Prolog interpreter/compiler I'm developing in Rust right now. One of my aims (eventually) is to compile Prolog to fast native code with it. It would be nice to have convenient acce…

Rust can already talk C ABI so I think the dream is already reality.

Rust does not have native C++ interop.

C ABI is different to what clasp has done (native C++ interop). All widely used Common Lisp implementations have seamless C ABI interop through their FFIs / CFFI [1].

Clasp goes above and beyond that and natively interfaces with C++. LTO works with mixed Common Lisp and C++ code. Exception handling works as expected. You can mix Common Lisp and C++ stack frames. Correct me if I'm wrong but Rust does not have anything equivalent. The language that comes closest is D I think [2].

[1] https://common-lisp.net/project/cffi/

[2] https://www.youtube.com/watch?v=IkwaV6k6BmM

Re: Creating a Non-Trivial Lisp Game in 2018

#15

Post by man213 »

armitron wrote: post #14
gameswithgo wrote: post #11

Earlier quoted context omitted.

Rust can already talk C ABI so I think the dream is already reality.

Rust does not have native C++ interop. C ABI is different to what clasp has done (native C++ interop). All widely used Common Lisp implementations have seamless C ABI interop through their FFIs / CFFI [1]. Clasp goes above and beyond that and natively interfaces with C++. LTO works with mixed Common Lisp and C++ code. Exception handling works as expected. You can mix Common Lisp and C++ stack frames. Correct me if I'…

Rust can inline cpp code via rust-cpp crate. I've been playing with it several months ago and successfully used dear-imgui and other stuff in some of my rust tech.

Re: Creating a Non-Trivial Lisp Game in 2018

#16

Post by armitron »

westoncb wrote: post #10

The article talks about one of the primary motivations for using Lisp being that it's 'fun,' which is a comment I've heard about Lisp elsewhere, and which makes sense to me since I've noted a difference in funness between other languages. So that's pretty appealing to me, but I haven't quite found the right Lisp to use. It seems like Clojure (probably ClojureScript actually) would be the most practical for me to use…

Clojure is practically tied to the JVM and the Java ecosystem (ClojureScript is different enough to count as a different language so I'll focus on Clojure).

To me that's not fun. It's also limited by design to fit the development model Rich Hickey wanted for his consultancy. It is nowhere near as encompassing or paradigm agnostic as Common Lisp. Moreover, you can take old Lisp code that's 40+ years old and run it today on top of Common Lisp with no/minor changes. Clojure breaks compatibility with Lisp code in many different ways. For me these reasons are enough not to consider Clojure a Lisp.

Re: Creating a Non-Trivial Lisp Game in 2018

#17

Post by slifin »

westoncb wrote: post #10

The article talks about one of the primary motivations for using Lisp being that it's 'fun,' which is a comment I've heard about Lisp elsewhere, and which makes sense to me since I've noted a difference in funness between other languages. So that's pretty appealing to me, but I haven't quite found the right Lisp to use. It seems like Clojure (probably ClojureScript actually) would be the most practical for me to use…

I find it fun, repl driven development, immutability, functions and maps as first class, practical in many situations

Also Datomic hyperfiddle and specs

Re: Creating a Non-Trivial Lisp Game in 2018

#18

Post by nsajko »

pmarreck wrote: post #7

"Abuse" by Crack.com way back in 1995 was powered by Lisp, as I recall (and also moddable via it): https://www.mobygames.com/game/dos/abuse https://everything2.com/title/abuse

The source, maintained by Sam Hocevar: http://abuse.zoy.org/browser/abuse/trunk

Re: Creating a Non-Trivial Lisp Game in 2018

#19

Post by _emacsomancer_ »

armitron wrote: post #16
westoncb wrote: post #10

The article talks about one of the primary motivations for using Lisp being that it's 'fun,' which is a comment I've heard about Lisp elsewhere, and which makes sense to me since I've noted a difference in funness between other languages. So that's pretty appealing to me, but I haven't quite found the right Lisp to use. It seems like Clojure (probably ClojureScript actually) would be the most practical for me to use…

Clojure is practically tied to the JVM and the Java ecosystem (ClojureScript is different enough to count as a different language so I'll focus on Clojure). To me that's not fun. It's also limited by design to fit the development model Rich Hickey wanted for his consultancy. It is nowhere near as encompassing or paradigm agnostic as Common Lisp. Moreover, you can take old Lisp code that's 40+ years old and run it tod…

Still, in cases where one is tied to the Java ecosystem for whatever reason, surely Clojure is better than no-clojure?

Re: Creating a Non-Trivial Lisp Game in 2018

#20

Post by dustingetz »

armitron wrote: post #16
westoncb wrote: post #10

The article talks about one of the primary motivations for using Lisp being that it's 'fun,' which is a comment I've heard about Lisp elsewhere, and which makes sense to me since I've noted a difference in funness between other languages. So that's pretty appealing to me, but I haven't quite found the right Lisp to use. It seems like Clojure (probably ClojureScript actually) would be the most practical for me to use…

Clojure is practically tied to the JVM and the Java ecosystem (ClojureScript is different enough to count as a different language so I'll focus on Clojure). To me that's not fun. It's also limited by design to fit the development model Rich Hickey wanted for his consultancy. It is nowhere near as encompassing or paradigm agnostic as Common Lisp. Moreover, you can take old Lisp code that's 40+ years old and run it tod…

if by limited we mean full ecosystem compatibility with jvm and javascript, then yes, Clojure is limited. Which 40 year old CL codebase is it that i am trying to run?
Post reply on HN