<div dir="ltr">On Thu, Dec 15, 2011 at 02:23, Gregory Crosswhite <span dir="ltr"><<a href="mailto:gcrosswhite@gmail.com">gcrosswhite@gmail.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><div><div class="im"><div>On Dec 15, 2011, at 3:36 PM, Antoine Latter wrote:</div></div><div class="im"><blockquote type="cite"><span style="border-collapse:separate;font-family:'Latin Modern Roman';font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:-webkit-auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;font-size:medium">Even<br>
the operators at hand ('many' and 'some') are partial in parsing, but<br>I'm not prepared to throw them out.</span></blockquote></div></div><br><div>Okay, I must confess that this straw man has been causing my patience to get a little thing. *Nobody* here is saying that many and some should be thrown out, since there are clearly many contexts where they are very useful. The *most* that has been suggested is that they should be moved into a subclass in order to make it explicit when they are sensible, and that is *hardly* banning them.</div>
</div></blockquote><div><br></div><div>This.</div><div><br></div><div>I was always under the impression that the Haskell Way was to capture constraints in the type system instead of letting them be runtime failures; here we have some combinators that appear to require an additional constraint, and active opposition to describing that constraint in the type! </div>
</div><div><br></div>-- <br>brandon s allbery <a href="mailto:allbery.b@gmail.com" target="_blank">allbery.b@gmail.com</a><br>wandering unix systems administrator (available) (412) 475-9364 vm/sms<br>
<br>
</div>