<div dir="ltr"><div><div>That's a nice idea, I like it, but now I can't figure out how to perform the `delay` end without some form of compile time type dispatch for `delay`.<br><br></div>For example I run into trouble with the second letrec form below:<br><br></div>;;; this works<br><div>(letrec ((a (Not (delay b)))<br> (b 'my-wire))<br> b)<br></div><div>;; but this won't work<br></div><div>(letrec ((a (Not (delay b)))<br> (b (wire-vec (list 'a 'b 'c))))<br> b)<br><br></div><div>The way forward (at least as far as I can tell) would need a type specific `delay`, delay-wire vs delay-wirevec macro, but I run into trouble with mixed delayed/eager evaluation. In the example above, a single `delay-dispatch` macro would need to expand to run-time code that would eagerily evaluate b in order to wrap it with the proper delay struct, but b is undefined at that point. Of course I could just manually provide the proper delay macro, but my macros that generate these letrec forms don't know how to do that... At some point I need to recheck my premise that my approach is sound.<br><br></div><div>I also tried using Neil's suggestion of changing types; I wrapped all promises within their own structs, but I ran into the same sort of trouble.<br><br></div><div>I just don't see a way to do this, so I might alter my approach. Maybe use Racket to generate a netlist/graph from the same letrec forms, but without a type checker in the way, and then figure out a way to type check the graph as a second step.<br><br></div><div>Thanks for your help.<br><br></div><div>-Luke<br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jan 24, 2015 at 12:50 AM, Alexander D. Knauth <span dir="ltr"><<a href="mailto:alexander@knauth.org" target="_blank">alexander@knauth.org</a>></span> wrote:<br><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>Would it help to wrap one of them (in this case WireVec) in a structure like this:</div><div><span class=""><div>#lang typed/racket</div><div>(define-type Wire (U (Promise Wire) Symbol))</div></span><div>(define-type Wire-List (U (Promise Wire-List) (Listof Wire)))</div><div>(struct wire-vec ([wires : Wire-List]) #:transparent)</div><div>(define-type WireVec wire-vec)</div><span class=""><div><br></div><div>;; dispatch based on type</div><div>(: Not (case-> (Wire -> Wire)</div><div> (WireVec -> WireVec)))</div><div>(define (Not wire*)</div></span><div> (if (wire-vec? wire*)</div><div> (Not-wirevec wire*)</div><div> (Not-wire wire*)))</div><span class=""><div><br></div><div>(: Not-wire (Wire -> Wire))</div><div>(define (Not-wire w)</div><div> (displayln "received wire")</div><div> w)</div><div><br></div><div>(: Not-wirevec (WireVec -> WireVec))</div><div>(define (Not-wirevec w)</div><div> (displayln "received wirevec")</div><div> w)</div><div><br></div><div>;; test</div><div>(Not 'my-wire)</div></span><div>(Not (wire-vec (list 'a 'b 'c)))</div><span class=""><div><br></div><div>;;; printed results are</div><div>;received wire</div><div>;'my-wire</div><div>;received wirevec</div></span><div>;(wire-vec '(a b c))</div></div><div><br></div><br><div><div><div class="h5"><div>On Jan 23, 2015, at 11:41 AM, Luke Whittlesey <<a href="mailto:luke.whittlesey@gmail.com" target="_blank">luke.whittlesey@gmail.com</a>> wrote:</div><br></div></div><blockquote type="cite"><div><div class="h5"><div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span></span>
That's only a guess at what `Not` is supposed to do, though. If you need to make a decision without first forcing the promise, you'll need to use different types.<span><font color="#888888"></font></span></blockquote><div><br></div><div>I'm playing around with describing circuits using Racket and using TR to type check my ports. Unfortunately I do have to make a decision before forcing the promise, just because in my current design I use nested letrec forms and can't guarantee that the promise is ready. `Not` is just a simple example of something that has a different behavior depending if the input is a single wire or a bundle of wires, but the input could also be a promise that forces to either a wire or a bundle.<br></div><div>Ususally when I get myself into a corner and there's not an easy way out, I need to rethink my approach (or goals). <br></div><div>Thanks for your suggestions.<br><br></div><div>-Luke<br></div></div></div></div></div></div><span class="">
____________________<br> Racket Users list:<br> <a href="http://lists.racket-lang.org/users" target="_blank">http://lists.racket-lang.org/users</a><br></span></blockquote></div><br></div></blockquote></div><br></div>