If you’ve heard of Racket “at-expressions”, maybe you think they’re “that funny Scribble notation in which you write Racket documentation.”
In fact at-expressions are a general, alternative way to write s-expressions. They can be used in various handy ways.
Let’s look at using at-expressions for a few practical things like:
NOTE: See my newer post.
Most of my Racket projects don’t use a makefile. Why would they? raco
make or raco setup suffices.
But a makefile can consistently define some common project tasks. And it can really help when you want to generate HTML documentation from Scribble sources, and publish it to GitHub Pages using the automagical gh-pages branch.1
Many languages have a variable (or preprocessor macro) called __FILE__ or __file__ whose value is the pathname of the current source file. Likewise __LINE__ for the the source line number.
You probably need this less in Racket than you imagine. For example:
We wouldn’t test that __FILE__ ends in main.rkt; instead we’d use a main submodule (module+ main <your code here>).
To get a data file foo.dat located in the same directory as a source file we’d use (define-runtime-path foo.dat "foo.dat"). If we’re a package or executable this works regardless of where our files happen to get installed.
But if you really did need a __FILE__ in Racket, how would you do it?
Let’s say we want to use find-collects-dir, which was added in Racket 6.0. We get a bug report from someone using Racket 5.3.6.
To fix this, we can dynamic-require the desired function; when it doesn’t exist, we can use our own fallback implementation.1
Two parallel thoughts:
I haven’t blogged in awhile. I’ve been heads-down on a few projects. Plus I haven’t had ideas I feel are “big” or unique enough to merit a post.
It’s occurred to me that a “Racket Cookbook” might be a useful resource. Because examples. Because real-life, practical examples.1
Although I haven’t created a cookbook, my working assumption is that it would be better to write one recipe at a time. As they arise. As I think, “Ah right, this wasn’t obvious to me when I was learning Racket.”
So I plan to experiment with releasing the things one at a time, as short blog posts. Thereby terminating two avian organisms with one geologic projectile.
Not sure if I’ll keep it up. Definitely not sure if I’ll ever collect and polish them into a “book” of some form. They might only ever live as a racket-cookbook tag on this blog.
Admittedly I rarely recall using any “cookbook” resource to find the answer to a problem I have. Taken literally, programming cookbooks are largely a failure, for me. On the other hand, flipping through one can give the “flavor” of a language. And as I’ve written, one valid learning strategy is to absorb things shallowly — you may not know the answer, but you know roughly where to find the answer. It rings a bell. Probably cookbooks fit that model — filling your head with, um, bells. ↩
In my previous post, I wrote about a nuance with syntax/loc, using the example of a macro that both defines and provides a function. But why don’t I back up, and look at a simpler example of why you’d want to use syntax/loc. The example is a simple macro you might often find yourself wanting, to reduce the tedium of writing unit test cases.
When I learned Racket, one of the first things I wanted to try was doing HTTP requests. And Racket’s net/url module is great.
Racket was the first real Lisp/Scheme family language I ever learned. As a result I was focused on building blocks like ports, and assuming I would need to open and close them directly all the time. At that early stage, I also didn’t really appreciate the value of higher-order functions. So I overlooked the value of call/input-url. I sometimes see other folks do the same, and wanted to write this short blog post.