Racketfest is a one-day event to learn & share what’s great about the Racket programming language and its philosophy of language-oriented programming.
Saturday, March 23, 2019 from to
Spielfeld, ground floor (
The Stadium), Skalitzerstrasse 85, 10997 Berlin, Germany
An agenda to sweeten program languages research
Syntactic sugar is pervasive in language technology. It is used to shrink the size of a core language; to define domain-specific languages; and even to let programmers extend their language. As a result, it is found in the heart of numerous programming languages. Despite its widespread use, it has received disproportionally little attention from the programming languages research community. This talk will lay out some interesting problems and preliminary solutions.
Because desugaring eliminates syntactic sugar, when a system provides feedback, it is in terms of a program that is unfamiliar to the authors. The concept of resugaring shows how to lift core language features to present them in terms of the surface syntax. We have discuss how this principle applies to different language components, and what properties we expect resugaring to obey. Desugaring also significantly expands program source, making the output daunting to manage. We will examine situations where this expansion is not necessary, and methods to mitigate the effect. Finally, we will examine an interesting and challenging open problem in language semantics where desugaring features prominently.
There will be three half-hour talks, held sequentially:
The truth about teaching with design recipes
The design recipes promulgated in How to Design Programs and Program by Design and its German offspring DeinProgramm are the most effective methodology for teaching programming, pretty much no matter what the context—friends, loved ones, colleagues, students, or customers. Unfortunately, while there is a body of material for learning with design recipes, there is not so much on teaching with them. (And the learning material leaves out a few crucial aspects.) This talk will tell you what you need to know to be an effective teacher with the design recipes.
Making DSLs with
Racket’s macro system allows programmers to create embedded DSLs that interact with Racket and with other Racket-hosted DSLs. DSL creation is supported by the
syntax-parse is a DSL for implementing DSLs.
This talk demonstrates how to use
syntax-parse to construct a small DSL for SQL queries. I focus on four aspects in particular: specifying and validating syntax using syntax classes, organizing compile-time computation with attributes, protecting interoperation via contracts, and sharing compile-time information between macros.
FP vs. OOP: Case studies in misunderstandings
Some people say that studying paradigms increases our knowledge and programming abilities. We usually arrive at these paradigms not by deliberate construction, but by our innate abilities to copy other people’s behaviors. It should therefore be no surprise that we’re often not even aware that our thinking represents some particular set of patterns, or that we’re making some implicit assumptions.
Functional programmers and object-oriented programmers sometimes claim that their paradigm represents a fundamental approach to programming. Yet, there are a number of assumptions that most programmers share without questioning them, and often without even realizing it. How can we discover these assumptions? To what extent are they a limitation to us and to the systems that we build? What alternatives can we propose? How can we deconstruct or transcend the paradigms that are familiar to us?
There will be three two-hour tutorials, held in parallel:
We use parallel computation, independent state, and message passing every day. Our world is wired around webservers and load-balancers. Racket allows us to create our parallel computation network inside a laptop.
In this tutorial we give a short introduction to Racket places. We introduce the basic concepts for independent computation and approach step-by-step how to use Racket places. Lastly, we play with examples including a worker pool manager. Essentially, we fork-bomb Racket.
I have two children—the oldest, who is not named after a big toilet paper company and the youngest, who is not named after an operating system had no boundaries until contracts came along.
Come with me on a journey into the land of contracts and how they helped me to get these children to bed on time, so I can then have some more time for Racket. If you pay attention, you might even learn some cool things about the contract system in Racket—in addition to the contract system I have implemented in my own home.
When I was asked for an abstract for this tutorial, the Racketfest organizers probably expected something serious. Instead, they got this! If only they had imposed some contracts on the abstract request they would have gotten something better, or at least someone to blame!
Come along and learn how to use, reuse, misuse, and disuse the Racket contract system. It might turn out to be a great way to help you develop great reliable software and even get your kids to bed on time.
Role-playing games! They’re fun. But all that dice rolling…we can automate that, can’t we?
Yes, we can.
Sure, we could write a library of functions for doing what we need. And I can assure you that Racket is not so
batteries-included that the base system contains a dice-specific part. At some point, data definitions for dice and functions for operating on them will need to be created.
But let’s take the idea of
automated dice rolling one step further and make a language for it.
Racket’s not just a fantastic programming language; it’s also a great environment for making languages. Language-oriented programming is the name of the game. In this tutorial, we’ll see how to get started with that, by focusing on a simple DSL (domain-specific language) for rolling dice.
Offer a lightning talk (at most 10 minutes). Talk about what you wish Racket had or what you find difficult. Identify libraries that could be improved. Tell us how you could help the community. If it’s about Racket, tell us!
Chat with the speakers and tutors, mingle, take a moment to reflect on what you’ve picked up.
Racketfest borrows from the spirit of Racket, whose community aims to improve the world through programming. Racket started with the goal of introducing everyone to the wonderful world of program design, with a spirit of full inclusion and no emphasis on any specific group. Over time it has grown into a full-fledged professional community with a well-known reputation for helpfulness and openness on its on-line communication channels. We want that openness and friendliness to extend to Racketfest.
For this to happen, Racketfest needs to be a space that where everyone can participate without fear of personal harassment. Harassment is understood here as unwelcome or hostile behavior, which, in turn, we understand as behavior that focuses on people instead of ideas. The ACM’s anti-harassment policy lists some unacceptable behaviors. Responses such as
only teasing, or being
playful, are unacceptable.
In short, be professional and kind. We’re all here to learn and share.
Anyone witnessing or subject to unacceptable behavior should notify the Racketfest organizer (Jesse Alama).
If a Racketfest participant engages in harassing behavior, the Racketfest organizer may take any action they deem appropriate, ranging from a verbal warning to expulsion (without refund) from the conference.
(The wording of this policy is derived, with permission & thanks, from that of RacketCon, which in turn was derived from the SNAPL conference.)
Racketfest pairs well with BOB, taking place in Berlin on the day before () at Lohmann & Birkner GmbH (Alt-Reinickerdorf 25, 13407 Berlin) BOB asks:
What happens when we use what’s best for a change?. Come find out!
José Diaz Seng