<div dir="ltr">On Sat, Apr 20, 2013 at 8:10 PM, Tab Atkins Jr. <span dir="ltr"><<a href="mailto:jackalmage@gmail.com" target="_blank">jackalmage@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Sat, Apr 20, 2013 at 4:13 PM, Sean Silva <<a href="mailto:silvas@purdue.edu">silvas@purdue.edu</a>> wrote:<br>

> On Sat, Apr 20, 2013 at 3:47 PM, Tab Atkins Jr. <<a href="mailto:jackalmage@gmail.com">jackalmage@gmail.com</a>><br>
> wrote:<br>
>> On Sat, Apr 20, 2013 at 9:19 AM, Isaac Schlueter <<a href="mailto:i@izs.me">i@izs.me</a>> wrote:<br>
>> > I'm not seeing what in this proposal can't be implemented in<br>
>> > JavaScript as it is today.  Is there an implementation of this<br>
>> > somewhere?  Are there any programs that use these streams?<br>
>><br>
>> This is a fully-general counter-argument against literally everything<br>
>> that doesn't require new primitives, and so is useless as an actual<br>
>> argument.  It would damn Promises/Futures, Sets, Maps, and a number of<br>
>> other new things.<br>
><br>
> I'm pretty sure there is no way to implement Maps with arbitrary keys in<br>
> current JS.<br>
<br>
</div>It's possible, but lookup time is linear.  You need some variety of<br>
language support to get constant-time lookups.<br></blockquote><div><br></div><div style>For ADT's, the complexity of an operation needs to be considered as part of the interface, since otherwise clients can't meaningfully use it. Every line of code a programmer writes requires a (possibly subconscious) evaluation of the complexity of the operation, and a factor of O(n) difference in complexity is enough to invalidate most of that reasoning and render the program broken. A linear lookup is equivalent to an incorrect implementation of the interface of a Map.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Now that I've got a handle on what I think a good design is, my plan<br>
is to retreat and spend some time studying and documenting existing<br>
stream patterns in libraries, to try and discover what I might be<br>
missing, or what areas I'm over/under-addressing.  When I'm done, I'll<br>
report back with my findings.<br><span class="HOEnZb"><font color="#888888"><br></font></span></blockquote><div style><br></div><div style>Cool. Please make sure to involve the primary developers of the most-used FRP and event stream libraries in your initial prototyping and put your work up on github.</div>
<div style><br></div><div style>-- Sean Silva </div></div><br></div></div>