Adding language motivation document by lnsolar · Pull Request #649 · microsoft/verona

lnsolar · 2023-12-06T13:13:05Z

Okay, so I added a first draft of an attempt at summarizing the verona language. At the moment it mostly contains parts which I have already talked about with some of you in the weekly type system meetings. It would be great if you have a read through and comment here.

lnsolar · 2023-12-06T13:15:18Z

Some things i need to do

Make sure syntax is correct in code examples
Add comparisons with other languages

davidchisnall · 2023-12-06T16:39:29Z

It would be nice to start such a document talking about the two key differentiating features of the language: region-based ownership and behaviour-oriented concurrency. I worry that someone coming to the language and seeing this would not see what makes Verona interesting.

lnsolar · 2023-12-07T14:37:37Z

@microsoft-github-policy-service agree

lnsolar · 2023-12-07T14:40:39Z

It would be nice to start such a document talking about the two key differentiating features of the language: region-based ownership and behaviour-oriented concurrency. I worry that someone coming to the language and seeing this would not see what makes Verona interesting.

I agree. I think we aimed to explain the main features of the type system, with less focus on capabilities, regions and BoC. I could try to add parts about these as well, or perhaps change the introduction to more clearly state what the document is supposed to be.

docs/motivation.md

EliasC

This is a really useful document to have! I have added some comments and questions, and also opened a pull request with spelling fixes.

EliasC · 2023-12-09T20:19:05Z

docs/motivation.md

+In Verona, a trait with multiple methods can be further simplified by breaking
+up each method into what we call an "atomic" trait and combining them with a
+conjunction. E.g. the definition of `Number` above is simply syntactic sugar for
+```verona
+type Number = {
+    add(self: Self, other: Number): Number
+} & {
+    sub(self: Self, other: Number): Number
+}
+```


Is this important for a language motivation, or is it an effect of how we formalise things? Maybe it actually helps with intuition for things.

It probably doesn't make much difference to most people. On the other hand, I don't think it hurts to mention it?

I think it might even help with the intuition for &, reading it again now. But maybe it should be more of a note than a proposed simplification (I would argue that it is less simple to compose atomic traits than to write a composite trait).

yeah, i agree, i'll see if i have time to write something before the meeting

"syntactic sugar" ==> "can also be understood as"

I think our readers do not care about syntactic sugar.

docs/motivation.md

EliasC · 2023-12-10T06:17:42Z

docs/motivation.md

+###### External trait inheritance
+A possibility is to allow externally declared trait inheritance, i.e.
+declaration of trait inheritance can be separated from class definition.
+```verona
+// file 1
+
+// class C definition
+class C {
+    toString(s: C) : String
+    ...
+}
+
+// file 2
+// declaration that C implements Printable together with its default method
+class C : Printable
+```


Should we group hypothetical features in a section of their own? Or maybe mark these headings as hypothetical (or "in flux" or something else that makes sense)?

Compared to the previous example, it is the ToString trait that implements print.

probably, we should discuss where we should put this

EliasC · 2023-12-10T13:29:47Z

docs/motivation.md

+  ```verona
+    type A[T] = {
+        type Self
+        type Anon = {
+            type Self
+            g(self: A[T].Anon.Self) : A[T].Anon.Self
+        }
+        f(self: A[T].Self) : A[T].Anon
+    }
+  ```


Is local types a thing? Looks like Scala's path-dependent types. I think the desugaring would hold even if Anon was a top-level trait.

I think this desugaring is wrong, since self is basically an implicit type parameter

docs/motivation.md

EliasC · 2023-12-10T14:33:23Z

docs/motivation.md

+Note that type constraints such as `N <: GNode[E]` and `E <: GEdge[N]` are part
+of the syntax for types, so we can combine them using conjunctions and
+disjunctions as in the definition of `Graph[N, E]`.


This makes me think if I should really parse a method with a where clause as the where belonging to the return type, i.e. the difference between

print(self: Self) : Unit where (T <: Printable)

and

print(self: Self) : (Unit where (T <: Printable))

Perhaps the syntax should be

print(self: Self) where T <: Printable : Unit

