Re: Must have SINGLE input/Arg.
"John Meacham [email protected] [concatenative]" <[email protected]> Wed, 13 Aug 2014 19:17:51 -0700
| Newsgroups | gmane.comp.lang.concatenative |
|---|---|
| Message-ID | <CAM0WKeX=czTZrO-d6vpD2Qjw4fDwUEsO_9rbM_MHEE9SvtfEYA@mail.gmail.com> |
--001a11c228fe2e449205008d844e Content-Type: text/plain; charset=ISO-8859-1 Lot's of fun stuff to read. thanks. I guess I was thinking more of the simple inductive reasoning I tend to use with haskell code that uses bottom as a base case, perhaps this will be what finally inspires me to learn coq. :) On Tue, Aug 12, 2014 at 5:07 PM, 'John Nilsson' [email protected] [concatenative] <[email protected]> wrote: > > > Im not sure that is the case. As I understand it it should be possible > even for a total language to reason about infinite structures. > > Here's a paper on copatterns > http://www.cs.mcgill.ca/~bpientka/papers/icfp13.pdf on termination and > productivity of those. > > > Does lazy exclude total btw? > > > If you do publish something about that language, it would be interesting > to read :) > > BR, > John > -- > Sent from Mailbox <https://www.dropbox.com/mailbox> > > > On Tue, Aug 12, 2014 at 5:16 AM, John Meacham [email protected] > [concatenative] <[email protected]> wrote: > >> >> >> 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/ >> > > > -- John Meacham - http://notanumber.net/ --001a11c228fe2e449205008d844e 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">Lot's of fun stuff to read. thanks. <div><br></div><div>I guess I was thinking more of the simple inductive reasoning I tend to use with haskell code that uses bottom as a base case, perhaps this will be what finally inspires me to learn coq. :)</div> </div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Aug 12, 2014 at 5:07 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> <span>Im not sure that is the case. As I understand it it should be possible even for a total language to reason about infinite structures.</span></p><div><br></div> <div>Here's a paper on copatterns <a href="http://www.cs.mcgill.ca/~bpientka/papers/icfp13.pdf" target="_blank">http://www.cs.mcgill.ca/~bpientka/papers/icfp13.pdf</a> on termination and productivity of those.</div> <div><br></div> <div><br></div> <div>Does lazy exclude total btw?</div> <div><br></div> <div><br></div> <div>If you do publish something about that language, it would be interesting to read :)</div> <div><br></div> <div>BR,</div> <div>John</div><div>—<br>Sent from <a href="https://www.dropbox.com/mailbox" target="_blank">Mailbox</a> </div><div><div class="h5"> <br><br><div class="gmail_quote"><p>On Tue, Aug 12, 2014 at 5:16 AM, 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> </p><blockquote class="gmail_quote" style="border-left:1px #ccc solid;"> <span> </span><div> <div> <div> <p></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]" 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></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>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> <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><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>-- <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> <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> </div> <div style="color:#fff;min-height:0;"></div> </div></div></blockquote></div><br></div></div><p></p> </div><div><div class="h5"> <div style="color:#fff;min-height:0;"></div> </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/5015;_ylc=X3oDMTJwMGZncDVmBF9TAzk3MzU5NzE0BGdycElkAzE4MzkyNzQEZ3Jwc3BJZAMxNzA1MDA2NzY0BG1zZ0lkAzUwMTUEc2VjA2Z0cgRzbGsDcnBseQRzdGltZQMxNDA3OTgyNjkz?act=reply&messageNum=5015">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=X3oDMTJlcWZwanJiBF9TAzk3MzU5NzE0BGdycElkAzE4MzkyNzQEZ3Jwc3BJZAMxNzA1MDA2NzY0BHNlYwNmdHIEc2xrA250cGMEc3RpbWUDMTQwNzk4MjY5Mw--" 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=X3oDMTM0dTg3Z2lnBF9TAzk3MzU5NzE0BGdycElkAzE4MzkyNzQEZ3Jwc3BJZAMxNzA1MDA2NzY0BG1zZ0lkAzUwMTUEc2VjA2Z0cgRzbGsDdnRwYwRzdGltZQMxNDA3OTgyNjkzBHRwY0lkAzUwMDg-" style="text-decoration: none; color: #2D50FD;">Messages in this topic</a> (8) </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=X3oDMTJlbHAxczVnBF9TAzk3MzU5NzE0BGdycElkAzE4MzkyNzQEZ3Jwc3BJZAMxNzA1MDA2NzY0BHNlYwN2dGwEc2xrA3ZnaHAEc3RpbWUDMTQwNzk4MjY5Mw--" 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=X3oDMTJkdm1pZmVnBF9TAzk3NDc2NTkwBGdycElkAzE4MzkyNzQEZ3Jwc3BJZAMxNzA1MDA2NzY0BHNlYwNmdHIEc2xrA2dmcARzdGltZQMxNDA3OTgyNjkz" 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=5015/stime=1407982693" 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 --> --001a11c228fe2e449205008d844e--