dvanhorn @ λ-calcul.us » Scheme http://dvanhorn.lambda-calcul.us Research weblog for David Van Horn Sat, 28 Aug 2010 13:39:54 +0000 http://wordpress.org/?v=2.9.2 en hourly 1 What’s the Racket? http://dvanhorn.lambda-calcul.us/2010/06/07/whats-the-racket/ http://dvanhorn.lambda-calcul.us/2010/06/07/whats-the-racket/#comments Mon, 07 Jun 2010 18:23:37 +0000 dvanhorn http://dvanhorn.lambda-calcul.us/?p=249 Racket, the system formerly known as PLT Scheme, has just been released.

PLT is happy to announce the release of Racket, available from

http://racket-lang.org/

With Racket, you can script command shells and web servers; you can quickly prototype animations and complex GUIs; regexps and threads are here to serve you. To organize your systems, you can mix and match classes, modules or components. Best of all, you start without writing down types. If you later wish to turn your script into a program, equip your Racket modules with explicit type declarations as you wish. And Racket doesn’t just come as a typed variant; you can also write your modules in a purely functional and lazy dialect.

Racket comes in so many flavors because Racket is much more than a standard scripting language or a plain programming language. Racket supports language extensibility to an unequaled degree. A Racket programmer knows that making up a new language is as easy as writing a new library.

To help you start quickly, Racket includes batteries in all shapes and sizes, most importantly, extensive documentation and all kinds of libraries.

Racket occupies a unique position between research and practice. It inherits many major ideas from language research, among them type safety (when the type system says that x is a number, then at runtime it always is a number) and memory safety (when some memory is reclaimed by the garbage collector it is impossible to still have a reference to it). At the same time, user demand governs rigid adherence to purely theoretical principles.

Racket, formerly PLT Scheme, is a product of over 15 years of development. Although Racket starts with a mature software base and an established user community, its new name reflects our view that this is just the beginning of Racket’s evolution.

]]> http://dvanhorn.lambda-calcul.us/2010/06/07/whats-the-racket/feed/ 0 Fun with Unicode and delimited continuations http://dvanhorn.lambda-calcul.us/2010/06/03/fun-with-unicode-and-delimited-continuations/ http://dvanhorn.lambda-calcul.us/2010/06/03/fun-with-unicode-and-delimited-continuations/#comments Thu, 03 Jun 2010 16:27:01 +0000 dvanhorn http://dvanhorn.lambda-calcul.us/?p=235 Doug Orleans’ cute program to compute roots of quadratic equations:

(define (± x y)
  (shift k (values (k (+ x y)) (k (- x y)))))

(define (quadratic-formula-roots a b c)
  (reset (/ (± (- b) (√ (- (² b) (* 4 a c))))
	    (* 2 a))))
]]> http://dvanhorn.lambda-calcul.us/2010/06/03/fun-with-unicode-and-delimited-continuations/feed/ 0 Photos from the Scheme Workshop http://dvanhorn.lambda-calcul.us/2009/09/26/photos-from-the-scheme-workshop/ http://dvanhorn.lambda-calcul.us/2009/09/26/photos-from-the-scheme-workshop/#comments Sun, 27 Sep 2009 03:25:55 +0000 dvanhorn http://dvanhorn.lambda-calcul.us/?p=174 Some photos from the 2009 Scheme and Functional Programming Workshop at Northeastern.

]]> http://dvanhorn.lambda-calcul.us/2009/09/26/photos-from-the-scheme-workshop/feed/ 0 SRFI 102: Procedure Arity Inspection http://dvanhorn.lambda-calcul.us/2009/09/23/srfi-102-procedure-arity-inspection/ http://dvanhorn.lambda-calcul.us/2009/09/23/srfi-102-procedure-arity-inspection/#comments Wed, 23 Sep 2009 15:31:36 +0000 dvanhorn http://dvanhorn.lambda-calcul.us/?p=171 A new SRFI for inspecting the arity of procedures:

