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

Gamedev in Lisp. Part 2: Dungeons and Interfaces

gitlab.com

Post reply on HN
Print view View original

51–60 of 68 posts

Re: Gamedev in Lisp. Part 2: Dungeons and Interfaces

#51

Post by groovy2shoes »

shawn_w wrote: post #41
SatvikBeri wrote: post #32

Earlier quoted context omitted.

This isn't really true – you have languages like Odin that only have a for loop, no while loop, that only supports index-based iteration. Then you have languages like Python that let you loop over an arbitrary iterable, and define your own iterables. Some languages allow conditionals in loops, some don't. Some let you loop over multiple iterables, while some only take one at a time. Common Lisp happens to be on the u…

And then there's Scheme, where there are no iterative loops; all looping is done with recursion. You can build pretty much everything other languages do with loops on top of that, though.

Not true. Scheme has `do`. See R7RS section 4.2.4 "Iteration".

Re: Gamedev in Lisp. Part 2: Dungeons and Interfaces

#53

Post by lispm »

medo-bear wrote: post #49
shawn_w wrote: post #48

Earlier quoted context omitted.

No, I mean do. It's basically just a C style for loop except with a return value. Nothing special.

yes the syntax for 'do is simple, like that of lisp. however 'do allows you to make far more complex iteration constructs than 'loop. 'loop is just a DSL to make some of these constructs more concise. read up on it

LOOP has the DO functionality included.

Example:

    CL-USER 18 > (do ((a 1 (+ a 1))
                      (b 10 (* b 1.5))
                      (c nil))

                     ((> a 5) (list a b (reverse c)))

                   (push (* a b) c))

    (6 75.9375 (10 30.0 67.5 135.0 253.125))

    CL-USER 19 > (loop for a = 1 then (+ a 1)
                       and b = 10 then (* b 1.5)
                       and c = NIL then c

                       when (> a 5) do (return (list a b (reverse c)))

                       do (push (* a b) c))

    (6 75.9375 (10 30.0 67.5 135.0 253.125))

Re: Gamedev in Lisp. Part 2: Dungeons and Interfaces

#54

Post by medo-bear »

lispm wrote: post #53
medo-bear wrote: post #49

Earlier quoted context omitted.

yes the syntax for 'do is simple, like that of lisp. however 'do allows you to make far more complex iteration constructs than 'loop. 'loop is just a DSL to make some of these constructs more concise. read up on it

LOOP has the DO functionality included. Example: CL-USER 18 > (do ((a 1 (+ a 1)) (b 10 (* b 1.5)) (c nil)) ((> a 5) (list a b (reverse c))) (push (* a b) c)) (6 75.9375 (10 30.0 67.5 135.0 253.125)) CL-USER 19 > (loop for a = 1 then (+ a 1) and b = 10 then (* b 1.5) and c = NIL then c when (> a 5) do (return (list a b (reverse c))) do (push (* a b) c)) (6 75.9375 (10 30.0 67.5 135.0 253.125))

You can also express LOOP constructs in terms of DO. However if you were to construct a more exotic iterator that is not so straight forward in LOOP (beware of edge cases), I think it is more reasonable to pick DO. I think also that your example illustrates this.

Re: Gamedev in Lisp. Part 2: Dungeons and Interfaces

#55

Post by shawn_w »

groovy2shoes wrote: post #51
shawn_w wrote: post #41

Earlier quoted context omitted.

And then there's Scheme, where there are no iterative loops; all looping is done with recursion. You can build pretty much everything other languages do with loops on top of that, though.

Not true. Scheme has `do`. See R7RS section 4.2.4 "Iteration".

Scheme's `do` is implemented using recursion. There's a sample macro for it in 7.3.

Re: Gamedev in Lisp. Part 2: Dungeons and Interfaces

#56

Post by lispm »

medo-bear wrote: post #54
lispm wrote: post #53

Earlier quoted context omitted.

