@ldbeth but it's wrong to suggest that article is anti-continuations, because the point of it is to advocate for call/prompt (delimited continuations) as the "correct" way to use continuations. He's not against continuations, he's against the primacy of continuations that don't always return a value.
"#Gauche tracks source code location information and shows it in the stack trace. However, what if the source is generated by macros? In 0.9.12, the macro expander re-attached the original source info to the outermost form of the macro output. However, if a runtime error occurred in constructed code other than the outermost one, stack trace couldn't find the info and had to show '[unknown location]'. It was annoying especially when the code was the result of nested macro expansions, that you didn't get a clue about where the error came from."
The problem with the #Hurd is that it really offers the most convincing vision of what a future generic #OS kernel to succeed #Linux should offer, and its actually out there and you can try it and it's an incredibly convincing vision, certainly taking virtualization to the furthest extent of anything I'm aware of, but building it on #Mach was a huge mistake.
@screwtape@ldbeth@galdor@svetlyak40wt was thinking sticking to lisp(s) in general might generate some likewise-applicable responses, but wanted to limit it to #lisp so that things don't stray too far off into the well-trodden #gdb debugging discourse
I think they are pretty similar actually, with the major differences imo being that #scheme implementations typically reify stack frames as continuations, allowing you to step through program execution live without necessarily needing a macrostepper, while #CommonLisp offers the SLIME/Sly experience on top of countless battle hardened tools & techniques developed over decades, with of course the downsides of a dynamic lexical environments and lack of hygiene that can lead to particularly funky debugging situations.
Most schemes have let-syntax, which I believe is like macrolet but with syntax-objects, which is another distinguishing difference. Syntax-objects are like records with an AST & source location information. It's worth noting that Robert Smith said that Common #Lisp's lack of a means to perform transformations over locations is one of the biggest obstacles to improving #coalton's user experience: https://twitter.com/stylewarning/status/1574868014855380992
But overall, scheme systems are typically very bare bones, you're often expected to roll ad-hoc debugging tools that I believe common lisp ships with. But the attraction of this is that our systems are easy to decompose and mold into whatever you need, and tools you simply can't imagine elsewhere (because of lack of first-class continuations) simply fall out the bottom once you get the hand of it. But I'll admit, moving from #racket to pure scheme was at times daunting and very challenging, whereas I could pretty much pick up racket and roll with it.
that article is also out of date concerning continuations as an unavoidable performance hit. a proper implementation of delimited continuations, ie one with "partial continuations", allows for arbitrarily jumping between stack frames at runtime, and this enables super powered optimizations. part of why Java invested so heavily in implementing them with project loom is because the major performance wins performace benefits they make possible.
#guix tip of the day:
upstream server issues got you retriggering a command until the download succeeds? fire up a #guile repl and have it automate the process for you with just a few lines of #scheme.
@jeko took me 2 minutes max. in my experience, the challenge of replacing bash with #guile took about 1.5 years of fiddling around and figuring out how to do everything, which is certainly a long time when compared to learning to use bash, but now bash just seems like a messy, inconsistent interpreter for creating tangled webs of dynamic state, compared to scheme's extremely clean, generic and well-scoped approach to interactive userland system scripting. And I get things done much faster... most of the time, at least.
@ramin_hal9001@jeko lol, I need to put a repository up collecting example scripts. the problem is that I keep all my sketches all in a single, encrypted #OrgRoam repo, which is also where I do my accounting and bills, and WIP writing, etc... this is why I'm becoming interested in #hyperbole, it acts as a hub for organizing and associating links across many repositories, giving you many of the same benefits but without locking you into a monorepo-style approach for the store