posted by Eli Barzilay

It’s been one too many times that I hear respectable Schemers talk about how they like explicit renaming macros — not because they’re more powerful, but because using them is close to using simple defmacros. In this post I’ll show how you can easily write ER-like macros in PLT, just so I won’t need to explain the same thing once again.

Disclaimers:

• If you’re not interested in ER-macros, then you shouldn’t read this.

• I’m not claiming that ER macros are not respectable, I’m just surprised at the knee jerk reaction to syntax-case.

• This is not an attempt at providing some portable library or even a PLT library. The intention is to show that syntax-case-style macros are “as convenient” as ER macros, if you really want to get down to that level.

• This is also not an attempt at any kind of formal claim of equivalence in any direction, only a demonstration that you can get the same kind of convenience.

• The bottom line here should be just the convenience point, addressed at people who like ER macros for that, and who think that syntax-case macros are somehow magical or that you lose the ability to play with S-expressions.

The important fact here is that while PLT’s syntax-case macro system does not give you raw S-expressions, what you get is a simple wrapper holding them. A macro is a syntax transformer: a function that consumes a syntax value and returns one. For example:

(define-syntax (foo stx)
    #'123)

is a macro that always expands to 123 (with #'123 being the usual shorthand for (syntax 123)).

A syntax object in PLT Scheme (the input to macro functions) is an S-expression, with some lexical information added — this includes the lexical context (in an opaque form), source location, and a few more things. To be more precise, a syntax value is a nested structure of wrappers holding lists and pairs, holding more wrappers, with identifiers at the leaves, where an identifier is a wrapper holding a symbol. It’s easy to strip off all wrappers using syntax->datum if you like to work with S-expressions, but you don’t want to strip it off of identifiers, since that will lose the important gravy. (In fact, the defmacro library works by stripping off all information, even from identifiers, then reconstructing it by trying to match names in the output form with the original input.)

Instead of throwing away all information, what we want to do is preserve identifiers. We can use syntax->list for this: this is a function that takes a syntax value that contains a list, and strips off the top-level extra information leaving you with a list of syntaxes for the sub-expressions (returning #f if the input syntax does not hold a list). Once we have such a list, we can do the usual kind of processing with it, and when we’re done turn the result back into a syntax using datum->syntax (which “borrows” the original input expression’s information). For example,

(define-syntax (add1 stx)
    (let ([+ #'+])
      (datum->syntax stx `(,+ 1 ,@(cdr (syntax->list stx))) stx)))

That’s a very simple example though; if you try something a little more complicated, you quickly find out that all this unwrapping is inconvenient:

(define-syntax (mylet stx)
    (let ([*lambda #'lambda])
      (datum->syntax
       stx
       `((,*lambda ,(map (lambda (x) (car (syntax->list x)))
                         (syntax->list (cadr (syntax->list stx))))
                   ,@(cddr (syntax->list stx)))
         ,@(map (lambda (x) (cadr (syntax->list x)))
                (syntax->list (cadr (syntax->list stx)))))
       stx)))

(Note also the *lambda that is used to avoid the lambda expressions used in the meta-code.)

What can help here is some helper function that receive a syntax value as its input, and turn all wrapped lists into real lists recursively, but will leave identifiers intact:

    (define (strip stx)
      (let ([maybe-list (syntax->list stx)])
        ;; syntax->list returns #f if the syntax is not a list
        (if maybe-list (map strip maybe-list) stx))))

But as long as we’re writing a syntax utility, we can make it do a litte more work: feed the resulting tree to your transformer, grab its result, and do the necessary datum->syntax voodoo on it:

(begin-for-syntax
    (define (er-like-transformer transformer)
      (define (strip stx)
        (let ([maybe-list (syntax->list stx)])
          ;; syntax->list returns #f if the syntax is not a list
          (if maybe-list (map strip maybe-list) stx)))
      (lambda (stx)
        (datum->syntax stx (transformer (strip stx)) stx))))

With this utility defined, the above macro becomes much easier to deal with:

(define-syntax mylet
    (er-like-transformer
     (lambda (exp)
       (let ((vars  (map car (cadr exp)))
             (inits (map cadr (cadr exp)))
             (body  (cddr exp)))
         `((,(syntax lambda) ,vars ,@body)
           ,@inits)))))

…and this is almost identical to the explicit renaming version of the macro; for example, compare it with the sample code in the MIT-Scheme manual. The only change is that (rename 'lambda) is replaced with (syntax lambda).

Obviously, this is very close, but doesn’t show intentional captures. So I just grabbed the loop example from the same page, and did the same change — only this time I used #'foo instead of (syntax foo) (and I also changed the one-sided if to a when). The resulting macro works fine:

(define-syntax loop
    (er-like-transformer
     (lambda (x)
       (let ((body (cdr x)))
         `(,#'call-with-current-continuation
           (,#'lambda (exit)
            (,#'let ,#'f () ,@body (,#'f))))))))
  
  (define-syntax while
    (syntax-rules ()
      ((while test body ...)
       (loop (when (not test) (exit #f))
             body ...))))
  
  (let ((x 10))
    (while (> x 0)
      (printf "~s\n" x)
      (set! x (- x 1))))

This is pretty close to a library, and indeed, as I was writing this text I found a post by Andre van Tonder on the Larceny mailing list that uses a very similar approach and does make a library out of it. This is done by adding two arguments to the expected ER-transformation function — one is a rename function (since the above method uses syntax it is limited to immediate identifiers), and the other is always passed as free-identifier=?. Such a compatibility library is, however, not the purpose of this post.

Finally, there is still a minor issue with this — PLT has an implicit #%app which is used wherever there are parentheses that stand for a function application — and in this code they are used unhygienically. This is usually not a noticeable problem, and if it is, you can add explicit #%apps. It might also be possible to find a more proper solution (e.g., use a hash table to keep track of lists that were disassembled by the client transformer), but at this point it might be better to just use the more natural syntax-case anyway.

posted by Jay McCarthy

One of the annoyance of the stateless Web application language that comes with the PLT Web Server is that you can’t call third-party higher-order library procedures with arguments that try to capture serializable continuations. (I know, you try to do that all the time.) For example:

(build-list
 3
 (lambda (i)
   (call-with-serializable-current-continuation
    (lambda (k) (serialize k)))))

The problem is that the stateless language performs a transformation on your program to extract the continuations into a serializable representation. If you really need to do this, we’ve developed a compromise called “The Two State Solution”: one state on the client and the other on the server. Only the third-party parts of the continuation (in this case, the code inside build-list) are stored on the server; everything else is shipped to the client. You just need to annotate your code slightly to indicate where the transition is:

(serial->native
 (build-list
  3
  (lambda (i)
    (native->serial
     (call-with-serializable-current-continuation
      (lambda (k) (serialize k)))))))

serial->native signals the transition to the third-party and native->serial signals the transition back.

It is still a little annoying to find when you’ve called these third-party higher-order library procedures with arguments that try to capture serializable continuations, so there’s a simple macro that provides a transitioning wrapper for you:

(define-native (build-list/native _ ho) build-list)

expands to:

(define (build-list/native fst snd)
  (serial->native
   (build-list
    fst
    (lambda args
      (native->serial
       (apply snd args))))))

This new feature is documented in the online manual, of course.

posted by Jay McCarthy

Many Web applications and network protocols have values in the continuation that are necessary to complete the computation, but that may be recomputed if they are not available. This is “soft state”.

For example, a Web application may cache a user’s preferences from a database and deliver it to a Web browser as a hidden value; when the value is returned to the application in subsequent steps, it is used to customize the display. However, if the preferences were not available (or were corrupted in some way), the application could retrieve them from the database.

When using the PLT Web Server’s native continuations, this roughly corresponds to the use of a weak box: a box that the GC is allowed to erase the contents of. When using the PLT Web Server’s serializable continuations it roughly corresponds to a weak box and a weak hash table (that holds its keys weakly) to give the box a serializable value as an identifier.

This programming pattern is a bit difficult to get right. So, a library that implements it is now provided with PLT Scheme: web-server/lang/soft.

Here’s a trivial example:

#lang web-server

(provide interface-version start)
(define interface-version 'stateless)

(define softie
  (soft-state
   (printf "Doing a long computation...~n")
   (sleep 1)))

(define (start req)
  (soft-state-ref softie)
  (printf "Done~n")
  (start
   (send/suspend
    (lambda (k-url)
      `(html (body (a ([href ,k-url]) "Done")))))))

posted by John Clements

We’re holding the line on our submission deadline; it’s still June 5, so that gives you about three weeks to write something awesome.

Re-posting the entire CfP on a blog seems a bit tacky, so instead I’ll just post the link:

http://blog.plt-scheme.org/2009/01/cfp-scheme-workshop–2009.html

We look forward to your submissions!

posted by Jay McCarthy

I often ponder what send/suspend really is. It is a lot like call/cc, but has the curious property that the continuation escapes in a single way and is only called in a particular context. I often wonder if there is something weaker than call/cc that implements send/suspend.

Today I wrote a little dispatcher that uses threads to implement send/suspend. In this implementation, _send_ing truly _suspend_s the computation.

Here’s the code: http://www.copypastecode.com/codes/view/5003

The trick is to have channels for communicating responses and requests. When you run this example, you should be able to add two numbers. But, in contrast to the normal send/suspend, all the URLs are one-shots, because once the computation is resumed, it moves forward… it is never saved.

This implementation technique also precludes clever implementations of send/suspend/dispatch, like:

(define (send/suspend/dispatch mk-page)
  (let/cc k0
    (send/back
     (mk-page
      (lambda (handler)
        (let/ec k1 
          (k0 (handler (send/suspend k1)))))))))

posted by matthias

Dear old Lisper,

You have found drscheme and it is almost like your old Lisp machine. It is easy to program in it, it has things that nobody else has, and we all love parentheses. But after some initial enthusiasm you are wondering why in the world, we decided not to provide commands for sending individual definitions and expressions from the Definitions window to the Interactions window, aka, REPL.

It wasn’t an accident. It was by design after some difficult experiences. I am personally a product of the Emacs world that you are describing below, and my advisor Dan Friedman was called the “Lispman” on his door sign at Indiana.

When I first discovered the idea of sending individual expressions and definitions from a buffer to a repl, it was a near-religious revelation to me. I wanted everyone to know this trick and use it. When I started teaching the freshman course at Rice, I told our chairman so and he asked “why”. I was shocked, awed, and I failed to explain to him how it mattered. He was a mathematician and I wrote it off. They don’t know.

Then I started watching my sophomores and juniors at Rice in lab. Now that was a true disappointment. Few if any used this trick and when they did, they more often tripped up and got the repl into a state where they didn’t know what was going on.

In the mid 90s, I wrote some more Little books with Dan, and boy, time and again, I watched him stumble across the state of the repl. I even watched him re-start the repl and load the whole buffer more often than not.

Why? In the presence of macros and higher-order functions and other beasts, it is difficult for masters of the universe with 30 years of experience to keep track of things. What do you think students with 10 or 20 days worth of experience will do? Is it really such a deep principle of computing to create the objects incrementally in the repl as opposed to thinking systematically through the design of a program?

I decided not and asked Robby to make DrScheme’s repl transparent. That is, it re-starts the repl and re-loads the buffer every time. I consider this behavior a suitable compromise: have a repl but don’t confuse yourself with send-defs and send-exprs. This is especially true in an age when sending an entire buffer takes as much time as sending an individual expression or definition. Soon we’ll get “compilation behind your back” so that only the current buffer is re-interpreted. It’ll start things even faster.

Even though I had used the incremental mode for more than a decade when I switched from Emacs to DrScheme in 1998, I have hardly ever looked back. I miss a few other things but the incremental repl is one of those rituals old Lispers acquired and never questioned … but it isn’t fundamental and critical to anything. (Note there is no qualifying clauses, no when no if no but. I really mean this last sentence the way I spelled it.)

posted by Eli Barzilay

PLT Scheme version 4.1.5 is now available from http://plt-scheme.org/

• Web Server:
  • new URL-based dispatching library web-server/dispatch,
  • customizable continuation serialization policies for the stateless web language web-server/stuffers,
  • abstraction of serve/servlet to build simpler dispatchers web-server/servlet-env,
  • HTTP Digest authentication support web-server/http/digest-auth,
  • built-in cookie support in web-server/http/cookie and web-server/http/cookie-parse,
  • highlighting and pretty-printing of errors in Xexpr constructions,
  • load control dispatcher for limit concurrent sessions web-server/dispatchers/limit.
• Scribble:
  • Literate programming is now available using the new scribble/lp language.
  • A new at-exp language makes it convenient to use the scribble reader’s @-expressions for general code.
  • The scribble/text preprocessor language has been extended to deal with indentation and other formatting issues.
  • The “scribble” command-line tool accepts a --pdf flag to render PDFs (via pdflatex).

• DrScheme now provides feedback when PLaneT downloads and installs new packages.

• Units & Contracts:
  • Elements of unit signatures can now be associated with contracts via the contracted signature form.
  • A contract combinator for units, unit/c, has been added.
  • The new with-contract form provides a nestable submodule contract boundary, protecting a group of definitions from the surrounding code with contracts.
  • The define/contract form has been reworked and new define forms have been added: define-struct/contract and define-unit/contract.

• Language levels and teachpacks from the DeinProgramm project for the German textbook “Die Macht der Abstraktion” by Herbert Klaeren and Michael Sperber have been added.

• Misc:
  • Typed Scheme now comes with several more pre-wrapped libraries, found in the typed collection.
  • The xml and html collections are now contracted.
  • Binding parsing in net/cgi now interacts with net/uri-codec’s configuration parameters.
  • DrScheme captures logging output.
  • Check syntax: it is now possible to tack arrows crossing the currently selected text.
  • New bitwise-bit-field function.
• The usual pile of bugfixes. (Notable: scheme/package works, deflate compression fixed, DrScheme language dialog issue resolved, match fixes, Windows networking, and much more.)

[Note that mirror sites can take a while to catch up with the new downloads.]

Feedback Welcome.

posted by Carl Eastlund

PLaneT packages may refer to themselves (i.e. include module paths referring to some part of the same package) for a number of reasons. One module may require another. Scribble documentation traces for-label imports to construct hypertext links. DrScheme language levels may provide a module path for an initial namespace.

In each of these cases, we want the module path to refer to the same version of the same package that it occurs in. On the other hand, we do not want to have to manually search and replace the version number every time we update. Before I solved this problem I would often release some new version x.0 of a package, only to find some lingering dependency on y.0 that my search/replace had not caught. Of course, then I had to go back and replace all occurrences of both x.0 and y.0 with x.1 and release again. To avoid this headache, we need a way to express self-referential module paths with precise, implicit version numbers.

The built-in module paths don’t quite support this. The relevant forms are PLaneT paths with version numbers, PLaneT paths without version numbers, and relative paths:

(planet my/package:1:0/dir/file)
(planet my/package/dir/file)
"../dir/file.ss"

PLaneT paths with version numbers suffer from the search and replace problem: they become obsolete, and must be changed with every new release.

PLaneT paths without version numbers “upgrade” with a new release: they automatically refer to the latest version of a package. Unfortunately, this means they aren’t really “self”-references. As soon as version 2.0 is released, every version-free reference to the package refers to 2.0. Even the references in version 1.0 get implicitly updated, and become forward references rather than self-references.

Relative paths are precise, in that they always refer to the same version of the same package. However, because they implicitly refer to the directory containing the source code, they are only valid within a single file. They cannot be reliably passed to DrScheme for a language level namespace, traced for documentation links by Scribble, or used by other such external tools.

None of these options provides precise, stable, externally comprehensible, self-referential module paths.

To fill this need, I have released (planet cce/scheme:4:1/planet). This module provides PLaneT package authors with several macros that construct references to the current package in require imports, Scribble documentation, and dynamic values. The self-referential modules paths are constructed automatically at compile time based on the source location of the macro use and the local PLaneT package database. Their expanded form always includes an explicit package name and version number (both major and minor). Here I will summarize their use, with (planet my/package:1:0/dir/file) as a running example. For full details, see the online documentation or install the package.

To import a module from within a PLaneT package, use the this-package-in require transformer. To re-export bindings from a module imported this way, use the this-package-out provide transformer, or use require/provide/this-package in place of both.

For example, you might want to import and re-export bindings from dir/file:

(require (planet my/package:1:0/dir/file))
(provide (all-from-out (planet my/package:1:0/dir/file)))

You can leave out the package name and version number, thus making the code invariant across upgrades, by writing:

(require (this-package-in dir/file))
(provide (this-package-out dir/file))

Or, you can further simplify it:

(require/provide/this-package dir/file)

All three of the above are equivalent (in version 1.0).

In Scribble documentation, a module often refers to itself via defmodule, declare-exporting, or schememodname. I provide the extensions defmodule/this-package, declare-exporting/this-package, and schememodname/this-package, respectively. These macros allow the user to supply a path such as dir/file, or to omit one to refer to the package as a whole (or its main module). In positions where the original macros allow a sequence of module paths, these forms allow two sequences, one for self-referential module paths and one for other paths.

To document an entire module, one might first write:

(defmodule (planet my/package:1:0))

The automatic self-reference version is simply:

(defmodule/this-package)

In more complicated cases, one might document a sub-part of a package or present bindings from multiple sources:

(defmodule (planet my/package:1:0/dir/file)
  #:use-sources
  [(planet my/package:1:0/private/impl) somewhere/else])

These self-references can still be automated:

(defmodule/this-package dir/file
  #:use-sources
  [private/impl]
  [somewhere/else])

Finally, I provide this-package-version-symbol for constructing PLaneT package symbols as runtime values. This macro is analogous to this-package-version from the planet/util collection, but it constructs a symbol rather than an s-expression. You can use this symbol to construct a module path for a DrScheme language level, or escape it with unsyntax in Scribble’s schemeblock typesetting to create self-referential example code.

This list of utilities may not be complete. Users may need to write new macros for self-referential PLaneT packages. To that end, (planet cce/scheme:4:1/syntax) provides syntax-source-planet-package. This function is analogous to this-package-version, but operates on syntax objects and is designed to be used in macro transformers. There are also -owner, -name, -major, -minor, and -symbol versions following the same analogy.

I find these tools useful for maintaining my PLaneT packages, and I hope other authors will too. If you do give them a try, please send feedback on what does or doesn’t work, or what might be improved. I would eventually like to add a refined version to the PLT Scheme collections once we get enough experience to know that these tools are fairly complete and usable.

posted by Sam Tobin-Hochstadt

Typed Scheme is a language for writing PLT Scheme programs that are statically checked for type errors. Right now, Typed Scheme handles a large portion of the PLT Scheme language. However, to use Typed Scheme effectively, we need libraries that work with it. For this task, we’re looking for help.

We’d like volunteers for writing wrapper modules that adapt untyped libraries to Typed Scheme. This task is very easy for the smallest libraries, but can be much more complicated for larger, complex libraries.

There’s a preliminary guide for conversion here and a list of modules to adapt, and their current status is available here.

Questions about this project, and about developing with Typed Scheme in general, can be asked on plt-dev@list.cs.brown.edu , and questions or comments can be sent directly to me.

We hope to continue making Typed Scheme into a useful tool for PLT Scheme programmers.

Thanks,

Sam, Stevie, and Matthias

posted by matthias

Election time is here again. A couple more days and the Scheme community will have a set of new steer-ers.

What should we want from a steering committee?

I have argued at this place before that good language design needs a feedback loop. Language designers write down specs; language implementers translate those specs into compilers and interpreters; programmers use these implementations to produce useful software. The loop comes in when implementers inform designers of flaws, inconsistencies, mistakes, errors, and other internal consistency problems in the specs. This is clearly happening with R6RS, and it is good. Implementers are a biased bunch, however. After all, they work on just one kind of program, and in a highly specialized domain that has been mined for a long time. How can you trust them? [*]

The loop becomes truly useful when people write large software systems (not just compilers, because they really are special cases!) and find that the language fails them in some way. Such failures can come in a number of flavors. For a document such as R6RS, we should hope that programmers can discover problems with porting systems that are apparently due to ambiguities, flaws, mistakes, roaches in the actual document (as opposed to a specific implementation).

So what does this have to do with the steering committee?

The last thing we want from a steering committee is a radical commitment to change (whatever it may be); a prejudice concerning R6RS; a closed mind about the size of “Scheme” (it’s too large, it’s too small); a willingness to steer without making observations. A steering committee of overbearing curmudgeons is not what we want.

What we do want is a committee that is willing to figure out how the listening is going to happen; how we can possibly finance a systematic way of listening (writing NSF grants, anyone?); how the feedback is best channeled into language design.

Let’s hope we get such a steering committee. The Scheme community deserves it.

[*] No I am not naive enough to think that language implementers don’t design languages, and that implementers don’t program systems other than implementations. I am just skeptical that it is easy for them to separate out their various roles in an objective manner, even if many of them are able to think at several different levels about programs.