<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body dir="auto">
Then program in golang. It gives you just that
<div><br>
<br>
<div dir="ltr">Sent from my iPhone</div>
<div dir="ltr"><br>
<blockquote type="cite">On 9 May 2021, at 09:51, Jay K <jayk123@hotmail.com> wrote:<br>
<br>
</blockquote>
</div>
<blockquote type="cite">
<div dir="ltr">
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
I am not suggesting remove anything.</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Interfaces/modules must retain their existing features. Global variables, etc.</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
But I'd like types to gain features. Specifically as I said: I should not <span style="background-color:rgb(255, 255, 255);display:inline !important">
have<span> </span></span>to heap allocate state in order to say state.function() nor should state.function() require a function pointer (or vtable pointer). Nor would I like to say state.function(state).</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Is that too much to ask?</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
 - Jay</div>
<div>
<div id="appendonsend"></div>
<div style="font-family:Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>From:</b> Dirk Muysers <dmuysers@hotmail.com><br>
<b>Sent:</b> Sunday, May 9, 2021 7:45 AM<br>
<b>To:</b> Jay K <jayk123@hotmail.com>; Mika Nystrom <mika@alum.mit.edu>; m3devel@elegosoft.com <m3devel@elegosoft.com><br>
<b>Subject:</b> Re: [M3devel] language evolution?</font>
<div> </div>
</div>
<div>
<div id="x___MailbirdStyleContent" dir="ltr" style="font-size:10pt; font-family:Arial; color:#000000; text-align:left">
Do you want to destroy the language?<br>
<div class="x_mb_sig"></div>
<blockquote class="x_history_container" type="cite" style="border-left-style:solid; border-width:1px; margin-top:20px; margin-left:0px; padding-left:10px">
<p style="color:#AAAAAA; margin-top:10px">On 09/05/2021 09:42:25, Jay K <jayk123@hotmail.com> wrote:</p>
<div style="font-family:Arial,Helvetica,sans-serif">
<div style="font-family:Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
Also I must point out something, in my way of thinking.
<div><br>
</div>
<div>I think more programming should be type-based, not module- or subsystem- based.</div>
<div><br>
</div>
<div>Interfaces should be primarily containers of types, and types containers of state and associated functions.</div>
<div>(at least syntactically; types need not contain function pointers, just</div>
<div>that static function dispatch should be driven by the types of parameters</div>
<div>esp. the first parameter).</div>
<div><br>
</div>
<div>Interfaces should not directly contain many functions.</div>
<div>Just like interfaces should not directly contain many variables -- global variables.</div>
<div><br>
</div>
<div>So types need more powers and less restriction.</div>
<div><br>
</div>
<div>I want to more often say:</div>
<div><br>
</div>
<div>state.function()</div>
<div><br>
</div>
<div>and not</div>
<div><br>
</div>
<div>Interface.function(state)</div>
<div><br>
</div>
<div>(and esp. not state.functions.function(state))</div>
<div><br>
</div>
<div>Even if not all programming can/should be type-based, there should at least be plenty of linguistic power for such programming.</div>
<div><br>
</div>
- Jay<br>
</div>
<div>
<div id="x_appendonsend"></div>
<div style="font-family:Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_divRplyFwdMsg" dir="ltr"><span style="font-family:Calibri,sans-serif; color:#000000"><b>From:</b> M3devel <m3devel-bounces@elegosoft.com> on behalf of Jay K <jayk123@hotmail.com><br>
<b>Sent:</b> Sunday, May 9, 2021 3:28 AM<br>
<b>To:</b> Mika Nystrom <mika@alum.mit.edu>; m3devel <m3devel@elegosoft.com><br>
<b>Subject:</b> Re: [M3devel] language evolution?</span>
<div> </div>
</div>
<div dir="ltr">
<div style="font-family:Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
I admit I do not understand the brand feature.
<div><br>
</div>
<div>I have never seen it elsewhere and I do not know how it translates to C or C++.</div>
<div>The language definition is generally too high level for me to understand.</div>
<div>I always think in terms of how things translate to C, which is then</div>
<div>easily translated to assembly. C++ trivially translates to C. Modula-3 almost</div>
<div>does too.</div>
<div><br>
</div>
<div>In C and C++, names determine type identity, so:</div>
<div><br>
</div>
<div>struct Age</div>
<div>{</div>
<div> int value;</div>
<div>};</div>
<div><br>
</div>
<div>struct Distance</div>
<div>{</div>
<div> int value;</div>
<div>};</div>
<div><br>
</div>
<div><br>
</div>
<div>are different types. No brand is needed. No structural hashing occurs.</div>
<div><br>
</div>
<div>Granted, typedefs are transparent, so:</div>
<div>typedef int Distance;</div>
<div>typedef int Age;</div>
<div><br>
</div>
<div>is not so "strong".</div>
<div><br>
</div>
<div>I know the Modula-3 designers debated this and I should reread that chapter.</div>
<div>I often wonder if the solution should not be somehow both.</div>
<div>We could use name + hash.</div>
<div>If you ignore pickles, or at least pickles surviving type renames while retaining structure (Foo => Foov1),</div>
<div>and you can afford to store and compare variably lengthed strings, I think this works and wins.</div>
<div><br>
</div>
<div>Regarding indirection of objects, the problem is the heap allocation and garbage collector pressure.</div>
<div>Not the indirection.</div>
<div><br>
</div>
<div>In C++ we can do something like:</div>
<div><br>
</div>
<div>Type xstorage; // static or automatic</div>
<div>Type* x = &xstorage; // unify with all pointer-wanting code</div>
<div><br>
</div>
<div>and then just use x.</div>
<div><br>
</div>
<div>I kinda think objects should be "var", not "ref".</div>
<div>To resolve the part about taking address of locals -- because we *can* actually take the address of locals.</div>
<div><br>
</div>
<div>The problem then becomes, maybe, where can you store them?</div>
<div>But records have this problem too.</div>
<div><br>
</div>
<div>It is true, I guess, I haven't done it, that records + procedures come close, but there</div>
<div>are a few critical differences you indicate.</div>
<div> - Lack of inheritance.</div>
<div> - Convenient vtable initialization.</div>
<div> - Calling:</div>
<div>    jay.fn^.age(jay);  yuck! </div>
<div> - Size:</div>
<div>   Given only non-virtual functions, don't store anything.</div>
<div><br>
</div>
<div>Inheritance is strongly debated either way.</div>
<div>It is clearly useful and sensible sometimes (look at m3front!), and maybe it is overused sometimes (look at m3front?
<span id="x_x_🙂">🙂 )</span>.</div>
<div><br>
</div>
<div>Basically, yes, you really do want:</div>
<div><br>
</div>
<div> jay.age()  no function pointer or vtable pointer</div>
<div><br>
</div>
<div>instead of</div>
<div> Person_Age(jay)</div>
<div>or</div>
<div> jay.age(jay)  </div>
<div>or</div>
<div> jay.fn^.age(jay)</div>
<div><br>
</div>
<div>I mean, you know, achieving state.function() (or "object.method()") in "systems programming" is</div>
<div>the stuff of countless person years (C++, Java, COM, etc.) and Modula-3 does support it,</div>
<div>but it comes with unnecessary heap allocation.</div>
<div><br>
</div>
<div>As well, you want state.function() to be dynamically dispatched or not.</div>
<div>Depending on which function.</div>
<div><br>
</div>
<div>You know, I mean, C++ strikes imho a very healthy balance here.</div>
<div><br>
</div>
<div>I know ultimately C++ is complicated, but it is death by a thousand cuts, and we should be able to afford a few?</div>
<div><br>
</div>
<div>Thinking more on syntax..</div>
<div><br>
</div>
<div>INTERFACE Person;</div>
<div><br>
</div>
<div>TYPE T = RECORD</div>
<div>  birth_year: INTEGER;</div>
<div>END;</div>
<div><br>
</div>
<div>PROCEDURE Age(VAR self: T):INTEGER;</div>
<div><br>
</div>
<div>jay := Person.T{1900}; (* not really :) *)</div>
<div><br>
</div>
<div>jay.Age();</div>
<div><br>
</div>
<div>The idea is a value's static type implies its declaring interface as "its" scope.</div>
<div> C++ has a similar thing where parameter types imply namespace. Koenig lookup.</div>
<div><br>
</div>
<div><br>
</div>
<div>Though honestly I want to group arbitrarily many types in one interface/module,</div>
<div>so that breaks down. (e.g. m3c.m3) I understand the Interface.T idiom but I don't think</div>
<div>we should be bound by it. I don't think Modula-3 generally is. It is just</div>
<div>a convention.</div>
<div><br>
</div>
<div>And x.fn means x is first parameter to fn?</div>
<div><br>
</div>
<div>TYPE Dog = RECORD</div>
<div>  birth_year: INTEGER;</div>
<div>  CONST Age = DogAge;</div>
<div>END;</div>
<div><br>
</div>
<div>TYPE Person = RECORD</div>
<div>  birth_year: INTEGER;</div>
<div>  CONST Age = PersonAge;</div>
<div>END;</div>
<div><br>
</div>
<div>PROCEDURE DogAge(VAR self: Dog):INTEGER =</div>
<div>BEGIN</div>
<div> RETURN (Time.CurrentYear() - self.birth_year) * 7;</div>
<div>END DogAge;</div>
<div><br>
</div>
<div>PROCEDURE PersonAge(VAR self: Person):INTEGER =</div>
<div>BEGIN</div>
<div> RETURN (Time.CurrentYear() - self.birth_year);</div>
<div>END PersonAge;</div>
<div><br>
</div>
<div>?</div>
<div><br>
</div>
<div>That is much more explicit, as to what kind of lookup occurs, and seems convenient enough,</div>
<div>and more flexible.</div>
<div><br>
</div>
<div>I am using "const" here to indicate "not virtual".</div>
<div>I think virtual could reuse the object/methods syntax.</div>
<div>But I grant maybe these syntaxes should be more similar. Again look at C++,</div>
<div>where the syntaxes are the same except for the "virtual".</div>
<div>So my syntax is probably too clever. We just need a way in the existing</div>
<div>"methods" syntax to indicate non-virtual. </div>
<div><br>
</div>
<div>And then there is the matter of static member functions.</div>
<div><br>
</div>
<div>I understand the point, that language changes ripple through the larger language ecosystem.</div>
<div>m3front is the primary but not only definition of the language, but in my opinion</div>
<div>should not hold language evolution at a stand still.</div>
<div><br>
</div>
<div>C++ has the same problem -- expression evaluation in debuggers has been a mess.</div>
<div>But, then again, it hasn't bothered me much either. You do not really need the</div>
<div>expression evaluator in the debugger to handle much of the language.</div>
<div><br>
</div>
<div>Language aware editors can suffer too, but again, no big deal, language unaware</div>
<div>editors suffice. :)</div>
<div><br>
</div>
<div>We might consider better librarizing m3front??</div>
<div>I understand, having multiple implementations can be seen as good or bad,</div>
<div>so converging them to fewer also good and bad.</div>
<div><br>
</div>
<div>To repeat, sorry, I think despite all the criticism of C++, it really should be considered</div>
<div>to borrow some features from. There really are plenty of non-controversial features.</div>
<div><br>
</div>
<div>Which reminds me, even C99 can introduce variables later in a function, without implying</div>
<div>opening a block/scope/indent. I miss that. :(</div>
<div><br>
</div>
<div><br>
</div>
 - Jay<br>
</div>
<div>
<div id="x_x_appendonsend"></div>
<div style="font-family:Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_x_divRplyFwdMsg" dir="ltr"><span style="font-family:Calibri,sans-serif; color:#000000"><b>From:</b> Mika Nystrom <mika@alum.mit.edu><br>
<b>Sent:</b> Saturday, May 8, 2021 9:30 PM<br>
<b>To:</b> Jay K <jayk123@hotmail.com>; m3devel <m3devel@elegosoft.com><br>
<b>Subject:</b> Re: [M3devel] language evolution?</span>
<div> </div>
</div>
<div>
<div dir="ltr">Hi Jay,
<div><br>
</div>
<div>Writing here as someone who is not really a language implementer or a compiler person, but someone who regularly writes a bit of Modula-3 code.</div>
<div><br>
</div>
<div>Let me take your ideas backwards...</div>
<div><br>
</div>
<div>2. what do you gain here?  I don't think enough to make the complication worthwhile.  Is it such a big deal to write "Person.Age(johnDoe)"?</div>
<div><br>
</div>
<div>So this used to annoy me as well.  I learned to live with it, because Modula-3 has some very effective ways of doing shortcuts for Person.Age:</div>
<div><br>
</div>
<div>-- if you find yourself typing it a lot in a single procedure, module, or block, you can just write CONST Age = Person.Age.  If in a module, you can just as well write FROM Person IMPORT Age;  Also consider using generics.</div>
<div><br>
</div>
<div>-- or ask yourself why you care about the indirection.  I have never been able to measure a performance difference, and I have tried a few times.  </div>
<div><br>
</div>
<div>I think the design intent is that for performance critical stuff you use records and procedures and OOP gets the flexibility.  Do you need a middle ground, really?</div>
<div><br>
</div>
<div>----------------</div>
<div><br>
</div>
<div>So you ask OK, what we're proposing is optional.  But no, not really.  One of the super powers of Modula-3 is that it is a language in the same class as C++ but with a comprehensible type system.  There are at least two programs in CM3 that depend on understanding
 (at least the safe subset) of the type system.  If you start adding in non-virtual methods, ..... you are really making life difficult for these programs.  I don't know how many others may exist.  The ones in CM3 are Network Objects, and the Scheme interpreter
 I wrote ("Modula-3-Scheme"), which both use m3tk to understand basically arbitrary interfaces, and they really do need to understand the way to call methods, and they use the OOP features to add "surrogate objects" (I think that is a design pattern from Gamma
 et al.?  Or is it called a "facade"?)  If you add static/final methods you are suddenly making these systems keep track of different types of methods, on top of everything else they need to do.  Maybe not a major complication but still it is a complication
 that I think can be avoided.</div>
<div><br>
</div>
<div>1. This is trickier.  The javaism of having to NEW all OBJECTs in M3 is indeed a performance issue in many programs.</div>
<div><br>
</div>
<div>So let's make VAL = REF^-1 (i.e., the inverse of REF).</div>
<div><br>
</div>
<div>TYPE T = VAL REF U;</div>
<div><br>
</div>
<div>means T = U. for all U.</div>
<div><br>
</div>
<div>The only problem with it is... what the heck do you DO with a stack-allocated VAL OBJECT?  You can't pass it to anything that expects  an OBJECT, taking the address of something is verboten in non-UNSAFE Modula-3.  So you will have to declare your target
 procedures as taking VAR/READONLY x : VAL OBJECT ... parameters.</div>
<div><br>
</div>
<div>But what of the methods themselves?  The initial argument is the object itself.  They now take VAR/READONLY self : VAL OBJECT parameters too, I guess?  But then you probably break polymorphism?  (And if you are OK with breaking polymorphism, see my objections
 to your suggestion 2. above.  If all you want is a RECORD with PROCEDUREs, just do that!)</div>
<div><br>
</div>
<div>I would like VAL REF for another purpose.  To be able to do:</div>
<div><br>
</div>
<div>TYPE T = VAL OBJECT ... END;</div>
<div><br>
</div>
<div>VAR aMegOfObjects := NEW(REF ARRAY OF T, 1024 * 1024);</div>
<div><br>
</div>
<div>I think that is at least as useful as stack-allocated objects.</div>
<div><br>
</div>
<div>What would be the meaning of</div>
<div><br>
</div>
<div>TYPE T = VAL BRANDED OBJECT ...</div>
<div><br>
</div>
<div>          T = VAL UNTRACED REF ...</div>
<div><br>
</div>
<div>At least the former is important because many existing OBJECT types are BRANDED.</div>
<div><br>
</div>
<div>Yeah this won't work because the methods are messed up.  See:</div>
<div><br>
</div>
<div>TYPE T = OBJECT METHODS hello() := HelloT; END;</div>
<div><br>
</div>
<div>PROCEDURE HelloT(self : T) = BEGIN IO.Put("hi!\n") END HelloT;</div>
<div><br>
</div>
<div>now...</div>
<div><br>
</div>
<div>TYPE U = VAL T;</div>
<div><br>
</div>
<div>VAR </div>
<div>    u : U;</div>
<div>BEGIN</div>
<div>    u.hello()   (* what happens here? *)</div>
<div>END</div>
<div><br>
</div>
<div>the problem being that HelloT has the wrong type of initial argument.  It needs to be of type VAL T, not T.</div>
<div><br>
</div>
<div>What if you let it be of type T?</div>
<div><br>
</div>
<div>Then consider...</div>
<div><br>
</div>
<div>TYPE T = OBJECT METHODS goodbye() := GoodbyeT END;</div>
<div><br>
</div>
<div>
<div>VAR trap : T;</div>
<div><br>
</div>
<div></div>
</div>
<div>PROCEDURE GoodbyeT(me : T) = BEGIN trap := me END GoodbyeT;</div>
<div><br>
</div>
<div>TYPE U = VAL T;</div>
<div><br>
</div>
<div>BEGIN</div>
<div>  VAR </div>
<div>      u : U;</div>
<div>  BEGIN</div>
<div>      u.goodbye()</div>
<div>  END; (* u is out of scope here *)</div>
<div>  trap.goodbye() (* ????? *)</div>
<div>END</div>
<div><br>
</div>
<div>The declaration of U parenthesizes inconveniently.</div>
<div><br>
</div>
<div>TYPE U = (VAL OBJECT METHODS goodbye() END) OVERRIDES goodbye := GoodbyeU END;</div>
<div><br>
</div>
<div>If you don't override a method when you make a VAL object it must be overridden with NIL, to preclude making references to the stack.</div>
<div><br>
</div>
<div>I guess you get a separate type hierarchy for VAL OBJECT types from OBJECT types, you can't inherit the methods.</div>
<div><br>
</div>
<div>Now there is a school of thought in OOP, I know, that holds that inheriting methods is a Bad Idea and dangerous.  That school would probably be OK with your idea.  It says that it's OK, and a Good Thing, to inherit the method signature, since it is part
 of the specification.  But implementations (i.e. method text) should not be inherited.  Are you part of this school?</div>
<div><br>
</div>
<div>
<div></div>
</div>
<div>Is there a problem with REF VAL OBJECT?  Yeah it becomes ambiguous.  Drat... is it (REF VAL) OBJECT = OBJECT or is it (REF (VAL OBJECT)), a REF to a given VAL OBJECT type?  These are obviously different concepts.</div>
<div><br>
</div>
<div>Are you sure you want this?  It seems tricky and not that convenient after all.</div>
<div><br>
</div>
<div>    Mika</div>
<div><br>
</div>
<div>  </div>
<div><br>
</div>
</div>
<br>
<div class="x_x_x_gmail_quote">
<div dir="ltr" class="x_x_x_gmail_attr">On Fri, May 7, 2021 at 11:53 PM Jay K <<a href="mailto:jayk123@hotmail.com">jayk123@hotmail.com</a>> wrote:<br>
</div>
<blockquote class="x_x_x_gmail_quote" style="margin:0px 0px 0px 0.8ex; border-left:1px solid rgb(204,204,204); padding-left:1ex">
<div dir="ltr">
<div style="font-family:Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
Here are some language features I would like.
<div><br>
</div>
<div>1. OBJECTs that are not heap allocated.</div>
<div><br>
</div>
<div>Given that records can be on the stack or global, and can contain function pointers,</div>
<div>why must OBJECTS be heap allocated?</div>
<div><br>
</div>
<div>The syntax is almost obvious, except that I think OBJECT implies REF.</div>
<div>Perhaps we could say "VALUE" to negate that?</div>
<div>Or the existing keyword VAL could be repurposed?</div>
<div><br>
</div>
<div>2. non-virtual object methods; or merely non-virtual member functions in records.</div>
<div><br>
</div>
<div>TYPE Person = RECORD</div>
<div>   birth_year: INTEGER;</div>
<div>   CONST PROCEDURE age():INTEGER = Person_Age; (* not a function pointer *)</div>
<div> END;</div>
<div><br>
</div>
<div><br>
</div>
<div>PROCEDURE Person_Age(VAR self: Person): INTEGER =</div>
<div>BEGIN</div>
<div>  RETURN Date.CurrentYear() - self.birth_year;</div>
<div>END Person_Age;</div>
<div><br>
</div>
<div>VAR johnDoe := Person{1980};</div>
<div><br>
</div>
<div>IO.Put(Fmt.Int(johnDoe.age());</div>
<div><br>
</div>
<div> => equivalent to Person_Age(johnDoe), but using the type</div>
<div>    of the prefix parameter to disambiguate the short name "age",</div>
<div>    so I do not have to state the type in the function name over and over.</div>
<div><br>
</div>
<div>?</div>
<div><br>
</div>
<div>This could kinda be considered the same request..if you give records the ability</div>
<div>to inherit..you know, how in C++, class and struct are really the same thing.</div>
<div><br>
</div>
<div>I get that Modula-3 is optionally safe, has no preprocessor, has easier</div>
<div>to implement generics -- it is not C++ -- but are these bad features?</div>
<div><br>
</div>
 - Jay<br>
</div>
</div>
_______________________________________________<br>
M3devel mailing list<br>
<a href="mailto:M3devel@elegosoft.com" target="_blank">M3devel@elegosoft.com</a><br>
<a href="https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fm3lists.elegosoft.com%2Fmailman%2Flistinfo%2Fm3devel&data=04%7C01%7C%7C2d50dffa95134fef79ba08d912be8399%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637561431723069054%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=hc%2FWfaawytTc31q8nXBBt1HYLXq6MyGUpvZ%2FYnQYeEM%3D&reserved=0" originalsrc="https://m3lists.elegosoft.com/mailman/listinfo/m3devel" shash="r/6FUc5RyRrv+niFYhaCyAAsOHb4FtPiQ95KKboFzM5OsOOBrxIW1Kdvo4p1npB9wYNZdetMYKwaDLO9Fxek4ai7/r3IsvIkVLt9j2/NFRnxC5pbWccgm9hvRkkSa+FkcZXuhZXQi4XhyXl8zWtSoE4iaIfTmSFQjuk4MEexg8g=" rel="noreferrer" target="_blank">https://m3lists.elegosoft.com/mailman/listinfo/m3devel</a><br>
</blockquote>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<img class="x_mailbird" width="1" height="1" style="border:0; width:1; height:1" src="https://tracking.getmailbird.com/OpenTrackingPixel/?messageId=Mailbird-e88f357f-9a41-40a1-9773-d873e55a2f99@hotmail.com&senderHash=7C02C40A7B379A07BCD8ED251F69A75A67BA121D56B24ACC64170A95F0D0C6A4&recipientHash=233984F451119DD37E2E42BDF930267AC7574D9514389A80E452E590F59A6358&internalId=bc39fde4-99b8-499c-b808-aa8b8ac1d796" data-unique-identifier="">
</div>
</div>
</div>
</blockquote>
</div>
</body>
</html>