Many Scheme systems provide mechanisms for inspecting the arity of a procedural value, making it a common feature, however there is no standard interface. As a result there is no portable way to observe the arity of a procedure without actually applying it. This SRFI proposes a simple interface that is consistent with existing Scheme systems’ facilities and prior proposals.

]]> http://dvanhorn.lambda-calcul.us/2009/09/23/srfi-102-procedure-arity-inspection/feed/ 0 SRFI 101: Purely Functional Random-Access Pairs and Lists http://dvanhorn.lambda-calcul.us/2009/09/17/srfi-101-purely-functional-random-access-pairs-and-lists/ http://dvanhorn.lambda-calcul.us/2009/09/17/srfi-101-purely-functional-random-access-pairs-and-lists/#comments Fri, 18 Sep 2009 02:41:29 +0000 dvanhorn http://dvanhorn.lambda-calcul.us/?p=165 A new SRFI for purely functional random-access lists:

Functional programming and list hacking go together like peanut butter and jelly, eval and apply, syntax and semantics, or cursing and recursing. But the traditional approach to implementing pairs and lists results in index-based access (list-ref) requiring time proportional the index being accessed. Moreover, indexed-based functional update (list-set) becomes so inefficient as to be nearly unspeakable. Instead, programmers revert the imperatives of the state; they use a stateful data structure and imperative algorithms.

This SRFI intends to improve the situation by offering an alternative implementation strategy based on Okasaki’s purely functional random-access lists [1]. Random-access pairs and lists can be used as a replacement for traditional, sequential pairs and lists with no asymptotic loss of efficiency. In other words, the typical list and pair operations such as cons, car, and cdr, all operate in O(1) time as usual. However, random-access lists additionally support index-based access and functional update operations that are asymptotically cheaper; O(log n) for random-access lists versus O(n) for sequential-access lists, where n is the length of the list being access or updated. As such, many purely functional index-based list algorithms become feasible by using a random-access list representation for pairs and lists.

]]> http://dvanhorn.lambda-calcul.us/2009/09/17/srfi-101-purely-functional-random-access-pairs-and-lists/feed/ 0 Dilbert: Context semantics for the Geometry of Interaction http://dvanhorn.lambda-calcul.us/2009/06/19/dilbert-context-semantics-for-the-geometry-of-interaction/ http://dvanhorn.lambda-calcul.us/2009/06/19/dilbert-context-semantics-for-the-geometry-of-interaction/#comments Fri, 19 Jun 2009 21:13:34 +0000 dvanhorn http://dvanhorn.lambda-calcul.us/?p=127 Code from the past couple of posts on context semantics is now available on Planet.

PLaneT Package Repository : PLaneT > dvanhorn > dilbert.plt

]]> http://dvanhorn.lambda-calcul.us/2009/06/19/dilbert-context-semantics-for-the-geometry-of-interaction/feed/ 0 Interacting with GoI Graphs http://dvanhorn.lambda-calcul.us/2009/06/17/interacting-with-goi-graphs/ http://dvanhorn.lambda-calcul.us/2009/06/17/interacting-with-goi-graphs/#comments Wed, 17 Jun 2009 20:07:22 +0000 dvanhorn http://dvanhorn.lambda-calcul.us/?p=119 Think of a program as a big graph, constructed out of the pieces of its syntax. Using λ-calculus syntax as an example: an application (@) links to its context and two subexpressions; an abstractions (λ) links to its expression context, subexpression, and variable binding; a bound variable occurrence links to its expression context and binder; and a free variable links to its context and leaves the other link “open”. There is a distinguished root link that provides the context link for the whole program.

The geometry of interaction is a semantics of these graphs. In GoI, which is a kind of game semantics, you interact with the graph at its open ports—the root or a free variable—by pushing in a vector of values, called a context. These values flow around the graph and a transformed vector is spit out at another open port. Think of this as a Q/A session. You ask the graph some question, coded in the language of contexts, and you get back an answer in contexts. But these Q/A interactions are reversible. It’s like Jeopardy, if you pump in an answer back into the graph, the question pops out from where it was originally pushed in.

