Re: Must have SINGLE input/Arg.
"John Meacham [email protected] [concatenative]" <[email protected]> Mon, 11 Aug 2014 20:16:17 -0700
| Newsgroups | gmane.comp.lang.concatenative |
|---|---|
| Message-ID | <CAM0WKeX-FGRVRQx3DGpP6wyC+339yfoun_JF1vN8+0oYKqUOBg@mail.gmail.com> |
--001a11c261d079d8f40500661970
Content-Type: text/plain; charset=ISO-8859-1
An issue with no bottom is that having it is necessary to properly reason
about infinite data structures. Now, as to whether you actually want
infinite data structures in your language is another issue, but with my
Haskell background I gotta say they are darn handy. :)
I actually have a concatinative lazy language I wrote called 'levity' (a
play on joy) for use internally by a project a while ago. It had some
interesting properties, I should write up the core as it may be interesting
to other fans of concatinative languages even if the code itself is
probably not reusable.
Among other things, it had its symbols in compositional order and was list
based instead of stack based, it just happened that functions implicitly
acted upon the 'current list'. 'f g h' means f(g(h(current list))).. But
by having it in compositional order, something like (1 2 3) actually ended
up being a list in the order 1, 2, 3, and (1 2 2 1 +) ended up also being
(1 2 3). (..) was just syntactic sugar for 'run the symbols between the
parens on an empty stack and take the resulting stack as your new list.
Due to where I was using the language, as part of a strategy specification
system for a theorem prover, I was able to actually keep it fully pure in
the mathematical sense so laziness was a no-brainer without side effects to
worry about.
John
On Mon, Aug 11, 2014 at 5:26 PM, John Nilsson [email protected]
[concatenative] <[email protected]> wrote:
>
>
> I was thinking that composition would also be partial evaluation. So the
> benefits of curried functions should be the same.
>
> Regarding evaluation I'm curious if there is something interesting to be
> found by looking at kappa calculus or similar first order system instead of
> full lambda calculus. Or in any case, aiming for a total language, so no
> bottom. Looking around recent papers from various researches it seems to me
> that one could get quite far that route. Possibly one has to introduce some
> disciplined way to do higher order things sooner or later though.
>
> BR,
> John
>
>
>
> On Mon, Aug 11, 2014 at 9:39 PM, John Meacham [email protected]
> [concatenative] <[email protected]> wrote:
>
>>
>>
>> However, they actually are not isomorphic and behave differently during
>> beta reduction, due to being able to perform shared computation in between
>> the passing of the arguments. for instance
>>
>> f = \x -> let bx = x^10 in \y -> bx + y
>>
>> when applied to just one argument will share the computation of
>> calculating the tenth power with all of its uses.
>>
>> When working with a lazy language you also have the fact that a tuple has
>> another value, namely the tuple itself being bottom in addition to each of
>> its components being bottom which means tupled arguments are different than
>> fully applied curried ones as they can take on more values.
>>
>> These are all good and useful things, being able to control sharing and
>> evaluation via proper use of currying is a very powerful tool for many
>> languages.
>>
>> John
>>
>>
>>
>> On Mon, Aug 11, 2014 at 12:17 PM, 'John Nilsson' [email protected]
>> [concatenative] <[email protected]> wrote:
>>
>>>
>>>
>>> One problem with currying is that it makes (A,B) -> C != A -> B -> C !=
>>> B -> A -> C
>>>
>>> When in practice they should all be equal.
>>>
>>> My thinking is that this could be addressed by just making them equal so
>>> that
>>>
>>> (D -> B) (A,B -> C) = (A,D -> C)
>>>
>>> Now this gets a little problematic if we have (A,A -> A)
>>>
>>> So I suggest that we add bindings to the type and se argument lists not
>>> as ordered tuples, but more like first class environments.
>>>
>>> Thus the type above would be (x::A,y::A -> z::A) and composition would
>>> work as the ABCD case above.
>>>
>>> To allow composition with arbitrary name we can add a rename type so that
>>>
>>> (x:a) (x::A,y::A -> z::A) = (a::A,y::A -> z::A)
>>>
>>> This would also mean that it is an environment with bindings that gets
>>> threaded through the program, and not a stack.
>>>
>>> BR,
>>> John
>>> --
>>> Sent from Mailbox <https://www.dropbox.com/mailbox>
>>>
>>>
>>> On Mon, Aug 11, 2014 at 6:07 PM, chris glur [email protected]
>>> [concatenative] <[email protected]> wrote:
>>>
>>>>
>>>>
>>>> The 'impedance mismatch' [who introduced that term for
>>>> non-ElectricalEngineers?] problem of different numbers of
>>>> inputs & outputs of functions, is apparently the motivation
>>>> for the idea of passing a SINGLE stack.
>>>> And the ideas of 'currying'.
>>>> IMO, what matters, is reducing the human mental load.
>>>> Hiding N mental-chunks, by wrapping them in a stack
>>>> is fraudulent.
>>>> Yes, point-free is great. Everything 'popping-out' is just "it".
>>>> take it | wash it | cook it| eat it
>>>> Without even thinking about the theoretical aspects of
>>>> impedance mismatch when multiple input-args are needed,
>>>> it was obvious that the following 'schematic' does it:
>>>> -> set Arg2
>>>> -> set Arg3
>>>> Arg1-> DoA -> DoB(A,Arg2) -> DoC(B,Arg3) -> FinalResult.
>>>> So you set the extra Args, before the main composition starts,
>>>> and the relevant functions know where to get their extra args.
>>>>
>>>> Sure, it's not as neat looking, but the mental-load is less
>>>> than wrapping multiple args, to look like 'unary'.
>>>>
>>>> == Chris Glur.
>>>>
>>>
>>>
>>
>>
>> --
>> John Meacham - http://notanumber.net/
>>
>>
>
>
--
John Meacham - http://notanumber.net/
--001a11c261d079d8f40500661970
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
</head>
<body style="background-color: #fff;">
<span style="display:none"> </span>
<!--~-|**|PrettyHtmlStartT|**|-~-->
<div id="ygrp-mlmsg" style="position:relative;">
<div id="ygrp-msg" style="z-index: 1;">
<!--~-|**|PrettyHtmlEndT|**|-~-->
<div id="ygrp-text" >
<p><div dir="ltr">An issue with no bottom is that having it is necessary to properly reason about infinite data structures. Now, as to whether you actually want infinite data structures in your language is another issue, but with my Haskell background I gotta say they are darn handy. :)<div>
<br></div><div>I actually have a concatinative lazy language I wrote called 'levity' (a play on joy) for use internally by a project a while ago. It had some interesting properties, I should write up the core as it may be interesting to other fans of concatinative languages even if the code itself is probably not reusable.</div>
<div><br></div><div>Among other things, it had its symbols in compositional order and was list based instead of stack based, it just happened that functions implicitly acted upon the 'current list'. 'f g h' means f(g(h(current list))).. But by having it in compositional order, something like (1 2 3) actually ended up being a list in the order 1, 2, 3, and (1 2 2 1 +) ended up also being (1 2 3). (..) was just syntactic sugar for 'run the symbols between the parens on an empty stack and take the resulting stack as your new list.</div>
<div><br></div><div>Due to where I was using the language, as part of a strategy specification system for a theorem prover, I was able to actually keep it fully pure in the mathematical sense so laziness was a no-brainer without side effects to worry about.</div>
<div><br></div><div> John</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Aug 11, 2014 at 5:26 PM, John Nilsson <a href="mailto:[email protected]">[email protected]</a> [concatenative] <span dir="ltr"><<a href="mailto:[email protected]" target="_blank">[email protected]</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left:1px #ccc solid;">
<u></u>
<div style="background-color:#fff;">
<span> </span>
<div>
<div>
<div>
<p></p><div dir="ltr">I was thinking that composition would also be partial evaluation. So the benefits of curried functions should be the same.<div><div><br></div><div>Regarding evaluation I'm curious if there is something interesting to be found by looking at kappa calculus or similar first order system instead of full lambda calculus. Or in any case, aiming for a total language, so no bottom. Looking around recent papers from various researches it seems to me that one could get quite far that route. Possibly one has to introduce some disciplined way to do higher order things sooner or later though.</div>
<div><br></div><div>BR,<br></div><div>John</div><div><br></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote"><div><div class="h5">On Mon, Aug 11, 2014 at 9:39 PM, John Meacham <a href="mailto:[email protected]" target="_blank">[email protected]</a> [concatenative] <span dir="ltr"><<a href="mailto:[email protected]" target="_blank">[email protected]</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="border-left:1px #ccc solid;">
<u></u>
<div style="background-color:#fff;">
<span> </span>
<div>
<div>
<div><div><div class="h5">
<p></p><div dir="ltr">However, they actually are not isomorphic and behave differently during beta reduction, due to being able to perform shared computation in between the passing of the arguments. for instance<div>
<br></div><div>
f = \x -> let bx = x^10 in \y -> bx + y</div><div><br></div><div>when applied to just one argument will share the computation of calculating the tenth power with all of its uses.</div><div><br></div><div>When working with a lazy language you also have the fact that a tuple has another value, namely the tuple itself being bottom in addition to each of its components being bottom which means tupled arguments are different than fully applied curried ones as they can take on more values.</div>
<div><br></div><div>These are all good and useful things, being able to control sharing and evaluation via proper use of currying is a very powerful tool for many languages.</div><div><br></div><div> John</div><div>
<br></div></div></div></div><div class="gmail_extra"><div><div class="h5"><div><div><br><br><div class="gmail_quote">On Mon, Aug 11, 2014 at 12:17 PM, 'John Nilsson' <a href="mailto:[email protected]" target="_blank">[email protected]</a> [concatenative] <span dir="ltr"><<a href="mailto:[email protected]" target="_blank">[email protected]</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left:1px #ccc solid;">
<u></u>
<div style="background-color:#fff;">
<span> </span>
<div>
<div>
<div>
<p>
<span>One problem with currying is that it makes (A,B) -> C != A -> B -> C != B -> A -> C</span></p><div><br></div>
<div>When in practice they should all be equal.</div>
<div><br></div>
<div>My thinking is that this could be addressed by just making them equal so that</div>
<div><br></div>
<div>(<span>D -> B) </span><span>(A,B -> C) = (A,D -> C)</span>
</div>
<div><br></div>
<div>Now this gets a little problematic if we have (A,A -> A)</div>
<div><br></div>
<div>So I suggest that we add bindings to the type and se argument lists not as ordered tuples, but more like first class environments.</div>
<div><br></div>
<div>Thus the type above would be (x::A,<span>y::A -> z::A) and composition would work as the ABCD case above.</span>
</div>
<div><span><br></span></div>
<div><span>To allow composition with arbitrary name we can add a rename type so that</span></div>
<div><span><br></span></div>
<div>
<span>(x:a) </span><span>(x::A,y::A -> z::A) = </span><span>(a::A,y::A -> z::A)</span>
</div>
<div><span><br></span></div>
<div><span>This would also mean that it is an environment with bindings that gets threaded through the program, and not a stack.</span></div>
<div><span><br></span></div>
<div><span>BR,</span></div>
<div><span>John</span></div><div>—<br>Sent from <a href="https://www.dropbox.com/mailbox" target="_blank">Mailbox</a>
</div><div>
<br><br><div class="gmail_quote"><p>On Mon, Aug 11, 2014 at 6:07 PM, chris glur <a href="mailto:[email protected]" target="_blank">[email protected]</a> [concatenative] <span dir="ltr"><<a href="mailto:[email protected]" target="_blank">[email protected]</a>></span> wrote:<br>
</p><blockquote class="gmail_quote" style="border-left:1px #ccc solid;">
<span> </span><div>
<div>
<div>
<p>The 'impedance mismatch' [who introduced that term for<br>
non-ElectricalEngineers?] problem of different numbers of<br>
inputs & outputs of functions, is apparently the motivation<br>
for the idea of passing a SINGLE stack.<br>
And the ideas of 'currying'.<br>
IMO, what matters, is reducing the human mental load.<br>
Hiding N mental-chunks, by wrapping them in a stack<br>
is fraudulent.<br>
Yes, point-free is great. Everything 'popping-out' is just "it".<br>
take it | wash it | cook it| eat it<br>
Without even thinking about the theoretical aspects of<br>
impedance mismatch when multiple input-args are needed,<br>
it was obvious that the following 'schematic' does it:<br>
-> set Arg2<br>
-> set Arg3<br>
Arg1-> DoA -> DoB(A,Arg2) -> DoC(B,Arg3) -> FinalResult.<br>
So you set the extra Args, before the main composition starts,<br>
and the relevant functions know where to get their extra args.<br><br>
Sure, it's not as neat looking, but the mental-load is less<br>
than wrapping multiple args, to look like 'unary'.<br><br>
== Chris Glur.<br></p>
</div>
<div style="color:#fff;min-height:0;"></div>
</div></div></blockquote></div><br></div><p></p>
</div>
<div style="color:#fff;min-height:0;"></div>
</div>
</div></div></blockquote></div><br><br clear="all"><div><br></div></div></div></div></div><div class>-- <br>John Meacham - <a href="http://notanumber.net/" target="_blank">http://notanumber.net/</a>
</div></div>
<p></p>
</div>
<div style="color:#fff;min-height:0;"></div>
</div>
</div></div></blockquote></div><br></div>
<p></p>
</div><div class>
<div style="color:#fff;min-height:0;"></div>
</div>
</div></div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>John Meacham - <a href="http://notanumber.net/" target="_blank">http://notanumber.net/</a>
</div>
</p>
</div>
<!--~-|**|PrettyHtmlStart|**|-~-->
<div style="color: #fff; height: 0;">__._,_.___</div>
<div style="clear:both"> </div>
<div id="fromDMARC" style="margin-top: 10px;">
<hr style="height:2px ; border-width:0; color:#E3E3E3; background-color:#E3E3E3;">
Posted by: John Meacham <[email protected]> <hr style="height:2px ; border-width:0; color:#E3E3E3; background-color:#E3E3E3;">
</div>
<div style="clear:both"> </div>
<table cellspacing=4px style="margin-top: 10px; margin-bottom: 10px; color: #2D50FD;">
<tbody>
<tr>
<td style="font-size: 12px; font-family: arial; font-weight: bold; padding: 7px 5px 5px;" >
<a style="text-decoration: none; color: #2D50FD" href="https://groups.yahoo.com/neo/groups/concatenative/conversations/messages/5012;_ylc=X3oDMTJwNmUxaWVsBF9TAzk3MzU5NzE0BGdycElkAzE4MzkyNzQEZ3Jwc3BJZAMxNzA1MDA2NzY0BG1zZ0lkAzUwMTIEc2VjA2Z0cgRzbGsDcnBseQRzdGltZQMxNDA3ODEzMzk5?act=reply&messageNum=5012">Reply via web post</a>
</td>
<td>•</td>
<td style="font-size: 12px; font-family: arial; padding: 7px 5px 5px;" >
<a href="mailto:[email protected]?subject=Re%3A%20%5Bstack%5D%20Must%20have%20SINGLE%20input%2FArg%2E" style="text-decoration: none; color: #2D50FD;">
Reply to sender </a>
</td>
<td>•</td>
<td style="font-size: 12px; font-family: arial; padding: 7px 5px 5px;">
<a href="mailto:[email protected]?subject=Re%3A%20%5Bstack%5D%20Must%20have%20SINGLE%20input%2FArg%2E" style="text-decoration: none; color: #2D50FD">
Reply to group </a>
</td>
<td>•</td>
<td style="font-size: 12px; font-family: arial; padding: 7px 5px 5px;" >
<a href="https://groups.yahoo.com/neo/groups/concatenative/conversations/newtopic;_ylc=X3oDMTJlc2c5NDRrBF9TAzk3MzU5NzE0BGdycElkAzE4MzkyNzQEZ3Jwc3BJZAMxNzA1MDA2NzY0BHNlYwNmdHIEc2xrA250cGMEc3RpbWUDMTQwNzgxMzM5OQ--" style="text-decoration: none; color: #2D50FD">Start a New Topic</a>
</td>
<td>•</td>
<td style="font-size: 12px; font-family: arial; padding: 7px 5px 5px;color: #2D50FD;" >
<a href="https://groups.yahoo.com/neo/groups/concatenative/conversations/topics/5008;_ylc=X3oDMTM0MDR1dmRhBF9TAzk3MzU5NzE0BGdycElkAzE4MzkyNzQEZ3Jwc3BJZAMxNzA1MDA2NzY0BG1zZ0lkAzUwMTIEc2VjA2Z0cgRzbGsDdnRwYwRzdGltZQMxNDA3ODEzMzk5BHRwY0lkAzUwMDg-" style="text-decoration: none; color: #2D50FD;">Messages in this topic</a>
(5)
</td>
</tr>
</tbody>
</table>
<!------- Start Nav Bar ------>
<!-- |**|begin egp html banner|**| -->
<div id="ygrp-vital" style="background-color: #f2f2f2; font-family: Verdana; font-size: 10px; margin-bottom: 10px; padding: 10px;">
<span id="vithd" style="font-weight: bold; color: #333; text-transform: uppercase; "><a href="https://groups.yahoo.com/neo/groups/concatenative/info;_ylc=X3oDMTJlcjJzMWxsBF9TAzk3MzU5NzE0BGdycElkAzE4MzkyNzQEZ3Jwc3BJZAMxNzA1MDA2NzY0BHNlYwN2dGwEc2xrA3ZnaHAEc3RpbWUDMTQwNzgxMzM5OQ--" style="text-decoration: none;">Visit Your Group</a></span>
<ul style="list-style-type: none; margin: 0; padding: 0; display: inline;">
</ul>
</div>
<div id="ft" style="font-family: Arial; font-size: 11px; margin-top: 5px; padding: 0 2px 0 0; clear: both;">
<a href="https://groups.yahoo.com/neo;_ylc=X3oDMTJkZmRqcG90BF9TAzk3NDc2NTkwBGdycElkAzE4MzkyNzQEZ3Jwc3BJZAMxNzA1MDA2NzY0BHNlYwNmdHIEc2xrA2dmcARzdGltZQMxNDA3ODEzMzk5" style="float: left;"><img src="http://l.yimg.com/ru/static/images/yg/img/email/new_logo/logo-groups-137x15.png" height="15" width="137" alt="Yahoo! Groups" style="border: 0;"/></a>
<div style="color: #747575; float: right;"> • <a href="https://info.yahoo.com/privacy/us/yahoo/groups/details.html" style="text-decoration: none;">Privacy</a> • <a href="mailto:[email protected]?subject=Unsubscribe" style="text-decoration: none;">Unsubscribe</a> • <a href="https://info.yahoo.com/legal/us/yahoo/utos/terms/" style="text-decoration: none;">Terms of Use</a> </div>
</div>
<br>
<!-- |**|end egp html banner|**| -->
</div> <!-- ygrp-msg -->
<!-- Sponsor -->
<!-- |**|begin egp html banner|**| -->
<div id="ygrp-sponsor" style="width:160px; float:right; clear:none; margin:0 0 25px 0; background: #fff;">
<!-- Start Recommendations -->
<div id="ygrp-reco">
</div>
<!-- End Recommendations -->
</div> <!-- |**|end egp html banner|**| -->
<div style="clear:both; color: #FFF; font-size:1px;">.</div>
</div>
<img src="http://geo.yahoo.com/serv?s=97359714/grpId=1839274/grpspId=1705006764/msgId=5012/stime=1407813399" width="1" height="1"> <br>
<img src="http://y.analytics.yahoo.com/fpc.pl?ywarid=515FB27823A7407E&a=10001310322279&js=no&resp=img" width="1" height="1">
<div style="color: #fff; height: 0;">__,_._,___</div>
<!--~-|**|PrettyHtmlEnd|**|-~-->
</body>
<!--~-|**|PrettyHtmlStart|**|-~-->
<head>
<style type="text/css">
<!--
#ygrp-mkp {
border: 1px solid #d8d8d8;
font-family: Arial;
margin: 10px 0;
padding: 0 10px;
}
#ygrp-mkp hr {
border: 1px solid #d8d8d8;
}
#ygrp-mkp #hd {
color: #628c2a;
font-size: 85%;
font-weight: 700;
line-height: 122%;
margin: 10px 0;
}
#ygrp-mkp #ads {
margin-bottom: 10px;
}
#ygrp-mkp .ad {
padding: 0 0;
}
#ygrp-mkp .ad p {
margin: 0;
}
#ygrp-mkp .ad a {
color: #0000ff;
text-decoration: none;
}
#ygrp-sponsor #ygrp-lc {
font-family: Arial;
}
#ygrp-sponsor #ygrp-lc #hd {
margin: 10px 0px;
font-weight: 700;
font-size: 78%;
line-height: 122%;
}
#ygrp-sponsor #ygrp-lc .ad {
margin-bottom: 10px;
padding: 0 0;
}
#actions {
font-family: Verdana;
font-size: 11px;
padding: 10px 0;
}
#activity {
background-color: #e0ecee;
float: left;
font-family: Verdana;
font-size: 10px;
padding: 10px;
}
#activity span {
font-weight: 700;
}
#activity span:first-child {
text-transform: uppercase;
}
#activity span a {
color: #5085b6;
text-decoration: none;
}
#activity span span {
color: #ff7900;
}
#activity span .underline {
text-decoration: underline;
}
.attach {
clear: both;
display: table;
font-family: Arial;
font-size: 12px;
padding: 10px 0;
width: 400px;
}
.attach div a {
text-decoration: none;
}
.attach img {
border: none;
padding-right: 5px;
}
.attach label {
display: block;
margin-bottom: 5px;
}
.attach label a {
text-decoration: none;
}
blockquote {
margin: 0 0 0 4px;
}
.bold {
font-family: Arial;
font-size: 13px;
font-weight: 700;
}
.bold a {
text-decoration: none;
}
dd.last p a {
font-family: Verdana;
font-weight: 700;
}
dd.last p span {
margin-right: 10px;
font-family: Verdana;
font-weight: 700;
}
dd.last p span.yshortcuts {
margin-right: 0;
}
div.attach-table div div a {
text-decoration: none;
}
div.attach-table {
width: 400px;
}
div.file-title a, div.file-title a:active, div.file-title a:hover, div.file-title a:visited {
text-decoration: none;
}
div.photo-title a, div.photo-title a:active, div.photo-title a:hover, div.photo-title a:visited {
text-decoration: none;
}
div#ygrp-mlmsg #ygrp-msg p a span.yshortcuts {
font-family: Verdana;
font-size: 10px;
font-weight: normal;
}
.green {
color: #628c2a;
}
.MsoNormal {
margin: 0 0 0 0;
}
o {
font-size: 0;
}
#photos div {
float: left;
width: 72px;
}
#photos div div {
border: 1px solid #666666;
height: 62px;
overflow: hidden;
width: 62px;
}
#photos div label {
color: #666666;
font-size: 10px;
overflow: hidden;
text-align: center;
white-space: nowrap;
width: 64px;
}
#reco-category {
font-size: 77%;
}
#reco-desc {
font-size: 77%;
}
.replbq {
margin: 4px;
}
#ygrp-actbar div a:first-child {
/* border-right: 0px solid #000;*/
margin-right: 2px;
padding-right: 5px;
}
#ygrp-mlmsg {
font-size: 13px;
font-family: Arial, helvetica,clean, sans-serif;
*font-size: small;
*font: x-small;
}
#ygrp-mlmsg table {
font-size: inherit;
font: 100%;
}
#ygrp-mlmsg select, input, textarea {
font: 99% Arial, Helvetica, clean, sans-serif;
}
#ygrp-mlmsg pre, code {
font:115% monospace;
*font-size:100%;
}
#ygrp-mlmsg * {
line-height: 1.22em;
}
#ygrp-mlmsg #logo {
padding-bottom: 10px;
}
#ygrp-msg p a {
font-family: Verdana;
}
#ygrp-msg p#attach-count span {
color: #1E66AE;
font-weight: 700;
}
#ygrp-reco #reco-head {
color: #ff7900;
font-weight: 700;
}
#ygrp-reco {
margin-bottom: 20px;
padding: 0px;
}
#ygrp-sponsor #ov li a {
font-size: 130%;
text-decoration: none;
}
#ygrp-sponsor #ov li {
font-size: 77%;
list-style-type: square;
padding: 6px 0;
}
#ygrp-sponsor #ov ul {
margin: 0;
padding: 0 0 0 8px;
}
#ygrp-text {
font-family: Georgia;
}
#ygrp-text p {
margin: 0 0 1em 0;
}
#ygrp-text tt {
font-size: 120%;
}
#ygrp-vital ul li:last-child {
border-right: none !important;
}
-->
</style>
</head>
<!--~-|**|PrettyHtmlEnd|**|-~-->
</html>
<!-- end group email -->
--001a11c261d079d8f40500661970--