Yeah the more I think about it, the more the Julia-to-ASCII-Julia conversion seems untenable.
I did think that some analysis of the source code, as opposed to character-wise replacement, was necessary, but you’re right, I didn’t realize how much. My idea was feasible for reading a single source file: if
alpha is not in the source code, then
α → alpha, or if
alpha1 are present, then
α → alpha2. However,
include or importing can implicitly introduce
alpha1 from other files into the namespace, in which case a cipher bounded to a single source file cannot possibly know to rename
α → alpha2. Moreover, typing
alpha2 to mean
α in other scripts or the REPL can only work if the reverse cipher
alpha2 → α acts beyond that single source file.
I was thinking that any non-ASCII infix operator would be changed to an ASCII function form e.g.
a ⊻ b to
xor(a,b). However, there would be an issue with operators that don’t already have ASCII-named methods. Even if there’s a consistent cipher like
↓ → downarrow, defining a
↓(x, y) method for
3 ↓ 5 doesn’t automatically make
downarrow(3, 5) valid code, and
3 downarrow 5 certainly isn’t valid code. Either the parser needs to incorporate ASCII equivalents or the reverse cipher needs to operate everywhere or, again, you can’t type what you read from one script into another script or the REPL.
The modifying marks are also a problem. I would’ve imagined a cipher for the modifying marks e.g.
3 +̂ₐ″ 5 to
+hatsubasuperquote(3, 5), but right off the bat you can see that
+hatsubasuperquote is parsed with
+ as a unary operator, not
+hatsubasuperquote as a single variable.