You can think of GoI as a complete static analysis, capable of performing normalization; the normal form of a program can be recovered by a simple strategy of asking questions of the graph.

In the past, whenever I’ve wanted to examine the context semantics of something, I’ve had to take out paper, draw a graph, and calculate by hand. It’s a tedious and error-prone process. Also, some things I was still not quite sure about. In order to have a GoI calculator and to really confront the details of context semantics, I decided to write a Scheme macro for interpreting graphs. The macro takes a graph specification and compiles it into GoI object, represented as a Scheme function.

An object has a set of named ports. Applying the object to the name of a port, gives you back the port itself. The port is a function that consumes a context and produces a port and context. So for example, (F ‘πi) => πi and (πi c) => (cons πj c*). By the reversibility of GoI (πj c*) => (cons πi c).  Contexts are infinitely wide buses of values, represented as functions from natural numbers to contents of the indexed wire.

The graph for λs.λz.s(sz):

(define TWO
  (graph [(π1 ＊)]
         (λ  0 (＊ π1)   (π4 π2)   (π13 π3))
         (λ  0 (π2 π4)   (π7 π5)   (π27 π6))
         (@  0 (π10 π9)  (π5 π7)   (π20 π8))
         (@  1 (π18 π19) (π8 π20)  (π22 π21))
         (▵ 0 (π3 π13)  (π11 π12) (π15 π14))
         (s  0 (π12 π11) (π9 π10))
         (s  1 (π16 π17) (π19 π18))
         (~  0 (π14 π15) (π17 π16))
         (~  0 (π6 π27)  (π25 π26))
         (~  1 (π26 π25) (π23 π24))
         (z  2 (π24 π23) (π21 π22))))

Each clause in the graph corresponds to a node and its linkage is given. The ~-nodes are “brackets”, which manage sharing information, and the ▵-nodes are fans, in this case, fanning out the binding s to its two occurrences. Each node has a level (the given number), which represents the higher-orderness of that node’s sharing. This is assigned by a boxing strategy. These details can be found in Mairson, From Hilbert to Dilbert.

This macro use expands into the code given here.  Notice that links are implemented as recursive functions.  Traveling along a link in the graph is realized via a tail call. Here’s the transcript of an interaction with the graph TWO, reading back the normal form, λs.λz.s(sz):

