Some languages like Go, Rust use : in their struct initialization syntax:
Foo {
bar: 10
}
while others use = such as C#.
What's the decision process here?
Swift uses : for passing arguments to named parameters (foo(a: 10)), why not =?
I'm trying to understand why this divergence and I feel like I'm missing something.
42 comments · 91% upvoted · other discussions
Ruby also uses : for passing named parameters. It's nice because it's one less thing for the poor, massively-overworked single equals sign = to do. And in Ruby's particular case, it makes a lot of sense. Before the language had real named arguments, foo(1, a: 2, b: 3) was just shorthand for foo(1, {a: 2, b: 3}). Now Ruby has real named arguments, so the "turn it into a hash argument" rule only kicks in on old-style functions that don't take any named parameters.
The choice of colon for initialization is probably designed to evoke a JSON-like feel. We all like colon in hashmap literals, because it looks like JSON. And what are structs but fancy hashmaps?
In the C family of languages, assignment is an expression, so a = b = c is legal, and as a result, the = operator is a poor choice for named arguments.
The = assignments as expressions also leads to a few classes of common bugs in C family languages, so it's hard to defend in a new language, although it's easy to understand in an old languages with an enormous legacy codebase.
Ecstasy uses = for assignment statements (not assignment expressions), and also uses it for named arguments and other similar uses.
``` // assignment String s = "hello world"; (Int x, Int y) = point.coordinates();
// default values void foo(String text, Boolean echo=False) { // ... }
// named args foo(s, echo=True); ```
What does the assignment expression look like then?
The Ecstasy assignment expression uses the <- operator to indicate that the value from the right is copied to the l-value on the left.
As far as features go, it has not been used much, which is probably a good sign. The core libraries for the language do not contain a single instance of its usage, although to be fair, a fair portion of their development occurred before the introduction of the assignment expression.
A long time ago a language designer screwed up majorly and overloaded the equality operator to also be the assignment operator.
This was the wrong answer and a bad answer and it makes programming more confusing to learn, use, and debug.
There are heroes out there trying to step over the technical debt by using the colon operator for assignment, but there is a lot of hostility towards fixing things that have been broken for a long time, even in spaces and contexts where you would think that's the whole point of the space.
I'm not sure how I feel about just a colon for assignment. a := 1 I'm totally on board with, and I wish more languages would do this (if nothing else, having a two-character assignment operator would encourage people to think more functionally, since assignment is marginally more expensive to type). But I still have trouble reading a: 1 as a standalone expression. It looks like part of a DSL or a rule description language to me, not an instruction to set a variable.
I get what you're saying, but I feel like the colon alone is great.
If I gave you ten apples and a note:
John: 5
Jane: 2
Joan: 3
You would know that the note means to give that many apples to those people without any coding experience or familiarity with the grammar and conventions of my instruction notes.
I don't get the added value of a two character expression except, perhaps, to punish variable reassignment.
You would know the correspondence, yes. But you'd be considered a loon to think John equivalent to Jane + Joan.
Indeed.
In my project, types are required to have a sort and a hash method, which enables me to discern equivalence when sort returns 0, identicality when hash is identical, and identity when they share the same address.
I don't know of any language that handles the difference between equivalence, equality, and identity in this manner. Maybe for good reason, but I don't know it.
=(5 `5`) # true
==(5 `5`) # false
===(`5` `5`) # false
How long is the hash? A 64-bit number would likely experience a collision within 232 samples, which is definitely achievable. I'd recommend having an actual equality procedure.
In my language, the default type is "decimal," with unlimited precision.
I don't know what you mean by "actual equality procedure."
As I understand it, there's no way for a language to know whether two objects are "equal" without asking the objects for their fingerprints and comparing their fingerprints. This can be a cryptographic hash of a string mashing up all the attributes of the object in whatever algorithm or precision one fancies.
Naturally, if it's a number, then it's trivial. But when you get into things that aren't numbers, what's equivalent and equal are things that I believe must be left to the type to figure out, and very accessible to the programmer.
There's a more straightforward way to test equality: structural recursion. After checking that the types of the values are identical (a prerequisite to equality in most languages), determine a procedure to test equality depending on the values' shared type.
For example, to compare two lists of lists of numbers:
[[Number]] values have equal lengths.[[Number]], check that the corresponding element in the second [[Number]] is equal using the following procedure. [Number] values have equal lengths.[Number], check that the corresponding element in the second [Number] is equal using the following procedure.That's an optimization for speeding up equality checks for numbers. It's a nifty one, and I appreciate it.
But what I assert, and perhaps you justifiably disagree, is that equality checks can apply to other data types than numbers.
For instance, what if I want "gato" to evaluate as equal to "cat" in an app that does language stuff?
The presence of collisions can be proven via the pigeonhole principle: assuming that the first 2N distinct inputs cover all 2N outputs, the next distinct input must collide, and for those inputs to not cover all outputs, there must be a collision. For a hash to cover any number of inputs, it would need to have unlimited precision, rendering it not actually a hash.
The structural equality algorithm is definitely not specialized to numbers - I in fact said at the start of the explanation that two lists of lists of numbers were being compared. Similar traversal options are available for hash tables, heaps, etc., though the algorithm is much more time-consuming on graphs.
To answer your question, you'd need a very different algorithm from hashing or structural equality, and certainly not one that can be implemented on any type; if hashing is sufficient, then structural equality certainly is.
To be fair to the designer of FORTRAN (John Backus, I guess), he didn't "overload" =, as FORTRAN originally used .EQ. as the equality operator.
I agree that it was a bad choice, but maybe understandable given the very limited character sets at the time? (Looking at https://en.wikipedia.org/wiki/BCD_(character_encoding)#Fortran_character_set#Fortran_character_set), if they modified the character set to fit FORTRAN anyway, of course one could wonder why they designed a character set with "=" instead of, for example "←".)
Anyway, C making a "virtue" out of it (I believe Ritchie or someone else used the argument that assignment was more frequent than comparison for equality) and picking "==" for equality, at a time when ASCII was used, well that should not have happened.
Regarding the situation now, I absolutely agree that there are things that can and should be fixed, including using "×" and "·" in place of "*" (which has other, more appropriate uses), and restricting "=" to equality (which probably also includes equality by definition/declaration, however.) And sure, ":=" could be a classic choice for assignment. However, there is also "←", which I believe was considered for use as assignment in the publishing variant of Algol 60.
However, ":" by itself has many possible uses, and I find it hard to say which are the more "natural" uses. It is often used to associate a name or label to something else. There is also the classic restricted form of this use, for type association: name:type. However, it also is useful for conditions. In the following definition of a sign function, I let it denote both the association of a parameter list with a body for an anonymous function, and for the association of conditions with values:
sgn = (x):(x>0: 1| x=0: 0| x<0: -1)
Is this too much overloading? Would (x) be mistaken for a condition instead of a (typeless) parameter list? Could this use coexist with the use for key-value maps:
s←"zot"; ("foo": 1, "bar": 2, s: 3)
Regarding named arguments, I like to think of the parameter list of a procedure as a structured type.
𝐩𝐫𝐨𝐜 foo(a int, b string, d point)
...
foo(b: "bar", 117, (0, 0))
𝐩𝐫𝐨𝐜 dist (a, b 𝐩𝐨𝐢𝐧𝐭 | a 𝐩𝐨𝐢𝐧𝐭, l 𝐥𝐢𝐧𝐞 | a 𝐩𝐨𝐢𝐧𝐭, c 𝐜𝐢𝐫𝐜𝐥𝐞) 𝐫𝐞𝐚𝐥:
𝐛𝐞𝐠𝐢𝐧
𝐢𝐟 defined(b) 𝐭𝐡𝐞𝐧 𝐫𝐞𝐭𝐮𝐫𝐧 sqrt(a.x·b.x+a.y·b.y)
𝐞𝐥𝐬𝐞 defined(l) 𝐭𝐡𝐞𝐧 ...
𝐞𝐥𝐬𝐞 defined(c) 𝐭𝐡𝐞𝐧 ...
𝐟𝐢
𝐞𝐧𝐝
...
d1 ← dist(a: p1, b: p2)
d2 ← dist(l: line(p2,p3), p1)
or
𝐩𝐫𝐨𝐜 dist (a, b 𝐩𝐨𝐢𝐧𝐭 | a 𝐩𝐨𝐢𝐧𝐭, l 𝐥𝐢𝐧𝐞 | a 𝐩𝐨𝐢𝐧𝐭, c 𝐜𝐢𝐫𝐜𝐥𝐞) 𝐫𝐞𝐚𝐥:
(defined(b): sqrt(a.x·b.x+a.y·b.y)
|defined(l): (l.a ≠ 0 ∨ l.b ≠ 0:
abs(l.a·a.x+l.b·a.y+l.c)/sqrt(l.a²+l.b²)
| l.a = 0: abs(l.b·a.y+l.c)/abs(b)
| l.b = 0: abs(l.a·a.x+l.c)/abs(a))
|defined(c): (𝐥𝐞𝐭 r = c.radius, cp = c.center;
𝐥𝐞𝐭 d = dist(a, cp);
(d < r: r-d | d > r: d-r | d = r: 0)))
or as type matching:
𝐩𝐫𝐨𝐜 dist
𝐜𝐚𝐬𝐞 a, b 𝐩𝐨𝐢𝐧𝐭: sqrt(a.x·b.x+a.y·b.y)
| a 𝐩𝐨𝐢𝐧𝐭, l 𝐥𝐢𝐧𝐞:
(l.a ≠ 0 ∨ l.b ≠ 0:
abs(l.a·a.x+l.b·a.y+l.c)/sqrt(l.a²+l.b²)
| l.a = 0: abs(l.b·a.y+l.c)/abs(b)
| l.b = 0: abs(l.a·a.x+l.c)/abs(a))
| a 𝐩𝐨𝐢𝐧𝐭, c 𝐜𝐢𝐫𝐜𝐥𝐞)𝐫𝐞𝐚𝐥: abs(dist(a, cp)-c.radius)
𝐞𝐬𝐚𝐜
all seem readable to me, even if they overload ":" quite a bit.
Using unicode always sounds like a nice idea, but that requires either an IDE for the language with common shortcuts, or it requires the Programmer to setup global keyboard macros for the specific subsection of unicode used by the language, or it requires there being ASCII equivalents to the unicode operators, in which case you gain little over, for example, a specialized font that joins together characters.
Using Unicode seems completely unproblematic to me, using vim. I am sorry if my use of it was distracting, as I was trying to make a point about the use of colon. But then again, it shows why colon is so attractive: it just does its job (demarcation of various associations of fieldnames:content, keys:value, conditions/patterns:branches) very well, while being unobtrusive to the point of being overlooked.
Thank you for this illuminating deep dive.
It was unfair of me to imply that the guys who started this convention didn't have their reasons.
Looking forward, it may become more common to use extended ascii characters in the future, as more people will be using editors that easily convert <- into ← and such.
There seems to be two "schools of thought" regarding symbols in programming languages. One wants the IDE or ligatures is special programming fonts to replace certain character sequences by others, like "<-" by "←" as you mention. The other school which may possibly be just me, wants to use the "correct" Unicode symbols whenever possible, only deferring to IDE/editor support in very rare situations. Ideally I think a source file should look correct when displayed with cat.
It is perfectly understandable that most people these days have very little knowledge of just how limited computing and programming was, just 50-60 years ago, and at the same time how advanced much of the theory about it had already become at just about the same time. The is a possibly well-known blog from a few years ago, that describes a "mystery language", comparing it with Go, and concluding they are nearly feature-equal, and then revealing the language to be Algol 68, which was defined in 1968 (and revised, mostly to give it a more format semantic definition, in 1974.) 7-bit US-ASCII was only defined in 1963, and before that character sets encompassed just upper case letters, digits and a tiny selection of symbols. ASCII, and its international variants under ISO-646 ruled computing almost up to the 90es, although ISO 8859 appeared in 1988 - based on the European ECMA-94 standard from 1985, in turn based on DEC's multinational language support with the wonderful VT220 terminal from 1983. When I first had access to the Internet in 1991, I could not reliably transmit my full name in e-mail for another two or three years. Today we have portable devices that easily support Unicode, and IMO there is no longer any excuse for not using available symbols when it makes good sense.
I feel like it's the perennial conflict between simple and easy, with simple being using the correct symbols from the entire unicode library we all have access to now. Easy is limiting ourselves to the symbols available on the standard US keyboard.
If the typical reaction to apl is any indication, modern coders are irrationally frightened by symbols that don't exist on their chromebook keyboard.
How I'm trying to break through the dichotomy is with label localization.
If you're programming in English, then equality is equals(). If you're programming in Swahili, it's sawa(). But there's also a universal "C" locale that you can place universal symbols for things in, like ==().
In addition to improving accessibility, it also allows for one to program in easy or hard mode, and get carried away with using apl style squiggles if you're feeling terse and full names of formulas (I call functions formulas) if you're feeling verbose.
Maybe I'm over engineering.
In the following definition of a sign function, I let it denote both the association of a parameter list with a body for an anonymous function, and for the association of conditions with values:
Is this too much overloading? Would (x) be mistaken for a condition instead of a (typeless) parameter list? Could this use coexist with the use for key-value maps:
They all can be the same thing by extensionality:
x: means "for a variable x,"f(x): means for "for f applied to x,"42: means "for constant 42,"(0: 0, x < 0: -1, x: 1) means "for 0, 0, or for a variable x less than 0, -1, or for a variable x, 1."At which point functions are mappings again, and both pattern-matching and key-value lists are functions.
Like in Prolog or Ting.
I would argue that the true original sin was done by never considering that really we have three things: assignment, equality and declaration.
The problem is that the assignment doesn't exist in mathematics.
When talking about constants we use symbols to represent numbers whose value we don't know (so we say c but replace it with the value we calculate when we do, as a number, when talking about G we don't know the precise value of the constant and only have a good enough approximation) or those we can't represent, only approximate (irrational numbers, I etc).
Variables instead represent something that is true for a range of values, and they are given values not by assignment, but instead by defining the context. In lambda calculus variables aren't assigned values, instead they are replaced with a value when the function is called with certain parameters.
When in math we see the term let x = 5 we need to understand it's not shorthand for let <assignment> be given for the next cases instead it should be more like let us imagine/assume <fact> is true. It's just as fair to say let x > 5 or let x % 2 = 0. In languages like LISP, PROLOG or APL which build off math directly you don't have this issue (APL uniquely because assignment is considered). But in other languages instead there was a desire to make it look like math statements, so equality constraints were repurposed as declarations, and since declarations could be best defined as naming with an initial assignment this resulted in assignment being defined as an equality constraint. It really works more like defining predictions in math though.
But maybe it's just that math has its limitations to define computations (even though we've always used math to describe how to do a computation) and this just exposed it wasn't the best language to define them.
Yes. If I am not mistaken, original BASIC specifically used (abused?) the "let"-notation for assignment: LET A=A+1. Then of course later versions of BASIC designed by other people dispensed with the LET keyword. :-)
I used to like ":=" for assignment, but I prefer to use ← now.
I sometimes wonder when the mathematical world discovered that their use of language and naming some times caused ambiguity and confusion due to inconsistent levels of abstraction. Certainly Lewis Carroll was aware of it, when he wrote about the song (called? named? name called?) "Haddocks' Eyes" in Through the Looking-Glass. :-)
Oh, two things: (neatly bringing this back to the topic as well)
When I commented above, and wondered about whether (x):(...) could be confusing, I actually was thinking of this exact problem. Without a type annotation to indicate that x here is intended as a formal parameter to an anonymous routine, it could be interpreted as either a field mapping in a structure, or as a condition variable x in an if-statement. Similarly, if using x: "foo" as a field in a struct value denotation, it could mean a field with key "x" and value "foo" - OR a field with the key being whatever x contains, and the value "foo".
The symbol level confusion was definitely not very well understood in 1960 - as I understand it, they were trying to add call by reference, but instead invented call by name. People like Christopher Strachey tried to "fix" this, by introducing r-values and l-values, thereby introducing new problems. Van Wijngaarden's solution was a lot more consistent with its introduction of the generalised ref mode.
How'd you get Reddit to format your code with those nice bold keywords?
PS: I believe a programming language should contain only symbols that it's completely obvious how to type them, even if you're unfamiliar with the programming language. I realize that international keyboards vary, but ... for example my Korean keyboard is basically a US 104-key with a couple extra keys.
It's called Unicode Mathematical Alphanumeric Symbols Block. Very nice - and also lends itself to wildly excessive abuse, if one is disposed to such things.
I have made it relatively easy for myself after writing my first vim script. I just pushed it to Github for your possible amusement. (If you use vim.)
Cut/Paste to Reddit works - badly. A little better when not using "fancypants", which is a shame as I like proper styled editing. (How a site can continue to have such an abysmal post/comment editor for so long and not do anything about it really boggles the mind.)
Unicode Mathematical Alphanumeric Symbols Block
Tables of styled letters and digits... Clever, but this sort of thing far exceeds Unicode's mission to represent all the world's languages. Let me go further: it runs directly counter to their own professed guiding principle. An "a" is an "a" whether it be serif, sans, italic, or black-letter. It's an "a" whether narrow or wide, plain or bold or oblique or both. It's still an "a" whether underlined, overlined, struck through once or twice, superscript, subscript, or upside flipping down. It's code-point 97 in every case, with style applied after the fact in the presentation layer.
And then the Unicode consortium comes along and does this. Note the holes in the tables. There are just random letters missing from some sequences.
The holes are not missing letters. They are intentionally left empty,because the corresponding letter had already been defined in some earlier version. And whether a bold A is the same as a non-bold A. Sure, in text, meaning sentences and words from a natural language, there is not a very large semantic difference between plain type and for example italic type. Although there are cases where the use of a different style has semantic meaning (example included in the sentence.)
However, in mathematics, and also in programming languages, although this has gone unnoticed because the languages in question were used at a time where all-uppercase was the norm anyway, different styles and different languages frequently are used to carry a lot of meaning. Vectors in textbooks on algebra are printed in boldface. Matrices are printed as uppercase boldface. In locally produced textbooks and kompendiums back in the 70es and 80es, at least as the university I attended in 1987, due to the text being photographic reproductions of typed pages, vectors were indicated with an arrow overbar. Which is arguably another "styling".
I also seem to recall that there was some upheaval or controversy in the earlier history of Unicode, about whether certain Asian languages' symbols - all derived from the Chinese writing system, but since evolved with varying visual characteristics, for example in Japanese - which was considered by the Unicode Consortium at the time as stylistic variation, resulting in one symbol being picked to represent for example both Chinese and Japanese variants of that symbol.
al numbers, ℚ, real numbers ℝ, and complex numbers ℂ, possibly a few more. Now, I think that already at that point someone should have had the thought that maybe it would be smart to add all letters in this style. They didn't. There is also a historical aspect: For a long time, various computer manufacturers defined their own "extended ASCII variants or Code Pages". Greek letters like π and µ existed in some of them; the Macintosh had both, and also ff, fi, and oe ligatures, IBM had others, and so did Microsoft. In 1993, I created a mapping from ISO-8859-1 to/from the Western European variant of MacRoman, to be used with the widely popular Eudora mail program, and the NewWatcher 1.3 NNTP newsreader. (I sent my mappings to Steve Dorner, but he chose to use a mapping that was slightly different iirc.) MIME was just about the break through, and the WWW had only just been invented. You may recall that HTML used SGML entities for character names; again, iirc, some Danish standards people were very annoyed that the name for our letter Æ/æ was demoted to be a "ligature": Aelig/aelig. Historically it may be, but it is considered a unique and proper letter in the Danish alphabet, not a typographical nicety. Note that the Unicode name for the letter is LATIN CAPITAL LETTER AE and LATIN SMALL LETTER AE.
I understand that part of Unicode's early "mission statement" was also to reconcile many kinds of code pages that had been in use, so fx "℃" exists as a codepoint (U+2103), even if the degree symbol "°" existed in Latin1, and we will typically write "degrees Celsius" as "°C" (two codepoints: °: U+00B0 and C: U+0043.) This is because it was a single symbol in some Chinese or Japanese character set, I think. (And to be fair, there is a decomposition rule for it.) Things like this are also the cause of different codepoints that are visually indistinguishable and which has turned out to be a security issue when Unicode was allowed using Punycode in DNS names.
So I think it is fair to say, that the "guiding principle" you mention, has more or less been abandoned due to pragmatic (and probably also political) needs. I do believe that Unicode will stick to one principle "forever": that being that when a symbol has once been introduced, it remains there, even if it means that there are things that need to bend a bit to make everything work. The holes in doublestruck/blackboard bold being one such example. (Another is the hole in Mathematical Script uppercase p, which was first entered as the Weierstrass Symbol.)
When the Algol language was designed, it was deliberately designed so that the letters constituting keywords and letters constituting identifiers were considered different: in typeset text this was achieved with boldface or underlined keywords. The language was carefully designed so that identifiers were never juxtaposed, which in turn meant that identifiers could contain (ignored) whitespace. With Algol 68, van Wijngaarden took this to another level, with userdefined modes (types) also using bold letters. This is why we got the infamous lexer problem in C, when typedefs were added to the language!
So now Unicode has sets of boldface, italic, fraktur, script etc letters, and I'll be damned if I would let anyone prevent me from using this fact as I please. Sure, it may not be the perfect solution, and maybe one day some bright person gets an idea that "solves" whatever problems this could cause and convinces Unicode Consortium to use it. There are so many oddities and irregularities already in Unicode that need to be looked at (like why arent there a full set of super- and subscripts, and why do some fonts apparently implement them in a way that they are better suited for fractions than for super/subscripts?), but these days I almost get the impression that they are much to busy to add politically correct smileys and emojis to the standard, to take care of such trivialities. At least the have added the "⏨" subscript, originally designed by the Algol 60 committee I believe, for scientific number notation (1.2⏨3 being 1.2·10³ or in most languages 1.2E3 or 1.2e3.)
Using different styles as distinct symbols, in addition to solving the C lexer problem with types, also could solve the problem the C standards committee is having when needing to introduce new keywords at this point in C's lifecycle. Because people may have used words like true, false, bool, generic, and whatever as identifiers in their code, these words could not be added willynilly as reserved keywords; instead needing to be gradually introduced by way of "odd reserved spelling" like _Bool, _Generic, and header files with macros redefining them to their final form for people who would prefer using that.
I have much respect and gratitude for the work done by the Unicode Consortium, and it must be hell sometimes, but once something is in Unicode, it is there to be used, in my opinion.
And now I am tempted to find some fitting Unicode symbols for comic strip style cursing, as it seems that when Fancypants started acting up and I switched to Markdown, my comment was garbled in some places. I hope the meaning is still somewhat clear (It is when I talk about how blackboard bold was added piecemeal at first to Unicode), but I may eventually get back to it and fix it up. Right now I am just too pissed off by that *¤FF#&%¤& POS "editor" to do so.
Ah, yes. The classic problem of the installed base. On that front I agree: Once something makes it into the Unicode standard, it's easier to shut down a government program than pull it back out again.
I take no issue with your choice to exploit all that Unicode has to offer. I just think the Unicode Consortium has lost its way, and did so many editions ago.
Several Cyrillic letters look confusingly similar to Latin or Greek letters. Nevertheless, when in Cyrillic text, they are arguably different entities from their visual-twins in historically-distinct alphabets. The H-looking thing in Latin, Greek, and Cyrillic all deserve their own code-points colocated with the rest of their alphabets. But on that basis Klingon has a better claim to a code-block than does black-letter. There are marked differences in orthography between Taiwan and Seoul so the J-K versions certainly deserve distinct blocks of code-points. (Beijing and Taipei will have to wait for the Ministry of Truth to rule.)
The Danes are not alone. Typists took to spelling ß as "ss" because typewriters didn't have the former. The Spanish "Ch" is similar, but less trouble because it does not have a corresponding typographical nicety. Different languages may collate the same alphabet differently but they can at least agree on what the alphabet is -- mostly. French and Vietnamese are ... interesting cases.
Historical curiosity: The Soviet copies of some programming languages allow the Cyrillic letter ю to stand in for the e in scientific notation.
IIrc, C# also use ':' for passing named arguments.
What's the decision process here?
There is no process. Each language designer chose they own implementation.
Personally I like : because using = leads to requiring == and even === which I see as being horrendous.
Of course there is also := which seems like an extra key to type for no good reason.
[deleted]
Could you elaborate on this? Saying something "is a bad idea for many different reasons", and then not providing even just a single example of these reasons, is a bit on the unhelpful side.
Using ”:” was actually the original syntax in GCC for its designated initializers (obsolete since 2.5)
[deleted]
LuciferK9 [OP] 4 points · Aug 2023
I see, thanks! I was overthinking it by wondering if I was missing something like parsing ambiguities on edge cases, etc.
[deleted] 1 points · Aug 2023
[deleted]
oscarryz 2 points · Aug 2023 · Yz
What's GP? Why is that not a matter of taste?
mus1Kk 4 points · Aug 2023
GP is grandparent. From the perspective of the writer, the GP is the post two levels up (like parent post being one level up).