Hacker News Reader

Comment by john-shaffer | Hacker News Reader

> I wonder whether a naming convention would solve the problem? If all coroutine functions and methods have names like fire-arc* and move* , then your synchronous call to fire-arc* would stick out like a sore thumb.

That'd be fine as long it's simple to write a wrapper of a different color. If I change fire-arc to fire-arcSTAR, but I can do a quick (def fire-arc (to-sync fire-arcSTAR)) then I don't have to visit call-sites. If it's not possible to make a wrapper, then that would be a major pain point.

Edit: Can't get HN to print the asterisks.

View on HN

But the * suffix marks functions which might stagger their execution over multiple frames. If a function calls fire-arc* , then that function should also have the * suffix; otherwise, the suffix would be meaningless.

You're asking for the ability to refactor a synchronous function into an asynchronous function without needing to review the function's callsites. By definition, this would come with a high price: when writing a step handler, you'd need to assume that any function call could be refactored so that it doesn't return until several frames in the future. Even for a Lisp, that seems chaotic!

Oh, thanks for the explanation. That makes things very clear.

I'm not sure when I'll get time to play with GameLisp, but it looks absolutely brilliant. I'll keep an eye on it; maybe some interesting open-source project will turn up that I can hack on.

I think we have different views about the process of scripting behaviors, which determines most of our conversation so far. I don't like taking algorithms in my mind, breaking them up into basic blocks by hand, and writing a switch statement in a step handler. I especially don't like iterating on code that has been manually turned inside out in this way. So I do not write any step handlers at all, barring extremely general things like "things move in the direction they are moving."

Sounds like an interesting approach - can you point me towards any open-source code written in this style?

I don't have any particular project in mind, but every BulletML game and many Danmakufu games are written this way. My favorite BulletML game is rRootage[0], but the scripts used in rRootage are procedurally generated combinations of scripts from other games, so they may not make good reading. I think Shiroi Danmakukun[1] features handmade scripts.

BulletML and Danmakufu's scripting language are not my favorite languages for other reasons.

[0]: http://www.asahi-net.or.jp/~cs8k-cyu/windows/rr_e.html

[1]: https://shinh.skr.jp/sdmkun/

Reply on news.ycombinator.com