;; Q: What's your head variable?
> (inter 2 TWO '＊ '((○ ○)))
;; A: The left occurrence of s.
(#<procedure:π1> ((● L . s) (○)))

;; Q: What's the head variable of its first argument?
> (inter 2 TWO '＊ '((● L . s) (● . α) (○)))
;; A: The right occurrence of s, in the box bound to α.
(#<procedure:π1> ((● R α . s) (○ ○)))

;; Q: And the head variable of its first argument?
> (inter 2 TWO '＊ '((● R α . s) (● . β) (○ ○)))
;; A: z, in the box bound to β, in the box bound to α.
(#<procedure:π1> ((○ ● α β . z) (○ ○)))

The inter function is a simple helper for injecting / projecting finite values into / out of a context.

Here is the graph macro itself:

;; A Graph   is a Symbol -> Port
;; A Port    is a Context -> (Pair Port Context)
;; A Context is a Nat -> WireVal
;; A WireVal is one of
;;   - empty                    Empty stack
;;   - (cons Token WireVal)     Non-empty stack
;;   - (cons WireVal WireVal)   Pairing (bracket)
;;   - '?, v
;;   - Symbol                   Variable name (croissant)
;; A Token is one of '● '○ 'L 'R

;; Syntax: (graph <interface> <node-spec> ...)

;; <interface> ::= [(x-in x-out) (y-in y-out) ...]

;; The *-out names given will be named ports (all other ports
;; are not visible outside a graph and can be obtained only
;; through interaction).  The first link is assumed to be the
;; root link, which every graph has.  The remaining links
;; represent remaining named, open ports.

;; <node-spec> ::= (λ  i (p1 p2) (w1 w2) (b1 b2))  Lambda
;;              |  (@  i (p1 p2) (w1 w2) (b1 b2))  Apply
;;              |  (▵ i (p1 p2) (w1 w2) (b1 b2))  Share
;;              |  (x  i (p1 p2) (a1 a2))          Croissant
;;              |  (~  i (p1 p2) (a1 a2))          Bracket
;;              |  ('v i (p1 p2))                  Constant
;;              |  (δ  i f (p1 p2) (a1 a2))        Primitive
;;              |  (⨀ i (p1 p2))                  Plug
;;              |  (⧻ f g (p1 p2) (p3 p4))        Chink

;; A node spec gives the level (i) of the node, its kind, and
;; a set of links for the node.  The number of links corresponds
;; to the arity of the node.  The order is always principal;
;; principal, auxillary; or principal, white, black.  Links are
;; direct from the outside into the node.

;; The ⧻-node is a "chink" in the graph.  It acts as an identity
;; but calls f with the context going left to right, and g with the
;; context going right to left, only for effect.  You can use IO
;; to observe a sub-interaction in the graph, like λf.f(f3) vs succ.
(define-syntax (graph stx)
  (syntax-case stx ()
    [(graph ([lr r] [lx x] ...) N ...)
     (let loop ((ns (syntax->list #'(N ...))) (bs null))
       (cond [(null? ns) #`(letrec ((r (λ (c) (cons lr c)))
                                    (x (λ (c) (cons lx c)))
                                    ...
                                    #,@bs)
                             (λ (π)
                               (case π
                                 [(r) lr]
                                 [(x) lx]
                                 ...
                                 [else (error "unknown port" π)])))]
             [else
              (syntax-case (car ns) (~ ⧻ ⨀ δ quote)
                ;; Ternary node
                [(kind i (l1 l2) (l3 l4) (l5 l6))
                 (with-syntax (((w b) (syntax-case #'kind (λ @ ▵)
                                        [λ #'(○ ●)]
                                        [@ #'(○ ●)]
                                        [▵ #'(L R)])))
                   (loop (cdr ns)
                         (list*
                          #'(l2 (λ (c)
                                  ((if (eq? 'w (car (c i))) l3 l5)
                                   (λ (n)
                                     (if (= n i)
                                         (cdr (c n))
                                         (c n))))))
                          #'(l4 (λ (c)
                                  (l1 (λ (n)
                                        (if (= n i)
                                            (cons 'w (c i))
                                            (c n))))))
                          #'(l6 (λ (c)
                                  (l1 (λ (n)
                                        (if (= n i)
                                            (cons 'b (c i))
                                            (c n))))))
                          bs)))]

                ;; Constant
                [('v i (l1 l2))
                 (loop (cdr ns)
                       (list*
                        #'(l2 (λ (c)
                                (l1 (λ (n) (if (= i n)
                                               (if (eq? (c i) '?) v '?)
                                               (c n))))))
                        bs))]

                ;; Primop
                [(δ i f (l1 l2) (l3 l4))
                 (loop (cdr ns)
                       (list*
                        #'(l2 (λ (c) (l3 (λ (n)
                                           (if (= i n)
                                               (f (c i))
                                               (c n))))))
                        #'(l4 (λ (c) (l1 (λ (n)
                                           (if (= i n)
                                               '?
                                               (c n))))))
                        bs))]

                ;; Chink
                ;; a narrow opening or crack, typically one that admits light
                [(⧻ f g (l1 l2) (l3 l4))
                 (loop (cdr ns)
                       (list*
                        #'(l2 (λ (c) (f c) (l3 (λ (n) (c n)))))
                        #'(l4 (λ (c) (g c) (l1 (λ (n) (c n)))))
                        bs))]

                ;; Bracket
                [(~ i (l1 l2) (l3 l4))
                 (loop (cdr ns)
                       (list*
                        #'(l2 (λ (c)
                                (l3 (λ (n)
                                      (cond [(< n i) (c n)]
                                            [(= n i) (car (c i))]
                                            [(= n (add1 i)) (cdr (c i))]
                                            [else (c (sub1 n))])))))
                        #'(l4 (λ (c)
                                (l1 (λ (n)
                                      (cond [(< n i) (c n)]
                                            [(= n i) (cons (c i) (c (add1 i)))]
                                            [else (c (add1 n))])))))
                        bs))]

                ;; Variable
                [(x i (l1 l2) (l3 l4))
                 (loop (cdr ns)
                       (list*
                        #'(l2 (λ (c)
                                (l3 (λ (n)
                                      (cond [(< n i) (c n)]
                                            [else (c (add1 n))])))))
                        #'(l4 (λ (c)
                                (l1 (λ (n)
                                      (cond [(< n i) (c n)]
                                            [(= n i) 'x]
                                            [else (c (sub1 n))])))))
                        bs))])]))]))
]]> http://dvanhorn.lambda-calcul.us/2009/06/17/interacting-with-goi-graphs/feed/ 0 GoI of a Church Numeral in Scheme http://dvanhorn.lambda-calcul.us/2009/06/17/goi-church-numeral/ http://dvanhorn.lambda-calcul.us/2009/06/17/goi-church-numeral/#comments Wed, 17 Jun 2009 08:03:22 +0000 dvanhorn http://dvanhorn.lambda-calcul.us/?p=117 The denotation of λs.λz.s(sz) in the geometry of interaction.

