This page accompanies my paper "De Jure Codesignation". Section 7 of that paper provides some code to illustrate a kind of semantic structure that has also been claimed to be useful in the analysis of anaphora and/or attitude reports.
This page provides some background, and further details about implementation I sketched for this semantic structure in the Scheme programming language. Scheme is a family of programming languages, and different versions of Scheme extend or further specify the language in different ways. Unfortunately, I need to make use of some of these extensions. What I'm proposing cannot be easily implemented in the current (R7RS) Scheme "standard." (It could be implemented un-easily, by writing an interpreter for a custom programming language from scratch.)
The instructions below assume you are using the Racket version of Scheme. The current version of Racket as I write this is v6.4 (from Feb 2016), however the code will probably work with some earlier and later versions as well.
If you just want to be able to run the code in my article, all you need to do is download this file dejure.rkt, place it in your working or home directory, then start up DrRacket and in the "Definitions" window, type:
#lang racket
(require "dejure.rkt")Then you can enter any of the code from my article, either in the same "Definitions" window, or in the lower "Interactions" window.
If you want some explanation of what's happening behind the scenes, see below. This may be helpful if you already have some familiarity with Scheme.
In the article, I use let in the way that let* is really used in Scheme. I didn't want to take the time to explain the difference between these, and why we wanted to use let*. I could have finessed the issue by always using multiple embedded lets, but that quickly gets verbose and hard to format. (Scheme's native let keyword can be accessed using parallel-let.)
I also didn't want to explain Scheme's funny #t and #f notation for the booleans, so I just used true and false. In fact Racket already pre-defines these.
Also, I thought philosophers and linguists would find the symbol λ more familiar than Scheme's more usual lambda. Racket lets one use these interchangeably.
Different versions of Scheme will display lists in different ways, perhaps depending on runtime paramters. In my article, I showed (list 2 3 4) as evaluating to (2 3 4), and your version of Scheme may display that list the same way, or it may display '(2 3 4) instead. This is just a matter of output style. You can rely on (list 2 3 4) generating the same complex value in any version of Scheme (modulo the issues discussed in the next point).
Most versions of Scheme don't have a built-in immutable list structure, and instead list, cons, car, set-car! and so on all work on mutable lists. I made use of Racket's helpful separation of immutable lists (which Racket builds using list and cons) from mutable lists (which Racket builds using mlist and mcons). For simplicity, I defined head to work like car or mcar, depending on the type of list it's given, and similarly for tail. Also, I made cons work with both immutable and mutable lists: it returns a list that's mutable iff its second argument is. It returns an error if its second argument isn't a list. (Racket's native (immutable) cons procedure can be accessed using pair, and its native mcons is still available under that name.)
In the article, I avoided using constructions with multiple expressions, like:
(let (...)
expr-with-side-effects
...
another-expression)or:
(begin
expr-with-side-effects
...
another-expression)Instead, I handled side-effects like this:
(let (...
[_ expr-with-side-effects]
...)
another-expression)This was to minimize the amount of special explanation that we needed for dealing with side-effects. Readers have already been introduced to lets with multiple clauses, so we can just use them to sequence our effects.
In the article I opposed the predicate equal? to egal?. The latter is explained in Henry Baker's paper "Equal Rights for Functional Objects or, The More Things Change, The More They Are the Same" (ACM OOPS Messenger, October 1993). Readers already familiar with Scheme may be surprised that I didn't use eqv? or eq?. The reason is that those pay attention to implementation details in an undesired way when comparing complex immutable objects. See Baker's paper for discussion. egal? behaves the way that eqv? really ought to behave (although it can be less efficient).