Though typing that I don't like it either. Then I thought:

print where T <: Printable(self: Self): Unit

which I like even less. So I think we need good syntax highlighting!

T is free in the above. IS that on purpose? If it was not, perhaps the problem would not arise?

docs/motivation.md

EliasC · 2023-12-10T15:00:52Z

docs/motivation.md

+type Printable = {
+    print(s: Self) : Unit // this will have to be defined if Self </: ToString
+    print(s: Self) : Unit where (Self <: ToString) {
+        sys.io.out(s.toString())
+    }
+}


Is there always a most specific constraint? There is a parallel to pattern matching where you can have a matching order that does not depend on the order that cases are written, but on their specificity, and then you need to look out for patterns that cannot be ordered, e.g., the patterns for tuples of lists (nil, l2) and (l1, nil). I wonder if a similar problem can appear here.

don't know, we should discuss later

docs/motivation.md

mjp41 · 2023-12-20T15:29:40Z

docs/motivation.md

+Note that type constraints such as `N <: GNode[E]` and `E <: GEdge[N]` are part
+of the syntax for types, so we can combine them using conjunctions and
+disjunctions as in the definition of `Graph[N, E]`.


Perhaps the syntax should be

print(self: Self) where T <: Printable : Unit

Though typing that I don't like it either. Then I thought:

print where T <: Printable(self: Self): Unit

which I like even less. So I think we need good syntax highlighting!

docs/motivation.md

mjp41 · 2024-03-01T10:07:50Z

@viewedlobster do you think you will be able to make the requested changes?

Spelling and language

TobiasWrigstad · 2024-03-19T15:08:29Z

docs/motivation.md

+
+## Structural type system
+
+A type system is all about managing a complexity budget. Make it too complicated


Nitpick: I'm not sure it is all about this! But I morally agree :)

But this is important. We need to avoid such phrases. Perhaps: "one aspect of a type system is".

haha, yeah, wrote that in a heated moment 😓

davidchisnall · 2024-03-19T15:10:19Z

docs/motivation.md

+// TODO add ToStringNumber version
+```
+
+In contrast, in a nominal system like Java, we would have to define a new


The Java equivalent of this is Object<Number, ToString>.

I didn't know that, which version of Java added that?

Well, technically, Objective-C 4 (I think, might have been 3), but Java inherited it from there.

matajoh · 2024-03-19T15:18:30Z

docs/motivation.md

+Verona. One between classes and one between class and trait.
+
+##### Class inheritance
+Inheritance between classes works as you would expect in a language like


It is not clear from the document (at this stage) whether you allow multiple inheritance. Is this the purpose of "language like Java" here?

Inheritance, perhaps use "reuse"?

Make clear that you can reuse code from multiple traits and classes.

nwf-msr · 2024-03-19T15:18:47Z

docs/motivation.md

+// here we reuse functionality of C in D, specifically the method f, but
+// we do not get a subtyping relation D <: C
+class D : C {
+    equal(self: D, other: D): Bool {...}


What would have happened if D hadn't redefined equal like this? Would it have picked up an equal : (C,C) -> Bool that then could be called with :: as in D::equal(c1,c2) but not via ., since D </: C?

Yes. Caveat: mentioning your own type could also be treated as Self, so that D got equal: (Self, Self)->Bool, that needs discussion (it may be that such a trick leads to too many type errors in the body of the function).

More generally: I think we should favor the term "code reuse" instead of "inheritance".

matajoh · 2024-03-19T15:19:50Z

docs/motivation.md

+
+#### Self types
+In Verona, the Self type represents the concrete type of which the object is
+part. When defining class types, Self mereley acts as an alias for the


typo 'mereley'

matajoh · 2024-03-19T15:22:14Z

docs/motivation.md

+```
+
+By extension this means that polymorphism in Verona doesn't need special
+handling of capabilities in type parameters. A type `A[T]` parameterized on `T`


Might need the introduction of this notation to be a bit more gentle.

Square bracket notation - language spec to cover. Probably should say a bit more here.

mjp41 · 2024-03-19T15:08:28Z

docs/motivation.md