(letrec ((＊ (λ (c) (cons π1 c)))
         (π23
          (λ (c)
            (π21
             (λ (n)
               (cond
                ((< n 2) (c n))
                (else (c (add1 n))))))))
         (π22
          (λ (c)
            (π24
             (λ (n)
               (cond
                ((< n 2) (c n))
                ((= n 2) 'z)
                (else (c (sub1 n))))))))
         (π25
          (λ (c)
            (π23
             (λ (n)
               (cond
                ((< n 1) (c n))
                ((= n 1) (car (c 1)))
                ((= n (add1 1)) (cdr (c 1)))
                (else (c (sub1 n))))))))
         (π24
          (λ (c)
            (π26
             (λ (n)
               (cond
                ((< n 1) (c n))
                ((= n 1) (cons (c 1) (c (add1 1))))
                (else (c (add1 n))))))))
         (π27
          (λ (c)
            (π25
             (λ (n)
               (cond
                ((< n 0) (c n))
                ((= n 0) (car (c 0)))
                ((= n (add1 0)) (cdr (c 0)))
                (else (c (sub1 n))))))))
         (π26
          (λ (c)
            (π6
             (λ (n)
               (cond
                ((< n 0) (c n))
                ((= n 0) (cons (c 0) (c (add1 0))))
                (else (c (add1 n))))))))
         (π15
          (λ (c)
            (π17
             (λ (n)
               (cond
                ((< n 0) (c n))
                ((= n 0) (car (c 0)))
                ((= n (add1 0)) (cdr (c 0)))
                (else (c (sub1 n))))))))
         (π16
          (λ (c)
            (π14
             (λ (n)
               (cond
                ((< n 0) (c n))
                ((= n 0) (cons (c 0) (c (add1 0))))
                (else (c (add1 n))))))))
         (π17
          (λ (c)
            (π19
             (λ (n)
               (cond
                ((< n 1) (c n))
                (else (c (add1 n))))))))
         (π18
          (λ (c)
            (π16
             (λ (n)
               (cond
                ((< n 1) (c n))
                ((= n 1) 's)
                (else (c (sub1 n))))))))
         (π11
          (λ (c)
            (π9
             (λ (n)
               (cond
                ((< n 0) (c n))
                (else (c (add1 n))))))))
         (π10
          (λ (c)
            (π12
             (λ (n)
               (cond
                ((< n 0) (c n))
                ((= n 0) 's)
                (else (c (sub1 n))))))))
         (π13
          (λ (c)
            ((if (eq? 'L (car (c 0))) π11 π15)
             (λ (n) (if (= n 0) (cdr (c n)) (c n))))))
         (π12
          (λ (c)
            (π3
             (λ (n) (if (= n 0) (cons 'L (c 0)) (c n))))))
         (π14
          (λ (c)
            (π3
             (λ (n) (if (= n 0) (cons 'R (c 0)) (c n))))))
         (π19
          (λ (c)
            ((if (eq? '○ (car (c 1))) π8 π22)
             (λ (n) (if (= n 1) (cdr (c n)) (c n))))))
         (π20
          (λ (c)
            (π18
             (λ (n) (if (= n 1) (cons '○ (c 1)) (c n))))))
         (π21
          (λ (c)
            (π18
             (λ (n) (if (= n 1) (cons '● (c 1)) (c n))))))
         (π9
          (λ (c)
            ((if (eq? '○ (car (c 0))) π5 π20)
             (λ (n) (if (= n 0) (cdr (c n)) (c n))))))
         (π7
          (λ (c)
            (π10
             (λ (n) (if (= n 0) (cons '○ (c 0)) (c n))))))
         (π8
          (λ (c)
            (π10
             (λ (n) (if (= n 0) (cons '● (c 0)) (c n))))))
         (π4
          (λ (c)
            ((if (eq? '○ (car (c 0))) π7 π27)
             (λ (n) (if (= n 0) (cdr (c n)) (c n))))))
         (π5
          (λ (c)
            (π2
             (λ (n) (if (= n 0) (cons '○ (c 0)) (c n))))))
         (π6
          (λ (c)
            (π2
             (λ (n) (if (= n 0) (cons '● (c 0)) (c n))))))
         (π1
          (λ (c)
            ((if (eq? '○ (car (c 0))) π4 π13)
             (λ (n) (if (= n 0) (cdr (c n)) (c n))))))
         (π2
          (λ (c)
            (＊
             (λ (n) (if (= n 0) (cons '○ (c 0)) (c n))))))
         (π3
          (λ (c)
            (＊
             (λ (n)
               (if (= n 0) (cons '● (c 0)) (c n)))))))
  (λ (π)
    (case π ((＊) π1) (else (error "unknown port" π)))))
]]> http://dvanhorn.lambda-calcul.us/2009/06/17/goi-church-numeral/feed/ 1 RaList: Purely Functional Random-Access Lists http://dvanhorn.lambda-calcul.us/2009/05/18/ralist-purely-functional-random-access-lists/ http://dvanhorn.lambda-calcul.us/2009/05/18/ralist-purely-functional-random-access-lists/#comments Tue, 19 May 2009 00:34:03 +0000 dvanhorn http://dvanhorn.lambda-calcul.us/?p=92 dvanhorn > ralist.plt ]]> Random-access lists (Okasaki, FPCA ‘95) are a purely functional data structure for representing lists of values. A random-access list may act as a drop in replacement for the usual sequential list data structure (cons?, cons, car, cdr), which additionally supports fast index-based addressing and updating (list-ref, list-set).

PLaneT Package Repository : PLaneT > dvanhorn > ralist.plt

]]> http://dvanhorn.lambda-calcul.us/2009/05/18/ralist-purely-functional-random-access-lists/feed/ 0 Scheme Workshop and Wand Festschrift http://dvanhorn.lambda-calcul.us/2009/05/18/scheme-workshop-and-wand-festschrift/ http://dvanhorn.lambda-calcul.us/2009/05/18/scheme-workshop-and-wand-festschrift/#comments Mon, 18 May 2009 22:40:23 +0000 dvanhorn http://dvanhorn.lambda-calcul.us/?p=87 The firm deadline for the Scheme and Functional Programming Workshop is approaching.  The workshop is going to be held at MIT in August in conjunction with the Symposium in Honor of Mitchell Wand.

Update: the preliminary program can now be found here.

]]> http://dvanhorn.lambda-calcul.us/2009/05/18/scheme-workshop-and-wand-festschrift/feed/ 0