LOOP has the DO functionality included. Example: CL-USER 18 > (do ((a 1 (+ a 1)) (b 10 (* b 1.5)) (c nil)) ((> a 5) (list a b (reverse c))) (push (* a b) c)) (6 75.9375 (10 30.0 67.5 135.0 253.125)) CL-USER 19 > (loop for a = 1 then (+ a 1) and b = 10 then (* b 1.5) and c = NIL then c when (> a 5) do (return (list a b (reverse c))) do (push (* a b) c)) (6 75.9375 (10 30.0 67.5 135.0 253.125))

You can also express LOOP constructs in terms of DO. However if you were to construct a more exotic iterator that is not so straight forward in LOOP (beware of edge cases), I think it is more reasonable to pick DO. I think also that your example illustrates this.

I would miss the in-order collects, actually collect/maximize/... features, destructuring of lists, direct type declarations, ...

I also find DO not easy to read and understand.

The code from above I would actually write in LOOP as

    (loop for a from 1 upto 5
          and b = 10 then (* b 1.5)
          collect (* a b) into c
          finally (return (list a b c)))
I find that to be readable.

Re: Gamedev in Lisp. Part 2: Dungeons and Interfaces

#57

Post by awkravchuk »

varjag wrote: post #39
maxwelljoslyn wrote: post #30

This is what all technical tutorials should look like. Well-composed and generally free of grammatical errors, spends just the right amount of time explaining each new topic as it is introduced, comes with full code samples, and includes visual samples of what the code does. Also, lengthy enough to treat the material in depth, while still being sufficiently self-contained that I can follow along -- without having rea…

Seconded! Top notch longform programming material.

Thanks so much guys :)

Re: Gamedev in Lisp. Part 2: Dungeons and Interfaces

#59

Post by medo-bear »

lispm wrote: post #56
medo-bear wrote: post #54

Earlier quoted context omitted.

You can also express LOOP constructs in terms of DO. However if you were to construct a more exotic iterator that is not so straight forward in LOOP (beware of edge cases), I think it is more reasonable to pick DO. I think also that your example illustrates this.

I would miss the in-order collects, actually collect/maximize/... features, destructuring of lists, direct type declarations, ... I also find DO not easy to read and understand. The code from above I would actually write in LOOP as (loop for a from 1 upto 5 and b = 10 then (* b 1.5) collect (* a b) into c finally (return (list a b c))) I find that to be readable.

Of course to each their own. I like LOOP a lot actually when I need to do something familiar, however for something unfamiliar DO is often my choice. It also serves as a caution to tread and think carefully when I return to the code. Sometimes, after a while, I realise how to do the DO construct succintly with LOOP

Re: Gamedev in Lisp. Part 2: Dungeons and Interfaces

#60

Post by BoingBoomTschak »

shawn_w wrote: post #46
BoingBoomTschak wrote: post #44

Earlier quoted context omitted.

Interesting concept, but it visually has the same problem as loop IMO, using keywords to implement a new syntax instead of seamlessly blending with Lisp (at the cost of needing code walking, though). And it seems to lack all the iterations drivers (incl. builtin destructuring) that make half of loop/iterate's usefulness and "reads like English" comfy factor; especially liking (for (i j) on list [by #'cddr]) (for i in…

Racket splits up the iteration forms from what to iterate over (sequences[1]). You can compose different sequence constructors together, or make brand new ones, without introducing new syntax. It has limited destructuring - sequences can return multiple values, all of which can be bound. There's an adapter to convert one that does that into returning a single list, but not the other way around. If there was it could…

Ah, I see, though I'd say it pollutes the function namespace a bit this way (as "in-x" semantically only makes sense in a loop) and missing on-list. Technically, you could do most of these in a few lines of CL too, but well, convenience is the point of these macros.

Those seem to return sequences instead of streams/iterators, any idea why? Though it says "An in-list application can provide better performance for list iteration when it appears directly in a for clause", so I guess there's some macro magic at play.

Anyway, thanks for exposing those, Racket does seem to be pretty practical (and with its Chez backend, I guess it's pretty fast); can't stand the square brackets used as syntax (as opposed to vector literals used as data), though ¯\_(ツ)_/¯.

Post reply on HN