yes, I agree, Dariusz. Let me investigate, I think the formal parameter only gets initialized and registered as variable when the ring is called with an actual argument.
[edit] yeah, looks like I can safely take out the conditional in the code that only creates a formal ring parameter if it corresponds to an actual argument in the call, and then it gets initialized with zero. I'll do that and release a quick patch later today. Thanks for the catcht!
[edit2] done!
Talking about priorities 
Won't the patch hurt other applications? (I have no specific application in mind)
I hope not 
The priority is that right now I'm working on a little tweak for bulk-renaming variables, and while I'm preparing this patch I'm also including a few other little things that seem to be stable enough to be included in this week's patch. Rather than waiting until the end of the week I want to get it out today, so I can react to possible issues before I'll be on vacation for the next 2 weeks.
[edit] What I really am in a hurry to get out is an extended version of support for teaching OOP in Snap! because that's what all the curriculum people in Europe are asking me for. It's strange, because - much as I'm a huge fanboy of Smalltalk - I'm not terribly excited about teaching OOP to kids in school. Oh, well, but turns out OOP is in all the curriculum frameworks and needs to be covered. I believed we'd done a pretty great job with Snap's prototypical inheritance for sprites (I still think that it's beautiful), but the curricula often require teaching OOP together with data structures using "data" classes, non-visual stuff such as purchase orders, customer records etc. and they often don't map those easily to our sprites as data containers. So, to address this I've spent the summer adding prototypical inheritance and data-scope to Snap's lightweight list-based dictionaries (lists of key-value pairs). But that's for another thread...
Real-time update 
On closer inspection ... I haven't been able to get report or script variables to work within the caller's context. How did you do it?
Before this school year, (when I didn't have access to my friend with a phone who could post on the forum), I sent an email to Brian implementing gensym var names using metaprogramming. It actually was just a simple hidden variable storing a counter, and some list manipulation.
is the issue translating the word doc to texinfo, or texinfo to a webpage?
if it's any more convenient for the tooling, you could write the manual as just the webpage. html/css supports various features for printing. css has a property for creating page breaks, per-page styling, and you can override any styling for printing with a media query. it would also probably make contributing easier than with tex since it's web development like the rest of snap instead of a completely different format.
I think using a markup format, like TEXInfo would be better, because that makes editing something like the snap manual easier than using pure html/css.
Of course I prefer to use a markdown to html system, or something like docusaurus, which allows you to make some documentation site fast, easier to write (since it uses markdown for the content), and allows you to add your own custom components, for example, snapblocks (although that would probably not be in the snap manual, it would probably just be smart script pics).
huh, i thought i mentioned markdown but i must've removed it while editing.
markdown is actually what i meant to reccomend. it's a superset of html, so all html works, and you can use a <style> tag for css.
No, markdown is just a text formatting language, however it does have support for html (if the developer decides to). It's not a subset of html, it just can have support for it.
Gosh, lots has happened while I've been away from my computer all day.
Gensyms are easy; it's just
where GENSYM COUNTER is a global variable. So we can stop talking about that aspect of the algorithm.
Jens, just to be clear, at least as of now I don't expect to ask you to implement anything special to define macros programmatically. The metaprogramming tools we already have should be enough.
I do think that if the idea of a macro syntax catches on, you might end up wanting to implement a "Make a macro" GUI. That's something we can't do, I think, with metaprogramming. But I wouldn't even want you to do that until we had a solid joint understanding of what a macro should look like.
About the metaprogramming library getting in the way of the manual:
Let me be absolutely clear that what's gotten in the way of the manual, more and more seriously as time passes, is my own psychological inability to do any work at all over the past several years. I should have been keeping up with the software one minor release at a time, and then the major releases wouldn't have been such a killer problem. This has nothing to do with our differing ideas about what to do first; I'm not doing anything, not even debugging the streams version of my Mastermind project, which is just debugging, something I'm allegedly good at. Believe me, nobody is more upset about this state of affairs than I am.
The manual chapter on metaprogramming is currently terrible and needs a complete rewrite. Here I guess we have a relevant disagreement; I think that the metaprogramming tools are hard to use for anyone except you, and that meanwhile the rest of the world has had some pretty good ideas about how to design a metaprogramming capability that ordinary programmers can use and understand. They're not my ideas; I'm not doing Not-Invented-Here about this. So, yes, I think that the best and quickest route to good documentation about metaprogramming runs through the path of doing some user-level (library) software development first.
I started trying to work on the manual some time ago, and I did it by going through HISTORY.md in chronological order, and that just seemed like an insuperably hard slog, and it occurred to me that I might have better luck if instead I started with the big ideas that need work. It's not just metaprogramming, although that's the most extreme case; there is a chicken-and-egg problem about how to discuss hyperblocks, namely, that the underlying scalar blocks are easy Chapter-One stuff, whereas lists are a couple of chapters later. So either we start out sorta lying about the operators, documenting as if their domains were limited to scalars, and revisiting them after we have lists (and HOFs) under the reader's belt, or we move the discussion of lists way earlier and then talk about the complete domains of the operators. Right now the manual sort of does a little of each of those things. I need to tear out all that and redo it. My idea is that if I'm focusing on a few big ideas, maybe I can get myself to write about them, and get the manual not only in much better shape, but much better positioned to let other people file PRs documenting the myriad little details.
TeXInfo vs. markdown vs. whatever:
Again, what to do depends very much on how much one cares about producing a beautiful PDF. I agree with @sarpnt that by far the easiest thing to do would be to ditch the PDF altogether and just have an online, hyperlinked document with one (web) page per subsection. I'm reluctant to do that, because I want a beautiful PDF. TeX is clearly the best way to accomplish that goal, better than Word, because it gives you better control over positioning and formatting, and doesn't think it's smarter than you are. When I started in the documentation game, it was hard to get pictures in TeX documents because there was no standard notation for it; each implementation of TeX did it differently. But that's all under control now, and in principle it should be possible to get software to do the conversion for us. In practice, though, it'll take a lot of TLC, page by page, to get it perfect -- another Herculean task that I'll never manage. I did that for my books, and I'm glad I did it, but I was younger then and better able to do the impossible.
So, you know, maybe someone should just give me a gold watch and assign the entire documentation department to someone else. And maybe the someone else would just make a web document and be done with it. And I can start reading all the books I've bought but haven't read, and scanning in all my old film photographs, and so on.
Or maybe we can induce someone to do the work of taking the beautiful Word layout and reimplementing it in a medium that can be communally edited.
Or maybe Jens has to write the metaprogramming chapter.
Okay it's 12:30am and I'm going to bed now.
i think you missed the point of what i said. webpages can link to parts of themselves with anchors, and webpages can make good pdfs (or you can just skip that step and print it directly). i'd like to give an example but unfortunately i can't find one.
i think really the only issue with a markdown manual is that as far as i know markdown itself can't generate a table of contents, you would need other tooling for that. this blog post shows how to do it with eleventy. i'm not sure what tooling you currently use for the snap website, but you could likely find a tool for it.
if you want i can make a proof of concept, i'd want to set up and practice this stuff anyways and i have a snap fork i'm working on already i can throw it in with.
Sure, that would be wonderful. Thank you.
Well … almost. There may be other variables around whose names were not created using the gensym algorithm; some of those may be called g3 or something, so a well-behaved algorithm should check for existing variable names in the context of the caller. Plus the gensym counter needs to be created and initialized.
Hmm... now I am depressed. Don't you remember how the two of us two years ago, in a series of Zoom meetings, went through a bazillion different edge cases the likes of this one:
(I took this particular example from the very project we worked on together back then)
and we were both so very pleased with how the "stepping" button now turns the Snap! IDE into a full-fledged "debugger", which is what an IDE should be in the first place?
No. I mean, I believe you, but I don't remember it at all. That's depressing!
