19 Jun 2015

Racket v6.2

posted by Ryan Culpepper

Racket version 6.2 is now available from http://racket-lang.org/

With this release we are taking a major step forward to get our user community even more involved than in the past. Over the past six months, we have re-organized the Racket code base into a small core code repo and many other package repos, all found on GitHub. If you have time and if you wish to get involved, please take a look at the GitHub repos and find your favorite places to learn, fix, and enhance our world.

The core repo is at https://github.com/plt/racket, and the package repos are listed at https://github.com/racket/.

core repo

  • The package manager supports a direct references to Git repositories via “git://[…]”, “http://[…].git”, and “https://[…].git” URLs. (Previously, only references to GitHub were supported.)

  • A --clone option for raco pkg install or raco pkg update facilitates Git-based package development. If a package X has a Git repository source, installing and updating the package pulls from the repository in a read-only mode. Using raco pkg update --clone X switches the local installation to a repository checkout that is suitable for modifying the package implementation, issuing pull requests, pushing changes, and so on.

Using raco pkg update --lookup X switches the package back to the default installation mode.


  • Its on-line check syntax works with graphical content.

  • Increased availability of DrRacket’s blueboxes, including method and constructor information.

  • The “Open Require Path” menu item supports ".." in relative pathnames.


  • Added data/enumerate, a library that supports efficient enumeration of data structures


  • Its redex-check facility uses data (in addition to random) enumeration to try to find counter-examples.

  • Its generate-term function accepts additional arguments to return the “i”-th member of a pattern using data/enumerate (meaning it efficiently supports very large values of “i”).

  • The examples collection includes Launchbury’s 1993 big-step lazy semantics.


  • 2htdp/image’s polygon may be built out of bezier curves instead of just straight lines (see the docs for pulled-point).

  • 2htdp/abstraction is a teachpack for instructors and students who wish to use for/* loops, match, define-type and type-cases in ISL and ISL+.

  • 2htdp/universe programs can be exported using DrRacket’s executable creation mechanism and they behave properly when run independently.


  • Typed Racket in DrRacket displays tooltips that show the types of expressions. Tooltips are also displayed for type errors.

  • Typed Racket loads generated contracts only when needed. This reduces memory use and startup time for Typed Racket programs.

  • Typed Racket has improved support for prefab structures, future semaphores, and async channels.

  • Typed Racket understands when two different variables refer to the same thing, and updates types accordingly. This particularly improves the type checking of macros such as match.

Feedback Welcome

more →

03 May 2015

King of the Hill on Rosetta Code

posted by Tim Brown

Racket is “King of the Hill” on Rosetta Code: This announcement is a follow up to “800!”.

In it I said we’d "[S]ee you at 1000!"; but you’ll understand why we stopped at this milestone.

Please read that article if you need an introduction to Rosetta Code, and the efforts being made to implement Racket tasks there, and more detail on how you can help. It is more instructive and less braggart than this post.

On Rosetta Code (RC), early in the morning on April 29th, Racket drew level with Tcl in the number of tasks that had been implemented for it. Shortly after that we could announce that:

Racket has the Most Tasks Implemented in Any Language on Rosetta Code!

Before I go into too much detail, it must be said that this is another amazing achievement. I, and I’m sure the rest of the Racket community, want to thank and congratulate everyone who has contributed to this effort.

How Did This Happen?

On the front page of RC’s site, it states its goal as:

… to present solutions to the same task in as many different languages as possible, to demonstrate how languages are similar and different, and to aid a person with a grounding in one approach to a problem in learning another.

As well as achieving these comparative goals, implementing tasks also provides a useful library of tools, applications and examples for Racket users themselves. Therefore, doing so is a laudable activity in its own right. The persistent effort and progress have been made by Racketeers on RC, both before and since the “800!” tasks post has been (mostly) performed in that spirit. And that should be plenty enough incentive for you to do so, too.

But I admit, there is a competitive element that creeps in (affecting some more than others). After having passed the 800 task mark after spending so much time in second place to get past the current leader, Tcl to stay ahead of Python these, too, provide plenty of motivation to implement tasks. And if winning isn’t important, why, then, do we keep score?

And in that spirit, early in the morning on April 29th, I was busily [cherry-picking] [2] tasks on Rosetta Code to help close the gap with Tcl; when I thought I would take a quick check on Tcl’s and Racket’s [task counts][3]. From what I could see, both had a task count of 845! Racket had drawn level with, Tcl as the Joint Most Popular Programming Language on RC.

I got the independent verification of this from the #racket [IRC Channel][4]. It was true! But Racket was only joint first. This point was not lost on the denizens of IRC (zedoary being one); who posted two more tasks in very quick succession, bringing Racket up to 847 — two clear of the previous leader!

How does this Help Racket? —

Plenty of Examples Look back at the intentions of Rosetta Code itself. It is expected that users of other languages can come and compare what they know with what Racket provides. Strictly speaking, of course, in a lot of cases they won’t be able to compare since the other language won’t be represented whereas Racket will.

There is also, now, a large collection of Racket examples, which Racketeers themselves can use to improve their understanding of Racket. Strangely, this is not actually one of the stated objectives of RC; it is a welcome side-effect of the work.

A Tool for Advocacy Advocates of Racket can use this position on Rosetta Code to show that Racket is as, if not more, capable than any language. Especially for general purpose computing.

“Racket is Number One on Rosetta Code” isn’t a bad place to start with, I guess.

Additionally, I would like to point out that whatever any of the other languages (or tasks) seem to throw at it, there is something in Racket that allows it to take it in its stride. Sometimes the implementations have had high [line counts][5]; but they rarely, if ever, seem contrived.

If you need to provide reasons for tasks not being implemented in Racket, here are a few you can use:

  • Nobody has implemented them “yet”: let it be known that we’ve done the best part of 850 tasks, and there are only so many hours in the day.

  • Someone has written an FFI for Tcl to an obscure library: The task for Tcl has then simply been to load the FFI. The task for Racket is either to a) implement the library, which is much more effort than Tcl put in or b) to produce FFI bindings itself, which after the first time doesn’t bring much to the party. The same holds true for tasks written for languages which are basically DSLs, showing off how they work in domain for which they are specific.

  • The task is written and documented entirely in Russian: This makes translating it an “exercise.”

Is it Time to Rest on our Laurels?

That was a rhetorical question.

Please ignore it.

There are many reasons to continue to work on Rosetta Code.

We Haven’t Finished

Implement Some Outstanding Tasks!

There are 922 tasks on Rosetta Code. 849 are implemented in Racket (more have been added as we speak)! Even excluding the impossible and Russian tasks, that’s still many more tasks to implement.

Improve Existing Tasks!

Some tasks are old, and lack style. Some may even be re-branded Scheme tasks. Anyone can edit these tasks. Add style to them. Tasks can then not only be an example of how to use the syntax and features of Racket, but also exemplars of well-written code.

Propose New Tasks!

There are things that Racket and other Lisps do well that haven’t been illustrated on RC. How about the fancier macro facilities that Racket provides?

I’m sure you can think of something. Might you suggest something involving anaphoric macros?

Oh, and if you do suggest something, maybe you can implement it, too!

They Haven’t Finished

New Tasks are Being Invented!

Tasks are being added to Rosetta Code constantly. Keep an eye out, some of these are really quite interesting.

Tasks are Being Implemented!

Tcl and Python (and maybe others in the future) will want what we have earned here, and they are going to continue to propose and implement tasks. “King of the Hill” is a precarious place. The more clear blue water between us and them Just do it! Buy glucose sports drinks

Maybe I am getting too competitive.

Finally —

Once again, many thanks to the people who have contributed to Racket on Rosetta Code. Including those who have answered questions on the mailing list or IRC. Your help has been invaluable even if the questions made you wonder “why on earth does he or she want to do that?

Finally, but certainly not least: Thanks to the folk at Rosetta Code. They’ve provided a site and experience which have been instructive, educational and fun; and without whom none of this would have been possible.

is also doing magnificently well, to be sure. It even had the audacity to draw level with Racket according to the FUPPLR a couple of times.

[2] A good way to start on Rosetta Code is to find tasks that are easy to implement. In order to find easy tasks you will need to browse the unimplemented tasks (and maybe some implemented ones, too) and decide what you could either implement and/or translate without breaking too much of a sweat. In the process you will also develop a sense of what tasks are out there ready to be implemented. A good example of an easy task would have been Pentagram.

[3] There is a Frequently Updated Popular Programming Languages Report, which I refer to but recently it has been miscounting tasks, and needs a bit of a look at.

[4] The #racket IRC channel is a fantastic community if you need support with your Racket issues

[5] Remember that Rosetta Code is not a Golf site. If it were, J’s weird 20-character-strings-that-do-anything (if only you could remember what they do 30 seconds after you’ve written them) would win hands down. Keep to the Style Guide as best you can. And since RC is a wiki, if you’re not perfect, others can improve the style of your code.

more →

20 Apr 2015

Scheme Workshop 2015

posted by Ryan Culpepper

Call For Papers:

Scheme and Functional Programming Workshop 2015

Vancouver, British Columbia, Canada

(Co-located with ICFP 2015)


Submissions related to Scheme, Racket, Clojure, and functional programming are welcome and encouraged. Topics of interest include but are not limited to:

  • Program-development environments, debugging, testing

  • Implementation (interpreters, compilers, tools, benchmarks, etc.)

  • Syntax, macros, hygiene

  • Distributed computing, concurrency, parallelism

  • Interoperability with other languages, FFIs

  • Continuations, modules, object systems, types

  • Theory, formal semantics, correctness

  • History, evolution and standardization of Scheme

  • Applications, experience and industrial uses of Scheme

  • Education

  • Scheme pearls (elegant, instructive uses of Scheme)

We also welcome submissions related to dynamic or multiparadigmatic languages and programming techniques.

Important Dates:

May 22nd, 2015 - Paper deadline

June 26th, 2015 - Author notification

July 19th, 2015 - Camera-ready deadline

September 4th, 2015 - Workshop

Submissions must be in ACM proceedings format, no smaller than 9-point type (10-point type preferred). Microsoft Word and LaTeX templates for this format are available at: http://www.acm.org/sigs/sigplan/authorInformation.htm

Submissions should be in PDF and printable on US Letter.

To encourage authors to submit their best work, this year we are encouraging shorter papers (around 6 pages, excluding references). This is to allow authors to submit longer, revised versions of their papers to archival conferences or journals. Longer papers (10—12 pages) are also acceptable, if the extra space is needed. There is no maximum length limit on submissions, but good submissions will likely be in the range of 6 to 12 pages.

More information available at: http://andykeep.com/SchemeWorkshop2015/


Andy Keep, Cisco Systems Inc. (General Chair)

Ryan Culpepper, Northeastern University (Program Chair)

(Apologies for duplications from cross-posting.)

more →

10 Dec 2014

The Racket package system and PLaneT

posted by Jay McCarthy

We have recently moved the majority of Racket’s code base into packages and repositories separate from the main core repository. This has given the Racket package system another cycle of attention. Whenever this happens, there are often questions and confusion about how to solve various distribution problems with the package system. A natural point of comparison is the older PLaneT system provided by Racket that appears to solve similar problems. In this blog post, I attempt to explain the purpose of the package system and its relation to PLaneT.

The package system and PLaneT do not solve the same problem and don’t exist for the same reason.

PLaneT is:

  • A file distribution mechanism for source code.

    Via .plt files that are installed into a particular place on your machine and then raco setup’d.

  • A mechanism for automatically downloading and installing source code just before it is needed by programs.

    Via the (planet ...) require form.

  • A centralized database of libraries

    Via the PLaneT website and its server & protocol which were undocumented and proprietary for the majority of PLaneT’s life

  • A prescriptive model of how programs and libraries should be composed.

    Specifically the system of major/minor versions, tagging packages by author name, and embedding the names of packages in source code.

In contrast, the package system is:

  • A file distribution mechanism for source code, byte code, and documentation. Via the raco pkg command.

In this way, the package system is almost identical to an operating system package system like Debian’s dpkg and apt systems. The problem is very finely tailored and becomes more flexible as a result (notice that we can now distribute byte code and documentation.) This design aspires to follow the admonition of holy writ: “Programming languages should be designed not by piling feature on top of feature, but by removing the weaknesses and restrictions that make additional features appear necessary.”

Furthermore, it was intended to solve practical problems throughout the Racket ecosystem. In particular, one of the common complaints people had and have about PLaneT is the very long install times because of long builds. The package system allows this problem to be solved by distributing pre-built code.

Since the package system specifically does not address jobs 2, 3, or 4 of PLaneT, we have to ask, “Do they need to be solved?” and if so, “How can we solve them on top of the package system, i.e. as a library in honor of the design principle?”.

In particular, 2 and 3 are very painful for people wanting to just use the file distribution mechanism of PLaneT. 2 causes unpredictability, because you don’t know if running a program will start a long invocation of “raco setup”, require Internet access, and start running un-vetted code. 3 requires you to share your code if you want to use the file distribution mechanism and is a single point of failure for doing installation.

By not mandating how to address 2 and 3 in the package system, we offer flexibility. Here is where the solutions to these jobs are now:

  1. There is currently no way to get automatic installs of packages. However, both DrRacket and xrepl offer advice about which packages you might want to install to compile and run the program. It would be natural to extend this advice to be automatic and patches are welcome. Given the experiences of operating systems which merely make suggestions (nethack: command not found, provided by nethack-console), I personally feel like we are at the sweet spot.

  2. The file distribution mechanism’s flexible package sources combine with a very simple protocol for package catalogs (Take a URL, add/pkg/, add a string, get a read-able hash table) to look up packages you don’t yet have. As a service, we run a few catalogs (one for each release, plus pkgs.r-l.o). But we expect that users with special needs (such as sensitive installations that need exactly certain tested and trusted versions, especially with proprietary software) will build their own catalogs on private Web sites.

Clearly, however, job 4 is where PLaneT and the package system differ the most.

With the package system, we follow the precedent of operating systems. An OS package’s job is to get files into the right spot. An OS package contains a binary and instructions to install it as /usr/bin/zsh. It is not typical in OSes to be able to install multiple packages (such as different “versions” of the “same” package) that both provide /usr/bin/zsh. When you’re at a Unix prompt, you don’t have to write zsh-5.0.5/usr/bin/zsh. It’s possible that many consider this is a big problem with OSes and indeed we do observe that it is fairly common to provide packages that provide binaries and libraries with embedded names such as how on my machine I have python2.6, python2.7, and python3.2 all in my $PATH. It is important to realize, however, that the deb format and the apt tool didn’t need to change to support this change or future changes in perspective in how to compose code.

I hope this analogy helps understand the Racket package system. In the package system, a package doesn’t install “binaries”, “man pages”, and “init scripts”, but installs similar things, such as “module paths”, “documentation manuals”, and "raco commands". Each of these has a notion of conflict: can’t have two zshs or two racket/lists; can’t have two zsh.1 pages or two docs named doc; can’t have two modules trying to provide raco neo-tokyo-is-about-to-explode. If you find a random .deb on the Internet, can you predict what binaries it will contain from its name? No. The same goes for Racket packages. However, if you are egregiously weird, then people probably won’t want to install your packages, just like for random debs.

However, clearly rules are helpful. In the world of operating systems, you know that basically all packages distributed by Debian can be installed at the same time, except for “virtual packages” that do stuff like selecting whether postfix or sendmail should be responsible for the sendmail command. These rules are not enforced through technology, though. Instead, the Debian maintainers have a social process that enforces them, with information being provided by technology (such as regression systems that identify unintended conflicts.) The catalog server that the Racket team provides helps facilitate a similar process with the concentric rings (all ring <=1 packages can be installed at once and ring 1< packages can do anything.)

Non-conflicting sets of packages is the simplest rule to define and enforce. Other rules about backwards compatibility are much more complicated to define and enforce. I do not believe there is much precedent in the world of OSes, although we can see a little bit of what they do through things like libgtk, libgtk2, and libgtk3, where generally code written for one libgtk2 package is compatible with all libgtk2 packages made in the future, but libgtk3 is effectively a totally different package and introduces totally separate binaries like gtk3-config.

The most that the Racket team attempts to do here is to say, “Here are the rules we will follow and we think you should follow them too.” Specifically, that we will maintain backwards compatibility or make a new package. We can’t and won’t enforce this, nor do we always live up to it with our own work (but we feel really bad about it when we do.)

Although my main goal of this section has been to explain my solution to (4), a great thing about the package system is that it is not binding at all. You can decide to follow the same rules as PLaneT. It is easy to do so:

  • Always name your packages $AUTHOR-$PACKAGE-$MAJOR

  • Always provide modules from only the collection, $AUTHOR-$PACKAGE-$MAJOR

  • Maintain backwards compatibility within releases of $AUTHOR-$PACKAGE-$MAJOR

  • Update the 'version metadata in the package info.rkt to reflect the $MINOR version.

And, boom!, you’ve recreated the rules of PLaneT to a T except for two things: (a) you’ll still need to put a dependency on $AUTHOR-$PACKAGE-$MAJOR on the outside of code in a package info.rkt file rather than just inside files and (b) you can’t use $AUTHOR-$PACKAGE to refer to “whatever the current $MAJOR” is.

The first compromise of adding something to the info.rkt is fairly modest, as it requires O(1) line modifications.

The second compromise is more severe, although actually you could just maintain such a package and deal with the breakage that occurs when you try to upgrade. Such breakage, however, was present in PLaneT too, as when a package was installed based on $AUTHOR-$PACKAGE only the local machine would cache the version used, so if you took the requiring module to another machine, it would download a new version and, potentially, have a backwards incompatibility problem. Using the package system in the most naive way (i.e. installing the $AUTHOR-$PACKAGE at some point and programming to that) would work exactly the same as PLaneT, except that the package system was designed to be able to port installations from one machine to another with raco pkg migrate.

I hope this blog post has helped explain the package system and shown that it does not prevent you from doing anything that PLaneT let you do, it only allows you to do more.

more →

23 Nov 2014


posted by Tim Brown

800 (Racket Tasks On Rosetta Code)

Since (and even before) Asumu Takikawa’s post “200!” at the beginning of March 2013, folk have been beavering away, implementing tasks on Rosetta Code. And on November 15th 2014:

800 tasks have now been Implemented1 in Racket on the Rosetta Code website!

Before I go any further it must be said that, without a doubt… this is awesome! This achievement represents a lot of work, and a lot of code. And everyone who has participated should be thanked and congratulated for getting this far.

So thank you. And well done!

What is Rosetta Code?: Rosetta Code (RC) describes itself as:

… a programming chrestomathy site. The idea is to present solutions to the same task in as many different languages as possible, to demonstrate how languages are similar and different, and to aid a person with a grounding in one approach to a problem in learning another. Rosetta Code currently has 758 tasks, 134 draft tasks, and is aware of 560 languages, though we do not (and cannot) have solutions to every task in every language."2

Of these tasks, 800 have been implemented in Racket… some tasks, like Hello World/Text, have been implemented in hundreds of languages. Some, however, like Time-based One-time Password Algorithm, have only been implemented in 3 (including Racket).

If you haven’t already, I suggest you take a quick look about the site to get a feel of what that means in practice.

WARNING: Rosetta Code is a wiki. Like any wiki it will steal your time from you as you browse tasks, algorithms, languages and the occasional link to Wikipedia. Don’t say I didn’t warn you.

What Can You Do With Rosetta Code? —

Learn From It Rosetta Code is a valuable resource with plenty of material to absorb and ideas to be had from. If you’re new to Racket, there are tasks like Loops/For which will get you on your way with fundamental programming tasks.

If you want something juicier there are other tasks (like Nonogram solver which runs to over 400 lines of Racket) for you to pick over.

And there’s everything in between.

Write Code!

Each task gives you a chance to think, “Is this how I would do this?”

Even if I don’t submit something, I find it’s fun to write some code around the task. In fact, I don’t even have to type code into a REPL, the thought exercise is often fun enough!

Some tasks, like (“Chess Player”), are shall we say, very challenging. But don’t let even that put you off thinking of, tinkering around or coding a solution to them.

If there isn’t a Racket implementation for a task you like the looks of, have a go.

Someone might have a better idea of how to do it in Racket later. But if there isn’t an implementation now — change that now!

Remember that others will be reading your code to understand Racket all the better. So please try to adhere to the Racket Style Guide as best you can3. Again, don’t worry about getting that perfect. Like anything, learning Racket style takes practice, and nobody expects perfection. And the experienced contributors/documentors are always at hand to help correct style.


  • I always have a Wikimedia Cheatsheet to hand. I can never remember its markdown syntax (which unfortunately doesn’t really support <code/>, either)

  • Pick whatever task you want… but it would be good to clear all the “Complete Tasks” (as opposed to “Draft Tasks”) if you have a choice.

  • Don’t add code until it’s running and producing the output you expect. This isn’t Project Euler, you don’t have to guess the answer in most cases — it’s likely someone has some sample output to compare to.4

  • If you can’t get your head around the algorithm in the task description then try to translate another language into Racket. You’ll learn Racket, you’ll learn the other language, and in working it through for yourself you’ll also see how the algorithm takes shape and works.

  • My workflow for posting a new solution is this: Once I have something to submit, I add a “Stub” Racket implementation. I edit the whole Task page (because that is all that is available to edit at that point), find whatever is after Racket alphabetically, and insert boilerplate code. I check this template code as a “minor edit” described as “Racket stub added — implementation later”. This then allows is for me to be able to edit the Racket section in isolation and keeps the rest of the task (everyone else’s hard work) safe from any, er, silliness. {{header|Racket}} <lang racket> </lang racket> {{out}} <pre> </pre>

  • I have started to make it my habit (especially when showcasing one or two functions) to use #lang racket/base and requireing the salient individual functions.

  • It is often not appropriate to fully document the functionality of Racket functions in the RC task implementation. You can, however, point to the canonical documentation on the Racket website. So I also include a link to http://docs.racket-lang.org/reference/... when I need to.

  • The RC administrators have switched off image uploading (or I, at least, cannot find out how). Even though Racket can produce images as results, think hard about whether you want the hassle of trying to present images to the reader. If you find out a method that works for you please tell me, I’d love to know. I suppose you could also extend all of the above to coding in another language — if you really have to.

Improve What’s Already There

Rosetta Code is a wiki.

It is open to anyone to edit.

Don’t be afraid to. If you see something that could be implemented, styled or documented better — work to improve it.

Once you have your improved entry together, show it to the author of the original post. Besides being courteous, he or she might have an opinion on what else you might do. Often, there is something bugging them, and you are scratching an itch of theirs!

I have never had anyone react badly to a change request. Everyone appreciates that you have made an effort to produce your change (and that you’re not just standing in the aisles complaining that it doesn’t look right).

Teach Through It —

If there is an aspect of Racket, algorithm or other “CS task” (in the broadest sense) that you want to share: see to it that it is adequately illustrated on Rosetta Code. If it is not, then create a task to demonstrate it. Not only will you show how something is done properly (i.e. in Racket), but you will also be inviting others to implement the task in their own favourite languages.

The Competition

Back at 200, Racket was the 54th most popular language. But for some time now, it has been sitting at #2 in the popularity1 ranking for quite some time now. For a while, it has been placed a long way behind TCL, and being hotly pursued by Python (never more than 10 tasks behind).

One of my motivators is that having seen Racket get to #2 — I don’t want to see it any lower in the rankings. I’m sure there’s something in the Python lot that wants to overtake us! This healthy competition has kept both of the communities pushing ahead with implementing the tasks.

The Intro Projects page of the racket wiki has “Implement a Rosetta code task” as a “Small Project”. I think of it as slightly more of a “Recreational” project (this at least justifies to myself the element of competition that has crept in.)

The Rallying Call —

or “What Specifically Would Help Racket on Rosetta Code?”

RC is a good way to present Racket as a most general programming language. So as a tool for Racket advocacy, as well as for the purposes of RC, we need to:

  • Implement more tasks in Racket to keep a high profile: 800 tasks, #2 in the popularity stakes. This keeps Racket visible; and proves it capable of (almost) anything. I would so love to give TCL a run for its money — so there’s 41 tasks to go before we can even think of taking a breather!

  • We have implemented 800 tasks in Racket. The quote above says there are 892 (758+134) tasks in total. That means that there are 92 more tasks to get to grips with.

  • Suggest new tasks: Especially tasks that will demonstrate the latest shiny feature of the latest shiny versions of Racket!

Personally I can’t believe that there are less than 900 things that you would want to do with a programming language. If you think of a task, add it. Even impossible tasks provoke thought and imagination — and interesting solutions!

  • Improve those tasks that have been implemented in Racket: We want to maintain a body of good, useful code, to allow us to teach and demonstrate Racket. There are a number of reasons why existent tasks need revisiting:

  • Racket technology has moved on (and moves on) apace. What was unavailable and experimental even 18 months ago is now available and reliable. This new technology needs to be demonstrated.

  • Code that is even older is very “schemey” (I have in some cases simply copied the Scheme implementation and stuck a #lang racket tag on the front). Although compatible, Racket has moved quite a way on from Scheme.

  • Some implementors (not a million miles from where I’m standing, for example), were not as au fait with the language and/or style guide as they might be now. It’s a housekeeping job, I know, but giving the examples as consistent a style as possible will help satisfy this aspiration from the Racket Style Guide:

“Doing so will help us … and our users, who use the open source code … as an implicit guide to Racket programming.”

  • Document tasks: see my hint about documentation and links above for what I now think is good practice. If some code seems utterly heiroglyphic, see if it can be made clearer. Remember this is Racket, not APL.

  • General tidying up never goes amiss.

  • RC is run by someone outside the Racket community. At the bottom of the “Small Projects” section of the Racket wiki is a suggestion to collect the RC examples into something “owned” by the Racket community. I’ve been thinking about this… if anyone has suggestions, let me know. There are limits to what we can put on RC (defined by the purpose of RC itself). It would be good to remove those limits by implementing something along RC’s lines oursleves.

  • Very specifically… anyone with a joystick, drivers and some spare time - please could you do “Joystick Position”. The possession of a joystick puts you in a position of great power with respect to that task. Exercise your responsibility. And Finally…: Well done everyone again! Keep up the good work. And see you at 1000!

  • You can track Racket (and everyone else’s) progress on the Popular Programming Languages report, which is updated hourly or so.

  • Rosetta Code’s Front Page

  • The style guide is actually the chapter called “How to Program Racket” in the main Racket documentation. One of the RC “style” rules is that code should be 80 characters wide. Personally, I ignore that in favour of Racket’s more generous 102. Sometimes someone on RC objects. Sometimes I then care enough to put the required newlines in.

  • Even if there are example results don’t necessarily trust them. e.g. in The ISAAC Cipher, the cypher engine isn’t reset between test runs in the Pascal implementation. That error is propagated through all other implementations. Mine (Racket) conforms to show that I’m doing the same thing as everyone else; but I also do what I think to be a more correct test later.

  • Hold on a mo… this is meant to be a pedagogical exercise, not a competition

more →

04 Nov 2014

Racket v6.1.1

posted by Ryan Culpepper

Racket version 6.1.1 is now available from http://racket-lang.org/

  • The Mac OS X Yosemite compatibility problems are fixed. We bundled a patched Pango text-drawing library with Racket.

  • The Windows [32-bit] releases fixes the window-update crashes. We bundled a patched Cairo drawing library with Racket.

  • Typed Racket closes two safety holes in the exception system. The revised type system restricts raise to send only instances of the exn structure type and flat data to handlers. It also checks exception handlers properly. Note: Previously well-typed programs may fail to typecheck.

  • Typed Racket’s typed regions support casts and predicates.

  • 2htdp/image’s notion of equality ignores an image’s baseline.

  • The package manager supports a binary library installation mode, which allows users to install packages without source or documentation. Use the --binary-lib option with raco pkg install.

  • The new drracket-tool-lib package factors out parts of DrRacket’s IDE so that they can be reused with other editors, such as Emacs.

  • The compiler’s use-before-defined analysis has been repaired for certain forms of nested letrec, some let forms, and some uses of set! or with-continuation-mark.

  • The compiler performs additional bytecode optimizations. Thanks to Gustavo Massaccesi.

  • The CML library comes with a new replace-evt event constructor. Thanks to Jan Dvořák.

  • Redex’s benchmark suite comes with a description of the benchmark programs.

  • Redex’s metafunctions can be typeset using the “large left brace” notation for conditionals.

  • The contract library comes with an improved contract-stronger?. Its error messages note that the contract itself might be wrong.

  • The GUI library is DPI-aware on Windows.

  • The openssl library supports Server Name Indication for servers. Thanks to Jay Kominek.

  • The syntax/parse library allows the definition of new pattern forms via pattern expanders, similar to match expanders. Thanks to Alex Knauth.

  • OpenGL on Linux no longer depends on libgtkgl, and core profiles are supported (see set-legacy?).

  • The teaching languages’ unit test framework supports check-satisfied, a construct for checking whether a result satisfies a predicate, e.g.:

(check-satisfied (sort l) sorted?)

Feedback Welcome

more →

07 Oct 2014

PLT Redex Summer School, Call for Participation

posted by Robby Findler

LOCATION: University of Utah, Salt Lake City

DATES: July 27 - July 31, 2015


PLT Redex is a lightweight, embedded DSL for modeling programming languages, their reduction semantics, and their type systems. It comes with an IDE and a toolbox for exploring, testing, debugging, and type-setting language models. The PLT research group has successfully used Redex to model and analyze a wide spectrum of published models.

The summer school will introduce students to the underlying theory of reduction semantics, programming in the Redex language, and using its tool suite effectively. The course is intended for PhD students and researchers in programming languages. Enrollment is limited to 25 attendees.

While the workshop itself is free, attendees must pay for travel, room, and board. We expect room and board to be around $500, assuming an arrival in the evening of Sunday July 26 and leaving Friday July 31 or August 1. Partial financial support for PhD students is available.

To register, send email to Matthew Flatt ([email protected]). If you are a PhD student and requesting financial support, CC your advisor and ask for a one-line confirmation email.


Matthias Felleisen, Robert Bruce Findler, Matthew Flatt. Semantics Engineering with PLT Redex. MIT Press, 2012.

Casey Klein, John Clements, Christos Dimoulas, Carl Eastlund, Matthias Felleisen, Matthew Flatt, Jay McCarthy, Jon Rafkind, Sam Tobin-Hochstadt, Robert Bruce Findler. Run Your Research: On the Effectiveness of Lightweight Mechanization. POPL 2012.

more →

02 Aug 2014

Racket v6.1

posted by Ryan Culpepper

PLT Design Inc. announces the release of Racket version 6.1 at


The major innovation concerns local recursive variable definitions. Instead of initializing variables with an undefined value, Racket raises an exception when such a variable is used before its definition. (Thanks to Claire Alvis for adapting Dybvig’s “Fixing Letrec” work.)

Since programs are rarely intended to produce #<undefined>, raising an exception provides early and improved feedback. Module-level variables have always triggered such an exception when used too early, and this change finally gives local bindings — including class fields — the same meaning.

This change is backwards-incompatible with prior releases of Racket. Aside from exposing a few bugs, the change will mainly affect programs that include

(define undefined (letrec ([x x]) x))

to obtain the #<undefined> value. In its stead, Racket provides the same value via the racket/undefined library (which was introduced in the previous release). Programmers are encouraged to use it in place of the pattern above to obtain the “undefined” value.

The release also includes the following small changes:

  • Plumbers generalize the flush-on-exit capability of primitive output ports to enable arbitrary flushing actions and to give programmers control over the timing of flushes (i.e., a composable atexit). New functions include current-plumber, plumber-add-flush!, and plumber-flush-all.

  • Contracts: the contract system’s random testing facility has been strengthened so that it can easily find simple mistakes in contracted data structure implementations (e.g. an accidental reverse of a conditional in a heap invariant check).

  • Redex: the semantics of mis-match patterns (variables followed by _!_) inside ellipses has changed in a backwards-incompatible way. This change simplifies the patterns’ semantics and increases the usefulness of these patterns.

  • Teaching languages: check-random is an addition to the preferred unit testing framework in the teaching languages. It enables the testing of students’ functions that use random-number generation. (Thanks to David Van Horn (UMaryland) for proposing this idea.)

  • Upgraded and normalized versions of graphics libraries and dependencies (Pango, Cairo, GLib, etc.) that are bundled with Racket on Windows and Mac OS X. For example, FreeType support is consistently enabled.

  • Typed Racket: its standard library includes contracted exports from the Racket standard library, such as the formatting combinators of racket/format. It also supports Racket’s asynchronous channels; see the typed/racket/async-channel library.

  • SSL: The openssl library supports forward secrecy via DHE and ECDHE cipher suites (thanks to Edward Lee) and Server Name Indication (thanks to Jay Kominek).

  • The mzlib/class100 library has been removed. Use racket/class instead.

more →

26 Jul 2014

Scheme Workshop 2014

posted by John Clements

DEADLINE: 5 September 2014, (23:59 UTC–12)

WEBSITE: http://homes.soic.indiana.edu/jhemann/scheme–14/

LOCATION: Washington, DC (co-located with Clojure/conj)

DATE: 19 November 2014

The 2014 Scheme and Functional Programming Workshop is calling for submissions. Submissions related to Scheme and functional programming are welcome and encouraged. Topics of interest include but are not limited to:

  • Program-development environments, debugging, testing

  • Implementation (interpreters, compilers, tools, benchmarks, etc)

  • Syntax, macros, and hygiene

  • Distributed computing, concurrency, parallelism

  • Interoperability with other languages, FFIs

  • Continuations, modules, object systems, types

  • Theory, formal semantics, correctness

  • History, evolution and standardization of Scheme

  • Applications, experience and industrial uses of Scheme

  • Education

  • Scheme pearls (elegant, instructive uses of Scheme)

We also welcome papers related to dynamic or multiparadigmatic languages and programming techniques.

Full papers are due 5 September 2014.

Authors will be notified by 10 October 2014.

Camera-ready versions are due 24 Oct 2014.

All deadlines are (23:59 UTC–12), “Anywhere on Earth”.

For more information, please see: http://homes.soic.indiana.edu/jhemann/scheme–14/

See you there!

more →

08 May 2014

Racket v6.0.1

posted by Ryan Culpepper

Racket version 6.0.1 is now available from


  • A new racket/undefined library exports undefined as the value currently produced by

(letrec ([x x]) x) This library anticipates a future where that expression will raise an exception. The racket/undefined library will continue to offer the undefined value as a bridge between versions and as a last resort.

  • The drawing and GUI libraries provide improved support for high-resolution bitmaps and their use on Retina displays. For example, read-bitmap includes a #:[email protected]? option to trigger substitutions through the usual "@2x" naming convention.

  • Check Syntax cooperates with Typed Racket to show arrows and other Check Syntax highlighting even when there is a type error.

  • Functions provided via contract-out that have first-order contracts perform better.

  • The contract boundary between typed/untyped modules is much less expensive. Typed Racket now avoids generating contracts for places where contracts failures cannot happen.

  • Occurrence typing now works better with when/unless. Example:

(let ((x (read)))
  (unless (number? x) (error 'bad-input))
  (add1 x))
  • Types in Typed Racket are now pretty-printed.

  • Function types can now be written in prefix style, which is now preferred and is used for printing. Infix function types are still accepted for backwards compatibility.

  • A new ->* type constructor is used for writing types for functions with optional and keyword arguments. The notation is similar to the matching contract combinator.

  • Typed Racket forms do not have a : suffix by default now. For example, the struct form replaces struct:. The suffixed versions are all provided for backwards compatibility.

  • Typed Racket now has preliminary support for classes and objects. However, it is still experimental and the APIs are subject to change.

  • Type aliases in Typed Racket now support recursion and mutual recursion. For example, (define-type (MyList X) (U Null (Pair X (MyList X)))) is now a valid type alias.

  • Plot correctly renders intersecting 3D graphs and non-grid-aligned 3D rectangles.

  • Elements in plots output in PDF/PS format have the same relative scale as in other formats. In particular, it is not necessary to adjust plot-font-size to make PDF plots look the same as PNG.

more →

Made with Frog, a static-blog generator written in Racket.
Source code for this blog.