+This document aims to cover the parts of the type system that are similar to (though in some places diverge in interesting ways from) other languages.
+
+Verona is an object oriented reference capability language with structural
+subtyping and bounded polymorphism. This document aims to describe the aspects


Not sure that bounded polymorphism is the right phrase here.

Predicated polymorphism.

mjp41 · 2024-03-19T15:09:22Z

docs/motivation.md

+and programmers will find it difficult to use and be less productive. Make it too
+simple and it will give you less guarantees to lean on as a programmer.
+
+We opt to use a structural type system since we beleive it simplifies some parts


Suggested change

We opt to use a structural type system since we beleive it simplifies some parts

We opt to use a structural type system since we believe it simplifies some parts

mjp41 · 2024-03-19T15:12:38Z

docs/motivation.md

+```
+A type describing numbers implementing addition and subtraction can be described with
+```verona
+type Number = {


I wonder if Number should have a carrier for the type of Number. E.g. Number[T]

mjp41 · 2024-03-19T15:16:48Z

docs/motivation.md

+type s = A of int
+         B of int


Suggested change

type s = A of int

B of int

type s = A of int

| B of int

mjp41 · 2024-03-19T15:20:00Z

docs/motivation.md

+
+#### Self types
+In Verona, the Self type represents the concrete type of which the object is
+part. When defining class types, Self mereley acts as an alias for the


Suggested change

part. When defining class types, Self mereley acts as an alias for the

part. When defining class types, Self merely acts as an alias for the

mjp41 · 2024-03-19T15:23:28Z

docs/motivation.md

+type Equal[V] = {
+    equals(v1: V, v2: V) : Bool
+}


Equals not used here? Delay to next bit?

mjp41 · 2024-03-19T15:24:48Z

docs/motivation.md

+searchGraph[V, N, E](n : N, v : V) : Option[N]
+    where ValueGraph[V, N, E] & (V <: Equal[V]) & (N <: Comparable[N])
+{


This is method level where.

matajoh · 2024-03-19T15:27:34Z

docs/motivation.md

+```
+
+### Type predicates
+Type predicates allow us to describe assumptions about subtyping. These can be


I think for most readers the distinction between subtyping here and what we say above (i.e. " inheritance
subtyping. This means that there is never any subtyping between two distinct classes.") may be lost, i.e. they would react with "but I thought there was no subtyping in this language". Maybe it is just me, but it seems a bit confusing.

Yes, I think this is important. We can avoid the word "inheritance" entirely. For describing predicates, I think we'll need to try several times :) We're looking for the "simplest possible" language - with no metric for what that is!

matajoh · 2024-03-19T15:28:35Z

docs/motivation.md

@@ -0,0 +1,553 @@
+# The Verona language: Core type system
+
+Verona is a language with a behaviour-oriented concurrency model and a region abstraction for ownership.


General question: who is the audience for this? And what do we want the effect of reading this document to be on them?

Add a section on the audience, expectation of the understanding the reader will get, and purpose of the document.

Newspaper style... important first, and less important as you go.

Tree of documents versus newspaper style? To be decided

sophiaIC · 2024-03-19T15:32:31Z

docs/motivation.md

@@ -0,0 +1,532 @@
+# The Verona language: Features and Motivation 
+
+Verona is an object oriented reference capability language with structural


I think here we should also say which parts of the type system are novel, and which are more standard.

The capabilities part seems to me not to be fully explained here. Is that so? Is that on purpose? Should there be a reference to OOPSLA?

Combine with https://github.com/microsoft/verona/pull/649/files#r1530615303

Novelty should be part of the top level description.

sylvanc · 2024-03-19T15:11:32Z

docs/motivation.md

+
+## Structural type system
+
+A type system is all about managing a complexity budget. Make it too complicated


But this is important. We need to avoid such phrases. Perhaps: "one aspect of a type system is".

sylvanc · 2024-03-19T15:12:25Z

docs/motivation.md

+
+A type system is all about managing a complexity budget. Make it too complicated
+and programmers will find it difficult to use and be less productive. Make it too
+simple and it will give you less guarantees to lean on as a programmer.


Similarly, we're provoking argument with an implicit productivity claim. For this to be effective, we need to back up the claim. Also s/less/fewer/.

Evidence on productivity? Jan Vitek paper about productivity citation. We approximate dynamic programming through the really cool typesystem.

https://dl.acm.org/doi/10.1145/3340571

https://dl.acm.org/doi/10.1145/2635868.2635922

sylvanc · 2024-03-19T15:13:35Z

docs/motivation.md

+simple and it will give you less guarantees to lean on as a programmer.
+
+We opt to use a structural type system since we beleive it simplifies some parts
+of reasoning, e.g. we don't need co/contra-variance notation on type parameters.


Let's avoid the word "believe". The more concrete claim is that we are eliminating type hierarchies and improving extension (classes may be subtypes of structural types that are added later).

Changing structure to address this.

sylvanc · 2024-03-19T15:16:39Z

docs/motivation.md

+
+We do however treat classes nominally and have opted to not have inheritance
+subtyping. This means that there is never any subtyping between two distinct
+classes.


I would prefer to avoid the word "opted", and state our concete motivations. In this case, we are distinguishing classes from types - a class is a closed binary layout.

We also need to highlight early on here that the type system is both structural and algebraic, allowing both "open world" and "closed world" subtyping, in both cases without hierarchies.

Class is an implicit final type, but more importantly a fixed binary layout.

Structural types are open world types.

sylvanc · 2024-03-19T15:18:56Z

docs/motivation.md

+
+### Traits
+Verona is a structural type system based on traits, i.e. types can be described
+using combination of methods on an object. E.g. we can describe a type


This is so minor, but: "e.g." is "for example" in Latin, requires a comma after it, and is bad form to use at the beginning of a sentence. Here it can be "object, e.g., we". "i.e." is "inter alia" and also requires a comma. Using both in the same sentence is an indicator that you probably had an entirely different structure in mind and you might want to rewrite :)

Is the comma issue a British vs. American English thing? I agree on not starting a sentence with either though.

I think I would put comma's in like Sylvan says, e.g., like in this sentence.
But mostly, I use

"for example" instead of "e.g."

and

"that is" instead of "i.e."

sylvanc · 2024-03-19T15:35:30Z

docs/motivation.md

+Note that `g` cannot have a more refined type than `t -> s`.
+
+#### Type discrimination
+In ML we might want to construct a type such as


Don't introduce ML when trying to explain Verona. Instead, discuss open and closed world types, without reference to other languages.

Define first, and compare second.

Perhaps want language comparison docs for each similar language.

X-lang for Y programmers docs - often negative signposting.. e.g., common misunderstandings.

sylvanc · 2024-03-19T15:36:48Z

docs/motivation.md

+```
+but it is now impossible to discriminate between the two cases. This is however
+easily fixed by defining `S` instead as
+```verona


This is really about defining data types. There's no need to address discriminated vs. anonymous unions here - that's for a language comparison doc.

https://github.com/microsoft/verona/pull/649/files#r1530627703

sylvanc · 2024-03-19T15:37:49Z

docs/motivation.md

+```
+
+#### Explicit nullability
+We can easily encode nullability with a class `None`


This is not "Null". A null is a value that can inhabit many types. Instead, this can be addressed as "verona uses algebraic types to express options and absence".

Precision of Null versus option types.

sylvanc · 2024-03-19T15:38:43Z

docs/motivation.md

+```
+
+### Subtyping and inheritance
+Verona is an object-oriented system with classes and traits. When it comes to


This isn't quite right. We can remove the use of "nominal" everywhere. Classes are concrete, traits are structural (there's no nominal type relationship).

Nominal comes with baggage from nominal subtyping, so avoid the baggage.

Open and close world types discussion too

sylvanc · 2024-03-19T15:39:49Z

docs/motivation.md

+Verona is an object-oriented system with classes and traits. When it comes to
+subtyping, classes are treated nominally, and traits are treated structurally.
+Furthermore there is no subtyping between classes. This means a class
+can be a subtype of a trait, but never a subtype of a class other than itself.


This can be covered early in a Structural section. Introduce Eq separately in a section that shows how to build useful structural primitives, and covers F-bound polymorphism and Self types.

sylvanc · 2024-03-20T14:31:12Z

docs/motivation.md

+    equal(self: D, other: D): Bool {...}
+    g(...): ... { ... f(...) ... }
+}
+// TODO: find a realistic example


Meta comment: we don't need realistic examples. In fact, they can be actively harmful. Examples of languages to emulate for language docs and language specs include: Go, Rust, C#, and to some degree TypeScript (that one is problematic as it spends a lot of time referencing JavaScript).

Realism versus teaching. Need to teach

sylvanc · 2024-03-20T14:32:11Z

docs/motivation.md

+
+There is a case to be made for not allowing inheritance from a
+  class, since this allows unanticipated code reuse. This might however also be
+  a positive.


This can be removed. Language docs aren't the right place to have design discussions.

Third type of doc... Design decisions. Neither Spec nor motivation.

sylvanc · 2024-03-20T14:33:37Z

docs/motivation.md

+// TODO: find a realistic example
+```
+If we want to describe a relation between `C` and `D`, we can only do so by
+subtyping them under a trait.


This isn't quite right. There may exist many relationships between C and D, based purely on structural commonality. There's no need to write a trait for such commonality to exist - this is a key point in structural subtyping.

sylvanc · 2024-03-20T14:35:09Z

docs/motivation.md

+Here, the definition `ToString` contains a default implementation for the print
+method.
+
+* Question: Should traits be allowed to define default fields?


They already can. Also, questions are for other docs :)

Should be addressed by the language spec.

sylvanc · 2024-03-20T14:36:16Z

docs/motivation.md

+###### External trait inheritance
+A possibility is to allow externally declared trait inheritance, i.e.
+declaration of trait inheritance can be separated from class definition.
+```verona


I don't understand what this means, or what the example is illustrating. Questions and design discussions are great! Let's move them to a different doc.

sylvanc · 2024-03-20T14:41:23Z

docs/motivation.md

+
+
+## Dynamic and static dispatch
+Method calls can be dynamically or statically dispatched based on the type of


I think it's too early to try to give optimization tips. Perhaps the interesting thing to cover here is call syntax?

sylvanc · 2024-03-20T14:44:47Z

docs/motivation.md

+written on both type and method level, and both has their distinct uses.
+Specifically, predicates on both type and method level allow us to express
+F-bounded polymorphism, while method level predicates are further useful in
+reducing code duplication, somewhat akin to type classes.


Calling out "what something isn't" leads to confusion. Either the audience doesn't have that context, or worse yet, has it - and makes unfounded additional assumptions! Go/Rust/C# docs are very good at explaining without reference to other languages or out-of-language terminology.

TobiasWrigstad · 2024-03-19T15:09:30Z

docs/motivation.md

+capabilities to enforce isolation and region topology.
+
+We do however treat classes nominally and have opted to not have inheritance
+subtyping. This means that there is never any subtyping between two distinct


Do we even have inheritance?

This was answered below so now my question is why and is it multiple?

TobiasWrigstad · 2024-03-19T15:10:12Z

docs/motivation.md

+classes.
+
+### Traits
+Verona is a structural type system based on traits, i.e. types can be described


Nit: has not is

TobiasWrigstad · 2024-03-19T15:12:32Z

docs/motivation.md

+
+#### Capabilities and conjunction
+In Verona, each concrete type is tagged with a *reference capability*. The reference
+capability decides which operations are permitted through and with a reference


Some broken language here

TobiasWrigstad · 2024-03-19T15:14:15Z

docs/motivation.md

+Verona also includes disjunction types. Assuming two types `C` and `D` we can
+define the new type
+```verona
+type COrD = C | D


Described as C and D above but now C or D

TobiasWrigstad · 2024-03-19T15:15:44Z

docs/motivation.md

+
+Since in Verona there is no subtyping between classes, we are able to check that
+a pattern match is exhaustive, and furthermore matching on concrete types will
+allow us to do implicit type filtering over match cases. E.g. imagine a case


I am not 100% sure what "implicit type filtering over match cases" means

TobiasWrigstad · 2024-03-19T15:27:47Z

docs/motivation.md

+type Eq
+type ToString
+
+class HashMap[K, T] where (K <: Hashable & Eq) { // type level where clause


Meaning of <: not described yet?

Do we parse K <: Hashable & Eq as K <: (Hashable & Eq) or (K <: Hashable) & Eq? :)

TobiasWrigstad · 2024-03-19T15:31:26Z

docs/motivation.md

+        if (!visited.contains(next)) {
+            visited.add(next);
+            if (next.val().equals(v)) {
+                Some(next)


Should there be a return here?

TobiasWrigstad · 2024-03-19T15:33:04Z

docs/motivation.md

+    set(self : Self, k : K, v : T) : T { ... }
+}
+```
+In a system without method-level `where` clauses, we would need to bifurcate each


TobiasWrigstad · 2024-03-19T15:51:20Z

docs/motivation.md

+
+A type system is all about managing a complexity budget. Make it too complicated
+and programmers will find it difficult to use and be less productive. Make it too
+simple and it will give you less guarantees to lean on as a programmer.


https://dl.acm.org/doi/10.1145/3340571

TobiasWrigstad · 2024-03-19T15:52:00Z

docs/motivation.md

+
+A type system is all about managing a complexity budget. Make it too complicated
+and programmers will find it difficult to use and be less productive. Make it too
+simple and it will give you less guarantees to lean on as a programmer.


https://dl.acm.org/doi/10.1145/2635868.2635922

Adding language motivation document

e876662

todo

32a5fe8

davidchisnall reviewed Dec 7, 2023

View reviewed changes

docs/motivation.md Show resolved Hide resolved

Spelling and language

5de175a

EliasC reviewed Dec 10, 2023

View reviewed changes

mjp41 requested changes Dec 21, 2023

View reviewed changes

lnsolar added 2 commits March 19, 2024 00:38

Merge pull request #1 from EliasC/language-motivation-document

389f32e

Spelling and language

Requested changes

cde7b0c

TobiasWrigstad reviewed Mar 19, 2024

View reviewed changes

davidchisnall reviewed Mar 19, 2024

View reviewed changes

fixed some minor things

6bf04a1

matajoh reviewed Mar 19, 2024

View reviewed changes

nwf-msr reviewed Mar 19, 2024

View reviewed changes

matajoh reviewed Mar 19, 2024

View reviewed changes

mjp41 reviewed Mar 19, 2024

View reviewed changes

matajoh reviewed Mar 19, 2024

View reviewed changes

sophiaIC reviewed Mar 19, 2024

View reviewed changes

sylvanc requested changes Mar 19, 2024

View reviewed changes

sylvanc reviewed Mar 20, 2024

View reviewed changes

TobiasWrigstad reviewed Mar 20, 2024

View reviewed changes

lnsolar marked this pull request as draft March 27, 2024 15:08


		## Structural type system

		A type system is all about managing a complexity budget. Make it too complicated

	We opt to use a structural type system since we beleive it simplifies some parts
	We opt to use a structural type system since we believe it simplifies some parts

	part. When defining class types, Self mereley acts as an alias for the
	part. When defining class types, Self merely acts as an alias for the

		@@ -0,0 +1,553 @@
		# The Verona language: Core type system

		Verona is a language with a behaviour-oriented concurrency model and a region abstraction for ownership.

		@@ -0,0 +1,532 @@
		# The Verona language: Features and Motivation

		Verona is an object oriented reference capability language with structural



		## Dynamic and static dispatch
		Method calls can be dynamically or statically dispatched based on the type of

Conversation

lnsolar commented Dec 6, 2023

Uh oh!

lnsolar commented Dec 6, 2023

Uh oh!

davidchisnall commented Dec 6, 2023

Uh oh!

lnsolar commented Dec 7, 2023

Uh oh!

lnsolar commented Dec 7, 2023

Uh oh!

Uh oh!

EliasC left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

mjp41 commented Mar 1, 2024

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mjp41 Mar 20, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mjp41 Mar 20, 2024 •

edited

Loading