When we first encounter the definition of a continuous function in general topology, it often feels completely backward: Why is a map defined as continuous if the pre-image of every open set is open?

Shouldn't a structure-preserving map send open sets to open sets (open map) instead?

Most texts warn us not to confuse the two, throw a couple of counterexamples, and move on.

Here is an essay building an intuition for why this definition works the way it does and why "pushing forward" fails while "pulling back" works to ensure continuity.

author here. the idea is to see how the Y and Z combinators come out relatively naturally given an extremely constrained context with no loops, no recursion, no bindings. the article is intentionally structured as a sequence of failed attempts that progressively reveal which phenomenon is still responsible for the recursive behaviour.

in the article, i define recursion narrowly as "... call the function `fact` from inside the definition of the function `fact`".

you're right that `factgen` is also not recursive but it is also rejected, but for a different reason: self-reference. declarations are banned precisely because they give a function a "name" that can be referenced later.

please note that the solution which uses Z combinator (given at the end) grows from `(x => x(x))(x => x(x))`, which is NOT self-referential. it achieves self-replication by literally rewriting the content of the function twice, which is different from self-referential recursion of `factgen`.

hope that clears some of the confusion.

Thanks for replying.

I think I missed the significance of your narrowed definition of recursion, and didn't apply it the way you intended when I read the article. I admit to my bad reading.

I went on to discuss your article with an LLM and used the experiences I've had _using_ some functional approaches in JS to help it give me a tutorial on the combinators, to try to better understand your article and the underlying principles. I "mostly get it" now, but I will have to go over it a couple more times.

You shared a thought-provoking article, even if I didn't immediately get your intended lesson out of it.

thanks for the feedback. a few people have expressed the same criticism. i'm open to producing a variant with less-curly curly brances. please raise an issue, if you want to use it.

as is expected, all codes in the illustrations, especially the C code, are to be judged superficially, ie, by their covers, not content :)

as i mention in the description, Myna doesn't use ligatures. the Unicode sure looks very much like that in the font, though.

designer here. thanks for the feedback. i've updated the serif in `l` after an issue raised the possibility of ambiguity with `1`. alas, that would mean i'd need to regenerate all the images, which i haven't done yet.

i didn't produce a variant for the `l` serif, please check issue #8. if you prefer the variant, please open an issue. can you elaborate on the kerning point, preferably there also?

thanks for the feedback. i think the em-dash is not very different in case of this font too. i made the (en-)dash so wide that there was no way to disambiguate within fixed-width constraints. i don't use em-dash at all, so there was no need to disambiguate too.

if you want to use it but em-dash is the only deal-breaker, please try it once and raise a feature request. i'd see what we can change to make it work.

yes, indeed. "condensed" means smaller width and less space between characters, in general. it allows for slightly more code to be shown on the screen horizontally.

any particular glyph you find surprising in Myna? feel free to open a feature request.

None, and that’s the great feature about it.

The comment above requesting that ^ be turned into something unexpected would have been a negative, but thankfully it’s not a feature of the font.

i have addressed this in one of the other comments. it is impossible to achieve both elegance (good look) and consistency (monospace width) in these cases. many folks, like yourself, are pioneering full Unicode editing. we, on the other end, are just trying to make editing without ligatures elegant because ASCII, i believe, would remain predominant for a long time to come.

I kind of think monospacing is overrated in programming. Sroustrup typeset the entire of The C++ Programming Language in variable width font and it looks totally fine. I've used variable width fonts in my editor a fair bit too.

I think the main problem with it is you need to use tabs for indentation and unfortunately spaces comprehensively won that battle. IMO that's because although tabs are clearly better, spaces are definitely more idiot-friendly and there are a lot of idiots in the world - or at least people who don't give a shit about nice formatting. So large tab based codebases tended to end up with a horrible mix of tabs and spaces.

Speak for yourself please. I have problems reading and writing code which is not monospace

well, my "pioneering efforts" :) are killed by language designers, as you note "it is impossible", so we can only waste time looking for various workarounds like using fonts designed around those limits...

i think that you also maintained that it is impossible to reconcile monospace with Unicode.

what would be ideal is a variable-width font which covers most Unicode characters consistently. some Unicode characters (eg, arrow) would need space of 2 characters and so on. making it elegant would require quite a lot of work to ensure Unicode does't look out of place (eg, arrow in your comment).

these are the problems which make me feel full Unicode editing is difficult to achieve in the short run. not to mention the obvious issue of typing Unicode characters from the ASCII keyboard.

i've included a reasonable subset of Unicode in Myna but it may not look very good. don't get me wrong, i appreciate the Unicode advocacy. but until we've something good-looking and well-behaving tooling on that side, using it would be quite frustrating.

Is it really impossible? I'm not disputing you, but for my own learning. Is there somewhere I could read about impossibility of ligatures and monospace?

It's just a fundamental limitation of being boxed, nothing deeper than that: that means you can't fully control spacing, which is crucial in any design. For a simplified example, you can't have a long arrow that is as wide as 2.5 boxes, but instead of 0.5 boxes for spacing only have 0.1 (so a total of 2.6 boxes)

thanks for the feedback. if that be the case, i'm afraid Myna might not be of much use to you.

That's not the case.

Rather, you don't provide reasons to motivate people to switch to your font and stick with it.

You have mainly two kinds of users:

- those who have always stuck with whatever font came up by default in their text editor or terminal emulator.

- those who have gone through a phase of experimenting and tried a good bunch of fonts, then settled.

When you motivate the former group to experiment, they will tend to go into the second group: once they get into the workflow of installing fonts, they won't just stop at the one that was suggested to them first.

The second group is harder to motivate to try new fonts; they will do it if there is some compelling reason they can understand /before/ installing.

You don't explain how your font stands out above the competition. Or, maybe the personal angle: I tried these fifteen different fonts and still had to make one because X, Y, Z, so here it is.

i thought the illustrations were enough to decide if one likes the font.

now i have also added a comparison table of Myna with many popular monospace fonts (if that could help gauge the utility).

i understand that there would be many many folks who would find this font ugly and unusable. it is largely a matter of personal preference.

Don't misunderstand; the examples do look great.

> find this font ugly and unusable

Not even remotely the case; they would have to get their heads examined.