If you think that's good, then you're gonna love this "simplified" real code posted as a real issue on one of my Github repos.
Edit: updated link to address the stack-trace comment
That's not actual code though, it looks like some kind of trace. Notice the filenames at the end of each line.
The actual solution the issue opener there might be looking for is to disable C++ parsing, since it's not actually C++ code, it's just some text they pasted into VSCode and they're wondering why their editor can't handle it.
Without thinking about it much, my understanding was that each line of the stack trace referred to a real line, even though the block as a whole wasn't a program.
But! because of this comment I went and checked the lines of those stack traces. And in fact, they're not real lines, just the C++ type expansion.
That said I've got a another half as bad example that is real so Ive edited the comment to point to that example instead.
Image Transcription: Code
[Transcriber's note: the first line in the following transcription is incorrect. After the equals, there should be eight instances of the word "Option", each succeeded by a less-than symbol, then two brackets, like (), before the first greater-tha symbol. However, if you type a less-than symbol on Lemmy, it seems to strip that symbol and whatever word comes next out of the source when you save the comment.]
type Wtf = Option>>>>>>>;
let two = Some(Some(Some(Some(Some(Some(None))))));
let three = Some(Some(Some(Some(Some(None)))));
let six = Some(Some(None));
unsafe {
assert_eq!(
std::mem::transmute::(two) * std::mem::transmute::(three)
std::mem::transmute::(six)
);
}
I am a human who transcribes posts to improve accessibility on Lemmy. Transcriptions help people who use screen readers or other assistive technology to use the site. For more information, see here.
Good human, but why not use tesseract though? I mean it works quite well with monospace fonts
Still needs to be checked over to make sure it didn't get anything wrong. In my experience the mistakes AI make with monospace fonts tend to be very awkward to notice (like 1 and l and I and | being interchanged), so I'd have to go over with a fine tooth comb which, for me, since I type quickly, isn't noticeably faster and is a lot more boring.
Since all of the expressions just wrap a None, I wouldn't be surprised if the transmutes basically get compiled to 0, making the assertion at the end assert_eq!(0 * 0, 0).
Nah these are the actual integer representations. Otherwise you would have Some(None) == Some(Some(None)) which is way too Javascripty for Rust folks.
That's kind of wild, I double-checked and it's true.
Although I disagree with the second part, the Rust folks wouldn't care about the in-memory representation as long as the compilation is on point.
Looking closer at the final enum, I guess it's because there are nine possible cases for it, making the compiler pack it into 4 bits, with one number representing each? I checked and None is represented as 8, while 7 Somes containing a None is 0 and the full 8 Somes is represented by 1.
the Rust folks wouldn’t care about the in-memory representation as long as the compilation is on point.
Well I can't speak for everyone, but Rust is very intentional about supporting things like repr(C). At least some of us care a lot.
It's somehow inverted. If it was Peano, two would be represented by two Somes, not by six. I have no idea how this one works.
For those interested, this is because of how Rust uses value gaps to represent its nullable/enum structures. E.g., like how None for Option NonZeroU8 [sic, can't get formatting to work] is represented internally by a 0 instead of a wrapping structure.
When you have that many layers around a unit, it will start at 0 and bump the internal representation for each Some you turn into a None.
No, not at all. It's a joke post, abusing the in-memory representation of the Option type to construct numbers. When nesting the Option type, it turns into a densely packed bit vector...
And if I understand the purpose of Fin correctly, you're picking on the one 'peasant language' that actually has something like that built-in.
In Rust, you can specify the type of an array as e.g [u8; 3]. Which is an array containing values of type u8 (unsigned 8-bit integer) with a fixed, compile-time-guaranteed length of 3. So, [u8; 3] could be used to represent an RGB color, for example.
It is an array, not a set, but well, close enough.
Fin is a type of finite oridinals bounded by a nat. For example the WTF type in there is the same type as Fin 8.
Of course every language can have Fin with a fixed integer, like the post suggest, by just stacking options.
However for a properly defined Fin type, the input number is dynamic, serves as a bound for the element of the type. For example, Adga was able to type the fact that nth fibonacci number is a finite ordinal bounded by a function of n. Which I believe is not typable in rust?
And yet still more better than writing a serious macro
Definitely looks
unsafeto me.If you think that's good, then you're gonna love this "simplified" real code posted as a real issue on one of my Github repos.
Edit: updated link to address the stack-trace comment
That's not actual code though, it looks like some kind of trace. Notice the filenames at the end of each line.
The actual solution the issue opener there might be looking for is to disable C++ parsing, since it's not actually C++ code, it's just some text they pasted into VSCode and they're wondering why their editor can't handle it.
Without thinking about it much, my understanding was that each line of the stack trace referred to a real line, even though the block as a whole wasn't a program.
But! because of this comment I went and checked the lines of those stack traces. And in fact, they're not real lines, just the C++ type expansion.
That said I've got a another half as bad example that is real so Ive edited the comment to point to that example instead.
Image Transcription: Code
[Transcriber's note: the first line in the following transcription is incorrect. After the equals, there should be eight instances of the word "Option", each succeeded by a less-than symbol, then two brackets, like
(), before the first greater-tha symbol. However, if you type a less-than symbol on Lemmy, it seems to strip that symbol and whatever word comes next out of the source when you save the comment.]I am a human who transcribes posts to improve accessibility on Lemmy. Transcriptions help people who use screen readers or other assistive technology to use the site. For more information, see here.
Good human, but why not use tesseract though? I mean it works quite well with monospace fonts
Still needs to be checked over to make sure it didn't get anything wrong. In my experience the mistakes AI make with monospace fonts tend to be very awkward to notice (like 1 and l and I and | being interchanged), so I'd have to go over with a fine tooth comb which, for me, since I type quickly, isn't noticeably faster and is a lot more boring.
Good Human
Peano arithmetic moment
Since all of the expressions just wrap a
None, I wouldn't be surprised if the transmutes basically get compiled to0, making the assertion at the endassert_eq!(0 * 0, 0).Nah these are the actual integer representations. Otherwise you would have
Some(None) == Some(Some(None))which is way too Javascripty for Rust folks.That's kind of wild, I double-checked and it's true.
Although I disagree with the second part, the Rust folks wouldn't care about the in-memory representation as long as the compilation is on point.
Looking closer at the final enum, I guess it's because there are nine possible cases for it, making the compiler pack it into 4 bits, with one number representing each? I checked and
Noneis represented as8, while 7Somes containing aNoneis 0 and the full 8Somes is represented by1.Well I can't speak for everyone, but Rust is very intentional about supporting things like
repr(C). At least some of us care a lot.loud suicide noises
Is that a Peano Axioms reference ?
https://en.wikipedia.org/wiki/Natural\_number#Peano\_axioms
It's somehow inverted. If it was Peano, two would be represented by two Somes, not by six. I have no idea how this one works.
For those interested, this is because of how Rust uses value gaps to represent its nullable/enum structures. E.g., like how
NoneforOption NonZeroU8[sic, can't get formatting to work] is represented internally by a0instead of a wrapping structure.When you have that many layers around a unit, it will start at
0and bump the internal representation for eachSomeyou turn into aNone.It's kinda like lambda calculus numbers
Is this how you do Fin in peasant languages?
No, not at all. It's a joke post, abusing the in-memory representation of the
Optiontype to construct numbers. When nesting theOptiontype, it turns into a densely packed bit vector...And if I understand the purpose of
Fincorrectly, you're picking on the one 'peasant language' that actually has something like that built-in.In Rust, you can specify the type of an array as e.g
[u8; 3]. Which is an array containing values of typeu8(unsigned 8-bit integer) with a fixed, compile-time-guaranteed length of3. So,[u8; 3]could be used to represent an RGB color, for example.It is an array, not a set, but well, close enough.
Finis a type of finite oridinals bounded by a nat. For example theWTFtype in there is the same type asFin 8.Of course every language can have
Finwith a fixed integer, like the post suggest, by just stacking options.However for a properly defined
Fintype, the input number is dynamic, serves as a bound for the element of the type. For example, Adga was able to type the fact thatnth fibonacci number is a finite ordinal bounded by a function ofn. Which I believe is not typable in rust?And yet still more better than writing a serious macro