<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Aptos;
panose-1:2 11 0 4 2 2 2 2 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
font-size:11.0pt;
font-family:"Aptos",sans-serif;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:11.0pt;
mso-ligatures:none;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style>
</head>
<body lang="EN-GB" link="#467886" vlink="#96607D" style="word-wrap:break-word">
<div class="WordSection1">
<div>
<p class="MsoNormal">So over Christmas I tried kicking the tires on string templates I by creating a method handle combinators library that worked with a small lisp DSL, because I had always described the method handles API to new developers as a lisp with
really annoying syntax, so I thought I’d try and remove that syntax hurdle.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Overall I think it worked well, except that there was some friction in composing fragments (should I use RAW templates, provide an intermediate form, or make sure I could always decompose the MH structures in all the ways my library might
need) and that if I expected a call site to be used frequently I lacked the sealed linkage mechanism that FMT could use.</p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Removing the processor from template literal declaration definitely steers things in a particular direction and should place all users on an even field in terms of implementation optimisations, and I’ll be very interested to see this when
there is a branch available. I think the downside to this is that we will no longer see a clean correspondence of template literals to call sites that process them so I will be interested to see what performance boost we get on string formatting that couldn’t
already be done with the existing format string.</p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">The other thing I’d be interested to know in this new approach is how StringTemplates inserted as values into other templates will be treated. Simply as StringTemplate objects in the values list, or will they produce a string template that
has been flattened? The new approach feels like it will encourage this approach of combining fragments and is likely to be something that many processors are going to need to handle.</p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Anyway, looking forward to seeing this new approach and trying this MH combinators prototype a second time.</p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Duncan.</p>
</div>
</div>
</body>
</html>