Lisp Pimpin'

Started by
387 comments, last by Mercury 18 years, 7 months ago
Quote:Original post by Flatlander
I'm not a language lawyer but since

(defstruct foo
bar)

(defun get-foo ()
(list #.(make-foo :bar 'bar)))

(eq (car (get-foo)) (car (get-foo)))
=> T

in both CMUCL and Lispworks, it looks like the struct in this case really is a literal ("...referenced directly in a program rather than being computed by the program...") object.

Yes, you're quite right. The result of evaluating the #. form is #S(VEC :X 0 :Y 0 :Z 0) which is a literal by virtue of being self-evaluating.

I think the language of the standard is a little confusing when it talks about structures appearing in constants, when the problem is that the structure appears as a constant -- the backquote form has nothing do with it.

In CMUCL, I get an error when compiling the above code. I must first put the defstruct in an (eval-when (:compile-toplevel) ...), since otherwise MAKE-FOO isn't visible when it's used. Then there's the error about not being able to dump the constant.

I don't quite see why there couldn't be a default make-load-form: it's trivial to 'pickle' the vector so-created, its print form -- #S(VEC :X 0 :Y 0 :Z 0) -- can be read directly, and in general that's the case for all structs: the only exceptions are those structs which contain unreadable objects in their slots, such as a stream.
Advertisement
Quote:Original post by Flatlander
I'm not a language lawyer but since...


As this was originally about Lisp for games programming. Which Lisp would people recommend for games programmers and what aspects of game programming do you think it would be most suitable for?
Probably Corman Lisp on Windows and CMUCL/SBCL on Unix derivatives. I'm currently testing the SDL bindings for Corman Lisp to see how Lisp could work in games programming. In general I have a feeling that it's easier to handle I/O style operations in another language and handle more game logic related tasks in Lisp.

If you check the Paradox games (Europa Universalis/Crusader Kings...) you can see that the event files and save games look like this:

#Hugh O'Neills Irish Rebellion## Edited by Johnny Canuck     #event = {	id = 3022	trigger = {		NOT = {			religion = catholic			religion = counterreform		OR = {			owned = { province = 231 data = -1 } #Connaught - New			owned = { province = 232 data = -1 } #Ulster - New			owned = { province = 233 data = -1 } #Meath - New			owned = { province = 235 data = -1 } #Munster - New			owned = { province = 234 data = -1 } #Leinster - New			}		}	}	random = no	country = ENG	name = "EVENTNAME3022"	desc = "EVENTHIST3022"	style = 3	date = { day = 1 month = january year = 1592 }	offset = 60	deathdate = { day = 30 month = december year = 1599 }	action_a ={			#We are not amused!#		name = "ACTIONNAME3022A"		command = { type = revolt which = 232 }		command = { type = revolt which = 232 }		command = { type = revolt which = 231 }		command = { type = revolt which = 231 }		command = { type = revolt which = 235 }		command = { type = relation which = SPA value = -150 }		command = { type = stability value = 1 }	}}


They could probably have saved a lot of time by using Lisp for game logic.
Quote:Original post by Erik S. Andersson
Probably Corman Lisp on Windows and CMUCL/SBCL on Unix derivatives.


I see. What do you see as the main advantages of Lisp other other non-mainstream languages (e.g. Haskell, Ruby, OCaml, SML, Python) in the context of game development?
Quote:Original post by jdh30

I see. What do you see as the main advantages of Lisp other other non-mainstream languages (e.g. Haskell, Ruby, OCaml, SML, Python) in the context of game development?


Since I haven't actually made any game in Lisp I'm not sure if I'm the right person to answer that question. Of the languages you mention I've only used Python to make a simple Tetris with Pygame, and I haven't even used Ocaml or Ruby. It's possible that Lisp is well suited to the type of strategy games that Paradox are making if their file format is any indication.

Even in the cases where I use C++ for games I alway start with a simple Lisp system for binding functions to a quake-style console. With the new templates and anonymous functions in C# I noticed that it had gotten pretty simple (to bind functions) in that language as well.
Quote:Original post by jdh30
As this was originally about Lisp for games programming. Which Lisp would people recommend for games programmers and what aspects of game programming do you think it would be most suitable for?

For Linux, definitely CMUCL or SBCL. If you are willing to spend some money on it Allegro CL or Lispworks seem very nice(linux/mac/windows). And if you don't need native compilation CLisp runs on most platforms. Then there is ECL & GCL of which I don't know much about.
I too think that Paradox's games would suit lisp perfectly, in general complex strategy/rpg games where fast action isn't the catch. Fallout, Combat Mission, Morrowwind etc. I don't think anyone has really tried any fast paced 3d-lisp-action on stock hardware so maybe it would work too.
I've been prototyping an X-com style game with CMUCL+SDL and so far it runs fine on an my old Thinkpad (233mhz/96mt), I guess it would work just fine with CLisp too.
Use the 'regular' toolkits (sdl, opengl, native guis, 3d-engines etc...) but keep as much code as possible on the lisp side as interacting with c(++) can be a pain. At least that's my plan.
Just did a quick test running some Irrlicht demo from CMUCL (hits debugger, div by zero?), Lispworks works fine though so it looks like I've got some bindings to do...

As for lisp's benefits in game developing (speaking purely as a hobbyist, of course); I like it's interactive nature, you can keep game running on one thread and level editor on other while you are defining new functions on the run in the third. You are free to quickly test & fix (and break) stuff, compiling function at a time, with a powerful condition system and debugger. Lisp's debugger is one good reason to keep C-code at minimum as it tends to introduce C style 'error-handling' in to lisp (segfaults). Hmm, I guess most of these features don't look that desirable to an ML'er ;-)


[Edited by - Flatlander on August 4, 2005 2:00:38 PM]
---from www.yellow-hut.com/blog
Quote:Original post by jdh30
Quote:Original post by Erik S. Andersson
Probably Corman Lisp on Windows and CMUCL/SBCL on Unix derivatives.


I see. What do you see as the main advantages of Lisp other other non-mainstream languages (e.g. Haskell, Ruby, OCaml, SML, Python) in the context of game development?
Macros and speed.
“[The clergy] believe that any portion of power confided to me, will be exerted in opposition to their schemes. And they believe rightly: for I have sworn upon the altar of God, eternal hostility against every form of tyranny over the mind of man” - Thomas Jefferson
Quote:Original post by Tron3k
Quote:Original post by jdh30
Quote:Original post by Erik S. Andersson
Probably Corman Lisp on Windows and CMUCL/SBCL on Unix derivatives.


I see. What do you see as the main advantages of Lisp other other non-mainstream languages (e.g. Haskell, Ruby, OCaml, SML, Python) in the context of game development?


Macros and speed.


Macros yes. But speed? I thought Lisp was one of the slowest languages on my list. According to the shootout, CMUML is faster than OCaml on 3/13 tests and is often an order of magnitude slower. Can you point me to some evidence of fast Lisp implementations and programs?
Quote:Original post by jdh30
Macros yes. But speed? I thought Lisp was one of the slowest languages on my list. According to the shootout, CMUML is faster than OCaml on 3/13 tests and is often an order of magnitude slower. Can you point me to some evidence of fast Lisp implementations and programs?

Generally, when people talk about speed as an advantage of Lisp, they are referring to development speed.

And, of course, the shootout benchmarks are flawed, anyway.
Quote:Original post by Nathan Baum
Quote:Original post by jdh30
Macros yes. But speed? I thought Lisp was one of the slowest languages on my list. According to the shootout, CMUML is faster than OCaml on 3/13 tests and is often an order of magnitude slower. Can you point me to some evidence of fast Lisp implementations and programs?

Generally, when people talk about speed as an advantage of Lisp, they are referring to development speed.


I see. What do you see as the ideal sorts of applications for Lisp, in terms of development speed?

Quote:
And, of course, the shootout benchmarks are flawed, anyway.


Yes. Well, I think everyone would agree that Lisp is in the middle of the languages I listed in terms of performance, particularly in the context of games.

Can anything be done to get Lisp within an order of magnitude of performance on my ray tracer, for example?

This topic is closed to new replies.

Advertisement