Your program is half an answer :) Here's a second half to compare:

#lang racket/base

(module typed1 typed/racket/base
  (provide (struct-out container)
           container-append)
  (define-type SymbolTree
    (U Null Symbol (Pairof SymbolTree SymbolTree)))
  (struct container ([tree : SymbolTree])
    #:transparent)
  (: container-append (-> container container container))
  (define (container-append a b)
    (container (cons (container-tree a)
                     (container-tree b)))))

(module typed2 typed/racket/base
  (provide container
           container-append)
  (define-type SymbolTree
    (U Null Symbol (Pairof SymbolTree SymbolTree)))
  (define-type container2 (Pairof 'container SymbolTree))
  (define (container (tree : SymbolTree)) : container2
    (cons 'container tree))
  (define (container-tree (c : container2)) : SymbolTree
    (cdr c))
  (: container-append (-> container2 container2 container2))
  (define (container-append a b)
    (container (cons (container-tree a)
                     (container-tree b)))))

(require
  (prefix-in struct: 'typed1)
  (prefix-in list: 'typed2))

(for ((iters (in-range 1 6)))
  (for ((make-c (in-list (list struct:container list:container)))
        (c-append (in-list (list struct:container-append
list:container-append)))
        (name (in-list '("struct" "list"))))
    (define n (* iters 10))
    (printf "testing ~a (~a iters)~n" name n)
    (time
      (for/fold ((acc (make-c '())))
                ((_i (in-range n)))
        (c-append acc (make-c (build-list (expt 10 4) (lambda (_) 'X))))))))

The version with lists runs much slower for me than the one with structs:

testing struct (10 iters)
cpu time: 1493 real time: 1509 gc time: 6
testing list (10 iters)
cpu time: 9775 real time: 9885 gc time: 9
testing struct (20 iters)
cpu time: 3031 real time: 3107 gc time: 4
testing list (20 iters)
cpu time: 34468 real time: 34796 gc time: 57


In general (iiuc): since Typed Racket defined this non-prefab
non-polymorphic struct, it can trust the fields of a `container?`
value.

> Assuming the answer to this question isn't likely to change, I think it would 
> be worth adding to the documentation, perhaps at 
> http://docs.racket-lang.org/ts-guide/typed-untyped-interaction.html#%28part._.Protecting_.Typed-.Untyped_.Interaction%29
>  or 
> http://docs.racket-lang.org/ts-guide/optimization.html#%28part._contract-costs%29.
>  For the use-case I'm considering, having to traverse the entire data 
> structure on typed–untyped boundary crossings would clearly be prohibitive.

Yes good point

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to