[racket] typed/racket, promises, and type dispatch

Would it help to wrap one of them (in this case WireVec) in a structure like this:
#lang typed/racket
(define-type Wire (U (Promise Wire) Symbol))
(define-type Wire-List (U (Promise Wire-List) (Listof Wire)))
(struct wire-vec ([wires : Wire-List]) #:transparent)
(define-type WireVec wire-vec)

;; dispatch based on type
(: Not (case-> (Wire -> Wire)
               (WireVec -> WireVec)))
(define (Not wire*)
  (if (wire-vec? wire*)
      (Not-wirevec wire*)
      (Not-wire wire*)))

(: Not-wire (Wire -> Wire))
(define (Not-wire w)
  (displayln "received wire")
  w)

(: Not-wirevec (WireVec -> WireVec))
(define (Not-wirevec w)
  (displayln "received wirevec")
  w)

;; test
(Not 'my-wire)
(Not (wire-vec (list 'a 'b 'c)))

;;; printed results are
;received wire
;'my-wire
;received wirevec
;(wire-vec '(a b c))


On Jan 23, 2015, at 11:41 AM, Luke Whittlesey <luke.whittlesey at gmail.com> wrote:

> 
> 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.
> 
> 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.
> Ususally when I get myself into a corner and there's not an easy way out, I need to rethink my approach (or goals). 
> Thanks for your suggestions.
> 
> -Luke
> ____________________
>  Racket Users list:
>  http://lists.racket-lang.org/users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20150124/8ad3dc6c/attachment-0001.html>