On macOS, clicking that link does not necessarily mean your browser gets to decide what happens. The operating system gets the first vote. And my macOS system is sure eager to send it to FaceTime. Which I don’t use and is a dead-end on my system.

Here’s how it works. LaunchServices looks for the application registered as the handler for the tel: URL scheme, and it sends the URL there. Meaning if FaceTime is the current default handler, then clicking a phone number in Google Maps, in Chrome, can still end up in FaceTime. No amount of poking through Chrome preferences will fix it. You can see if you try the more general:

open 'tel:+18005550111'

Boom. FaceTime. From macOS.

I wanted all the tel: links that the system knows how to dispatch to open my Google Voice account instead. From the browser, from a terminal, from a document, from whatever you can think of.

That’s the reason for the little helper app:

google-voice-tel-handler

What the helper does

This is an AppleScript applet with an on open location handler. The OS can send URL events to an applet, so the script receives the original tel: URL, extracts the phone number, and opens the corresponding Google Voice call URL in the default browser.

The script accepts the common shapes I’ve seen:

tel:+18005550111
tel://+18005550111
tel:800-555-0111

It strips the tel: wrapper, keeps the digits, and opens a Google Voice URL using the /u/0 account slot:

https://voice.google.com/u/0/calls?a=nc,%2B18005550111

Your default browser takes it from there.

How it works

You can see all the source code. It’s not much, and the AppleScript itself is pretty readable.

There’s a build script that compiles the applet with osacompile, then patches the generated Info.plist so the bundle has a stable identity and declares the URL scheme:

CFBundleIdentifier = com.jasonhemann.google-voice-tel-handler
CFBundleURLTypes   = tel

The tools involved are already on macOS: osacompile, PlistBuddy, and codesign.

If you ask whether reverse is fast, the right first response is: which reverse?

There is a mathematical function called reverse. It takes a list like '(1 2 3) and produces '(3 2 1). But there are many algorithms that compute that function. Some are linear time. Some are quadratic time. The result is the same; the amount of work can be very different.

Here are two Racket programs that both reverse a list:

(define (rev1 l)
  (cond
    [(empty? l) '()]
    [(cons? l)
     (append (rev1 (rest l))
             (list (first l)))]))

(define (rev2 l)
  (rev2-help l '()))

(define (rev2-help l acc)
  (cond
    [(empty? l) acc]
    [(cons? l)
     (rev2-help (rest l)
                (cons (first l) acc))]))

They compute the same answers:

> (rev1 '(1 2 3 4))
'(4 3 2 1)

> (rev2 '(1 2 3 4))
'(4 3 2 1)

But rev1 is slower for large lists. The reason is not mysterious once we look at what each step is forced to do.

Throughout, the complexity measure is time as a function of the length of the input list. When we say O(n) or O(n^2), n is the number of elements in the list being reversed.

Lists Are One-Way

A Racket list is built out of pairs. Each pair points at the next part of the list. That makes some operations cheap:

(first '(1 2 3)) ; 1
(rest  '(1 2 3)) ; '(2 3)
(cons 0 '(1 2 3)) ; '(0 1 2 3)

Each of those operations can be treated as constant time for this discussion. They look at, or add, the front of the list.

But append is different. To append one list onto another, Racket has to walk down the first list. For example:

(append '(1 2 3) '(4 5))

The result is '(1 2 3 4 5), but getting there requires visiting the elements of '(1 2 3). If the first list has length m, the append takes time proportional to m.

That one fact explains the difference between the two versions of reverse.

The Direct Version

The direct version says:

(define (rev1 l)
  (cond
    [(empty? l) '()]
    [(cons? l)
     (append (rev1 (rest l))
             (list (first l)))]))

In English:

1. Reverse the rest of the list.
2. Put the first element at the end.

For a small list, that is perfectly clear:

(rev1 '(1 2 3 4))
= (append (rev1 '(2 3 4)) '(1))
= (append (append (rev1 '(3 4)) '(2)) '(1))
= (append (append (append (rev1 '(4)) '(3)) '(2)) '(1))
= '(4 3 2 1)

The expensive part is hidden in “put the first element at the end.” Since lists are easy to add to at the front, but not at the back, rev1 uses append.

For a list of length 4, the append work has this shape:

append a list of length 0
append a list of length 1
append a list of length 2
append a list of length 3

For a list of length n, the append work has this shape:

0 + 1 + 2 + ... + (n - 1)

That sum is the familiar triangular number:

0 + 1 + 2 + ... + (n - 1) = n(n - 1) / 2

The important part is the n^2. The exact constants do not matter for big-O analysis, so this version is O(n^2).

We can also say this with a recurrence. Let R(n) be the cost of reversing a list of length n with rev1. Let A(m) be the cost of appending a first list of length m. These costs are still measured in terms of list length: R varies with the length of the list being reversed, and A varies with the length of the first argument to append.

R(0) = constant
R(n) = R(n - 1) + A(n - 1) + constant

Since A(n - 1) is linear in n - 1, R(n) accumulates a linear amount of append work at each level of recursion. Adding those linear pieces together gives the quadratic sum above.

The Accumulator Version

The second version uses a helper function:

(define (rev2 l)
  (rev2-help l '()))

(define (rev2-help l acc)
  (cond
    [(empty? l) acc]
    [(cons? l)
     (rev2-help (rest l)
                (cons (first l) acc))]))

This program carries an accumulator, acc, that represents the part of the answer built so far. At each step it removes one element from the front of the input list and adds that element to the front of the accumulator.

Here is the state of the computation for '(1 2 3 4):

When the input is empty, the accumulator is the reversed list.

The key operation is cons, not append. Adding one item to the front of a list is constant time. That means each recursive step does a constant amount of work, then moves to a list that is one element shorter. The accumulator grows, but the cost of cons does not grow with it.

If H(n) is the cost of rev2-help on a list of length n, then:

H(0) = constant
H(n) = H(n - 1) + constant

After n steps, that is just:

H(n) = constant * n + constant

So rev2-help is O(n), and rev2 is also O(n). Again, this is linear in the length of the original input list.

The Lesson

It is imprecise to say “the complexity of reverse” without saying which algorithm we mean. The function being computed is not the whole story.

rev1 and rev2 produce the same lists, but rev1 repeatedly pays for append, and those costs add up:

0 + 1 + 2 + ... + (n - 1)

That is why rev1 is quadratic.

rev2 does one constant-time cons per input element. That is why rev2 is linear in the length of the list being reversed.

The built-in reverse you expect from a language implementation should be the linear-time kind. But if you write your own, the difference between “put it on the end” and “carry an accumulator” is the difference between an algorithm that slows down quadratically and one that scales directly with the size of the list.

((lambda (i)
   ((lambda (j)
      ((lambda (j)
         i)
       5))
    6))
 7)

We will step through the execution of this program, but first let us acquaint ourselves with what the program actually does.

The Outer Application

At the top level, this is an application. It is the application of the operator expression

(lambda (i)
  ((lambda (j)
     ((lambda (j) i) 5))
   6))

to the operand 7. In an application form, we call the first expression the operator and the second expression the operand. The operator is a lambda expression. If I were unsure of that, we could write a program over our lambda-calculus datatype:

(define (primary-form expr)
  (match expr
    [`,y #:when (symbol? y) 'variable]
    [`(lambda (,x) ,body) 'lambda]
    [`(,rator ,rand) 'application]))

You can use this to verify the program for yourself. The body of that lambda expression is also an application:

((lambda (j)
   ((lambda (j)
      i) ; this will be the point we discuss most
    5))
 6)

There are three useful things to notice. First, this is again an application of a lambda whose body is also an application. Second, the ultimate value of this whole big expression is going to come from the value of i. Third, i is a free variable reference in

((lambda (j)
   ((lambda (j) i) 5))
 6)

This latter fact should not be surprising. If x occurs in the scope of an expression, such as in (lambda (x) (lambda (y) x)), then that is a bound reference to x, since the variable declaration of x in the lambda expression is the referent of that bound variable reference.

If we restrict our focus to the body of that same expression, (lambda (y) x), then there must be a free variable reference to x in the body. That outer (lambda (x) ...) is what will bind that free variable.

Environments Remember Context

We perform evaluation of our programs via structural recursion, the same way we write most other functions. That means the place where we actually want to get the value of a variable is when we work our way down to the variable line. For the program above, that happens when we have worked our way all the way down to i.

By then, it is too late to figure out the value of i all by itself, because we no longer have the information we need to determine what i means. Our solution is to accumulate that information as we recur into the expression, and then look up the meaning of bound variables in our accumulator when we reach a variable case.

Since there are potentially scads and scads of bound variables in an expression, we need to track each one differently. When we see i, we need to know to look up i and not x. We also need to track not just the name of the variable, but also its meaning. Our accumulator must therefore track two pieces for each variable: the name, or formal parameter, of the lambda expression, and the value, or actual argument, to which that formal parameter corresponds in this context.

When do we finally have both of those pieces? Look at the application line:

(match expr
  ...
  [`(,rator ,rand) ((valof rator env) (valof rand env))])

The rator has to evaluate to a Racket procedure, since we are about to call it like a procedure of one argument. We are going to call that procedure on the value of the rand. The rator and rand can both be big honkin’ expressions, but ultimately, when we get values for them and pass the results back up the recursion, the value of the rator had better be a procedure. The value of the rand can be any old value.

Only after we finish evaluating the two sub-pieces of the rator/rand form, and then do the Racket application, do we have both the formal and actual parameters at the same time.

Lambda Bodies Wait

Here is a simpler example of something like our interpreter:

((lambda (b) (if b 5 6)) (not false))

We first evaluate the operator and operand to values: the former to a Racket procedure and the latter to a Racket boolean. Then we call the Racket procedure on the Racket boolean. Only after that can we evaluate the body (if b 5 6).

That is an important point: we never evaluate the body of a lambda expression until after we have applied it to a value.

(define loop
  (lambda (x)
    (loop x)))

The reason you can get by with writing down a definition like loop is that we do not evaluate the body of the expression unless and until we invoke it with an argument.

Extending The Environment

It is on the lambda line that we actually extend our environment. The right-hand side of the lambda line is:

(lambda (a)
  (valof body (lambda (y)
                (if (eqv? x y)
                    a
                    (env y)))))

That is the function we invoke with true or 7 or whatever value we have in our example. It is not until we invoke that function that we begin to evaluate the body. As soon as we recur in to evaluate the body, we will no longer have access to the surrounding (lambda (x) ...), because that was the point of recurring down into the smaller expression.

To keep that information with us as we go, we add it to our accumulator, called an environment. We are using a functional accumulator; we can just as well look at our interpreter as a mathematical description of a particular function from variables to values.

This step, adding to the accumulator, is also called extending the function. If you think of a function as a set of pairs, then we have added one more pair: the mapping of (x, a). Notice also that if there were already a mapping from x, we will have locally overwritten it. We call this behavior shadowing, and the function extension in the lambda line shows how we implement that shadowing.

Walking The Example

Now let us evaluate the big expression:

((lambda (i)
   ((lambda (j)
      ((lambda (j)
         i)
       5))
    6))
 7)

We evaluate the two sub-pieces. The rator evaluates to a procedure, and the rand evaluates to 7. When we do the invocation, we start to evaluate the body:

((lambda (j)
   ((lambda (j)
      i)
    5))
 6)

We do so while keeping track of the association that i should mean 7. If we wrote the environment out by hand, it would now look like this:

(lambda (y)
  (if (eqv? y 'i)
      7
      ((lambda (y) <bomb>)
       y)))

So we evaluate that body in this environment. In the same fashion, we evaluate the two sub-pieces, produce the procedure and the value 6, and then do the application. That means we evaluate this body:

((lambda (j)
   i)
 5)

with one additional binding, j to 6. If we wrote the environment out by hand, it would now look like this:

(lambda (y)
  (if (eqv? y 'j)
      6
      ((lambda (y)
         (if (eqv? y 'i)
             7
             ((lambda (y) <bomb>)
              y)))
       y)))

Each time we extend the environment, we wrap the old one with an if statement that first checks for the variable we just added, and otherwise recurs to the slightly smaller environment.

Doing the same again, we evaluate the two sub-pieces, do the Racket application, and evaluate the body within the extended environment. In this case, that means we evaluate i in the following environment:

(lambda (y)
  (if (eqv? y 'j)
      5
      ((lambda (y)
         (if (eqv? y 'j)
             6
             ((lambda (y)
                (if (eqv? y 'i)
                    7
                    ((lambda (y) <bomb>)
                     y)))
              y)))
       y)))

Notice two things here. First, as we focus more tightly on a sub-expression of a sub-expression of a sub-expression, our environment has grown larger and larger. There is an inverse relationship between how tightly focused we are on a sub-expression and how large a nested function our environment has become.

Second, the innermost binding for j in our original expression, 5, has now blocked out the ability to look up the other meaning of j. This is our implementation of shadowing. Because we accumulate these bindings with the most recent one in front, we can use the recursion into the program’s structure to get the shadowing behavior right.

When we finally look up i, we check that it is not j, then that it is not j again, and then finally that 'i is 'i. Since it is, the lookup returns 7, and the whole expression evaluates to 7.

If you have heard the term “DWIC” before, then you’ll know what I’m about to say. Either way, please do make sure you see Paulette’s thoughts.The point is that “did well in my class” letters don’t count for much because everyone who submits an application did well in the class that they would have had with their letter writer. Anyone should be able to muster that kind of a letter, and so it doesn’t help distinguish the so-so candidates from the great ones. It’s basically table stakes.

Graduate schools typically want comprehensive letters of recommendation that give detailed, nuanced evaluations of your strengths and potential as a student. A letter that simply states that you did well in class doesn’t give much insight into your intellectual ability, research skills, leadership qualities, or any other relevant attributes that graduate schools are looking for in applicants. Good letters generally come from people who’ve seen you work on more long term projects, in either a small-group reading class, or an independent study or a research project. Sometimes this could be a co-op/internship supervisor, depending upon where you did your co-op/internship. A one-off professor can’t offer that kind of perspective, because they didn’t get a chance to work with you in that manner.

If you already have all that other stuff covered, and just need like a third letter to fill out your set, then that’s probably a better fit! Another important caveat: an un-tenured professor probably has less credibility than a tenured one. When could a non-research letter go further than an ordinary DWIC? When I’ve seen an individualized project or two that you’ve worked on, and we’ve talked together several times about that project. When I’ve reaching out for help in a new course. If I can speak to you as a TA or tutor as well as a student. If I’m writing a letter for a masters program vs a phd, or a local scholarship vs a national one.

Be sure and let me know (1) what specifically you’re hoping for me to speak to, (2) how I can best help fit into your overall letters and application, and (3) tell me what kind of a program is this for. MS CS ? PhD CS? MFA, DDS, or MBA? A scholarship? It helps to know what I’m aiming for.

It will also help if you can provide:

• A transcript
• A résumé/vita, with all of your pertinent info in it
• Anything in particular you’d like me to try and emphasize.
• A(nother) link to the scholarship/program information (and if they have multiple, which one you’re applying to!)
• And also tell me about your other letter writers.

$ bash --version 
GNU bash, version 5.2.15(1)-release (aarch64-apple-darwin21.6.0)

Looks good. If, however, we then go and check the BASH_VERSION …

$ echo $BASH_VERSION
3.2.57(1)-release

We get a very different and worse number. What gives? Well, your login shell is using a different version of bash than is currently front on your path.

This SO thread helpfully describes the problem and the issue. If you are using the new version of homebrew, then you might have had to move where you keep the programs brew installs: the new location is /opt/homebrew/bin. If that’s the one you want to set as your login shell, then you’ll have to first add it to the /etc/shells file, and then use the following to set it.

chsh -s /opt/homebrew/bin/bash
sudo chsh -s /opt/homebrew/bin/bash

(If you failed to add that to your /etc/shells file, then chsh will squawk that this is a non-standard shell.)

But after this, you should be good to go with an up-to-date login shell.

1. Get a second email address that doesn’t obviously look like a backup email address. You don’t want job mail spam in your inbox for the rest of eternity.
2. Make job hunting your full-time job until you have one. It’s a 9-5 process. There’s a lead time before you’re going to start seeing results, and you don’t know how long that is, but don’t sit and wait for that one org of your dreams to get back to you.
3. Start with the “usual suspects” job recruiting sites—Monster, indeed, etc. Fill out profiles and filters and set yourself up with a feed for job leads.
4. Any place that has an RSS feed, find yourself an RSS reader and subscribe to them. This can be your work list, and mean there’s a whole bunch of sites you don’t have to check.
5. Work backwards in time, from most recent to more distant postings.
6. Niche technology where you have experience can be a good place to start, because they probably have trouble recruiting for that.
7. When you find a job you want to apply for, do it from the company’s intranet if you can.
8. Google itself also has job search listings now, and you can use that too.
9. Often times when you’re looking up a job listing, you’ll find another site on which that job is posted that you hadn’t looked before. This is how you build breadth to your job search. Let the job listings lead you to more sites, and the job hunt sites lead you to more jobs listings.
10. Recruiters/headhunters can be useful, get in touch w/them too.
11. If you’ve graduated recently enough, the school might still offer advice on your resume. Some schools have an alumni network that to tap. The other thing I’ve seen is to update your LinkedIn profile, see where your colleagues and contacts are working, and then go to those companies’ websites for listings.
12. In fact, you can also start picking out companies that you’ve heard of that you wouldn’t mind working for, and apply directly with them. That’s another way to increase your pool of job sites.
13. Use several common search strings for positions on the search sites. You know that “software engineer” “programmer” “computer scientist” “software developer” “platform engineer” can bleed across one another, but the sites don’t and HR might not either. If a site only lets you have one active search, then get another email address and another login to that site, and have your second search set up that way.
14. Make sure your resume is AI/search friendly. Use the key words and phrases that will get you past the automatic filters and into the hands of a human being.
15. Borrow the address of a friend’s couch. If you’re willing to relocate, and you have someone in the area, then you can put that person’s address on the resume making you look like a local hire. “I’ve been staying with a friend out there while I .. I just recently moved back to my place…” yadda. IME, by the time you’re far enough along that you seem like a candidate worth interviewing in person, then that won’t matter. If it does.
16. As I understand it, in person commuting-to-work jobs are going to be less competitive than the remote jobs, because a) people place a premium on the work from home and b) you are already excluding all the people who aren’t in or willing to be in a commute distance of that job.
17. You can and probably should have multiple versions of your resume tailored to different kinds of positions. Depending on what technology they want you to work with and what the role requires, you’ll emphasize different things in your background. If you can, make it look like you’re already an expert at doing the job they want to hire you for.
18. Double, triple check your emails and spelling and that you’re addressing the right company with the right job. If you can, build yourself a little program that will automate portions of your cover letter. If you’re building it with PDF, then using TeX macros \longname \shortname \mediumname \specialreason to fill in a cover letter could both save you time and frustration
19. Likewise, before you send something, have a tool read it to you, out loud. You can listen for mistakes that sound obvious but are difficult to pick out. You can do this on 2x speed if you’re quick enough. This isn’t a place to be lazy.
20. If you have time, especially if you think you’ll be off for a while, pull out that side project you’d been working on, and spend some nights and weekends on that. It’s something new you can show off, looks good on your GitHub commit history, and gives you something to talk about at an interview.
21. This may be less applicable, but if you’re going to be off work for a while having a volunteer position doing something related could be helpful just to keep a blank off your resume. OSS and side projects are nice too, but that doesn’t fit in a spot on a resume. Maybe start thinking about this in your second month off, so that you can have something in hand. A position that you’ve had for 6 months working one day a week looks better than 5 months off and then a whole month straight of volunteering.

I know it’s tough out there. Most of that is probably common sense to readers, but I hope there’s something in there that’s worthwhile.

Easy command line access requires a little bit of study and configuration.

Firstly, the right tool for the job.

BTW, SFTP =/= FTPS

If you don’t know, SFTP and FTPS are not the same thing. If a person talks to you about “secure FTP”, stop that person immediately and make them clarify to you which they mean. It’s possible that they don’t know either: trust, but verify.

I found the easy way to connect to our server (tltc-web1h-prod.shu.edu) was to simply brew install lftp. Scads of dependencies I needed to download and update all handled for me; man alive package managers are great!

But I run into a problem when I actually try to use this to get to my space now. I can connect, but when I actually try and move around, you run into the following error.

$ lftp -u hemannja,"$PASSWD" ftp://tltc-web1h-prod.shu.edu/hemannja/
cd: Fatal error: Certificate verification: self-signed certificate ...

Certificates and verification

This error message is saying that the server has a self-signed certificate authority, and so my system rightly doesn’t trust it. If this were a nefarious actor, well, it wouldn’t make any sense to take his own word that he’s an honest fella. But I happen to know that I’m really dealing with the machine I think I am, so I want to, for this guy only, accept the certificate that it’s providing me.

So I need to get the certificate that this server is presenting me

$ openssl s_client -connect tltc-web1h-prod.shu.edu:21 -starttls ftp
...
---
Server certificate
-----BEGIN CERTIFICATE-----
123...
...
...456789abcdefgihijklm==
-----END CERTIFICATE-----
subject=...
issuer=...
---

I needed to save that certificate itself as a certificate file. Just the certificate, mind you.

$ cat > ~/tltc_web1h_prod_AES-256.crt
...

Once I had that, I needed to add it so that lftp knew about it.

Luckily this was a solved problem. If you want to add it to your MacOS Keychain, they also have a help page for this.

For my software engineering class however, students (and I) will just need access to some software sometimes that isn’t installed. For instance, the default version of python is 2.7.

However! python3 is already installed! As python3. As you’d expect. To be more specific, version 3.6. So that’ll probably suffice.

However, suppose not. Or, just that we wanted to build python3.10.7 from source.

How to install python 3.10 on Red Hat Enterprise Linux Server

release 7.9 (Maipo) without root

There were several missing modules that were not installed but optional, one that the output of a failed make lists as mandatory, and one that same failure lists as optional but seemed actually necessary.

The configuration script says it’ll require a more recent version of openssl than the one we have installed.

So we go wget ourselves a tarball of the most recent version of openssl, and then try and configure it.

Well, the version of perl that we have on our system seems broken or malconfigured, because perl can’t find some basic comes-out-of-the-box install packages, e.g. ExtUtils::MakeMaker and Test::Harness. And we don’t have CPAN installed either.

Those modules are supposedly core—but I cannot seem to find them even though I have the standard perl5 installed.

So, the suggestion was to use something like perlbrew to just manage, a la homebrew, to install a local fresh installation of perl5. perlbrew is pretty cool!

Out of the box, that failed. But the instructions suggested running perlpatch, from the same download, to try and fix perl up before doing the perlbrew of perl.

However, in order to run that command, we need GNU patch which, you guessed it, isn’t installed on our machine.

I had to download patch from the GNU site

Installing in userspace

Since we’re having to install all of these in userspace, we’ll need to have a directory convention for the download and install of all this software. One of the keys is that most of these packages in their configure script tell you about either a PREFIX= or --prefix= configuration setting to let you install the software wherever you want (in your own space ofc).

From there, I had to then perlbrew install-patchperl

From there, I had to install (some) right version of perl 5.16.3 in my case.

From there I could finish installing openssl 1.1 and add that on my path.

Once I had that I was one step closer to installing python3, because the next issue was that I do not have libffi installed.

The correct way to solve this problem is to download the release of libffi, which has the installation script built in, and run that script.

Okay, now these prerequisites are seemingly installed. Why isn’t the install script running?

Flags to the configure script

One of the keys was to read the configuration options for the configure script. These are also reproduced online:

This gave me the flags and information for how to solve the missing libssl information.

These both describe the problem with the SSL installation, that may have been a bug in the install script expecting a different directory structure for openssl. And also these.

LD_LIBRARY_PATH

A little bit of cli-fu is just enough to hang yourself. Xah Lee gives a nice history lesson on some of the ways this can bite you. I may or may not have needed some settings for this install. But I did avail myself.

Scripting it!

Now that we have a way to build this, we’d sure like to not have to do it all over again by hand. The right thing to do here is to script the install. The expedient thing is diligent notes. We won’t expose all of it here, but certainly this could be useful to the diligent student reader.

./configure --prefix=$HOME/python \
  LDFLAGS="-L$SPOT/libffi/lib64/ -L$SPOT/openssl/lib/"
  CPPFLAGS="-I$SPOT/openssl/include/openssl/ -I$SPOT/libffi/include/"
  --with-openssl=$SPOT/openssl/

Takeaways

1. Be kind to your sysadmin. Buy that person chocolates and Christmas cards.

2. Read The Friendly Manual. The information you want is sitting right there. You can of course

3. Your browser is your friend. There was a time when you had mailing lists and man pages and you felt good that you did. Now, you also have the ol’ googler.

> (findf number? '(1 #f 2 dog))
1

Findf takes a predicate and a list, and returns the first element of the list for which that predicate holds true, returning #f in the case that the predicate holds for no member of the list.

So if we change 1 to one, then we will now get a different answer.

> (findf number? '(one #f 2 dog))
2

And if we change 2 to two, we get #f, as now no elements of the list are numbers.

> (findf number? '(one #f two dog))
#f

Lets instead ask a different question of this list: boolean?

> (findf boolean? '(one #f two dog))
#f

Whoa ho ho. What’ve we got /here/?

findf returns the first element of the list for which that predicate holds. #f is a boolean, so that’s what’s returned. Lo, the confusion that can result.

> (findf boolean? '(one two dog))
#f

Let’s look at the issue a bit more abstractly. The meat of the problem is that the value we’re using to denote an “error” (“failure”, “exception”, what have you) is /in/ the set of things that we could possibly return as /actual/ answers. Some languages use -1 as an error condition instead. Obviously, that’s no good as an error value here, either.

There’s not a safe value we can pick, because for whatever value we pick, it might be someone wants to hunt for precisely that value in their list. For instance, we might try to patch the problem above, saying to ourselves “Well, #f is useful. Comes up all the time. I’ll write my own findf, and pick a different thing.” Heck, we’ll choose this-obscure-symbol-means-failure-Qx29t7.

And that works great until some dingbat comes along and does the following

> (my-findf (lambda (y) (eqv? 'this-obscure-symbol-means-failure-Qx29t7 y))
           '(a b c this-obscure-symbol-means-failure-Qx29t7))
this-obscure-symbol-means-failure-Qx29t7

But as it turns out, that might not be such a dingbat thing to do, after all. All the time, we write code that generates code. Someone who’s generating Scheme code might very well have reason to hunt for that symbol in a list.

Anyhow. What’s clear is that the above suggestion is just sort of a patch. These sorts of things come up all the time. We report #f, -1, Error 404, etc., etc. It seems like there ought to be a unified approach to handling this sort of problem, and one in which we don’t have to kludge together some sort of an error code for each distinct case.

The maybe monad gives us the power to do both of those. It provides a generic way to handle and propogate failure, and, by virtue of being general, it means there’s no ad-hoc solution to the value that denotes an error.

We’ve got return and maybe, those new relatives of eta and * that we introduced. And we’ve also got fail, which is our way of signaling a failure.

(define return-maybe
  (lambda (a) `(Just ,a)))
 
(define bind-maybe
  (lambda (ma f)
    (cond
      [(eq? (car ma) 'Just) (f (cadr ma))]
      [(eq? (car ma) 'Nothing) '(Nothing)])))
 
(define fail
  (lambda ()
    '(Nothing)))

return is just another name for eta (or unit). More on that in a sec, but a quick reminder.

There’s lots of monads, and they all have the same type signatures for the return and bind, and they all have to obey those monadic laws. We’re gonna walk though, at a type level, what return and bind /are/, how those things relate to eta and *, why their essence and behavior makes sense, and then look at how the actual implementations of return-maybe and bind-maybe make sense.

Whew. That’s a tall order. Well, let’s get to it.

As we were. return is just another name for eta.

return : alpha -> Malpha

The job of return/eta is to take a “pure” value – that is, a value from the regular land of computation, and wrap it up in the monad (burrito) (or like Just above.)

For our maybe monad, there are two classes of things that are monadic values.

1 : (Just ), where is any old thing you choose. (Must it be a pure value?) 2 : (Nothing)

This second one is the value provided by invoking fail. Notice that because all the pure values are wrapped up in a list with Just at the front, then this (Nothing) doesn’t have the same problem as we had before with -1 or #f.

If I want to return #f out of my findf-maybe (which we’ll write in a second), it’ll come out as (Just #f). If I want to signal something’s not in there, it’ll come out as (Nothing). (Of course, that could be #f).

And now, let’s consider that same dingbat from before, trying to be cute again.

> (findf-maybe (lambda (v) (equal v `(Nothing))) '(-1 #f (Nothing) 404))
(Just (Nothing))

Ah-HA! Lookie there. Unlike before with Scheme’s findf, now we can tell when the failure value is exactly that thing looked up in the list, vs. when it’s actually returned as a failure value. We’ve got the problem licked. Well, as soon as we figure out bind, relate it to *, explain why bind-maybe makes sense as a bind, and use this to implement findf-maybe.

• was typed as follows.

• : (alpha -> Mbeta) -> (Malpha -> Mbeta)

That is, it takes a function and returns a function. A few months ago that in and of itself might’ve been mind-blowing, but it’s pretty old-hat now. BTW, if you need a mundane example, integral is the sort of thing that takes a function and returns a function.

In the biz, we always associate curried functions to the left. If I have something that looks like

f : int -> (bool -> (string -> (bool -> (string -> int))))

those parens start to get a bit annoying there.

So we instead write it as

f : int -> bool -> string -> bool -> string -> int

but we all know what that means. So you’ll more likely see * typed like

• : (alpha -> Mbeta) -> Malpha -> Mbeta

That is, it’s gonna be a function that takes an f, then it takes an ma.

(define *
  (lambda (f)
    (lambda (ma) ...)))

And does … well, who knows what the /particular/ implementation does at this point, but it does something like calling the function on that argument.

A quick digression, seemingly apropos of nothing. Let’s define an operator curried-app.

(define curried-app
  (lambda (f)
    (lambda (a)
      (f a))))

Nothing terribly fancy here.

BUT–imagine a world in which that’s the only way you apply functions. You don’t get to call them directly on their arguments. Instead, when you wanna apply a function, you pass it to curried-app, to which you then pass the argument upon which you wanna call that function.

There’s not much use to doing such a thing when we do our regular run-of-the-mill Scheme programming. But when we’re working with monads, it’s a necessity. By the way, did you notice the type of curried-app?

curried-app : (alpha -> beta) -> alpha -> beta

Remarkably, strikingly, /suspiciously/ similar to the type of *. * does what curried-app does, except it works over monads. When using monads, we’ve given up the necessity of doing our own function applications to arguments. It’s passe. Well, not really that, so much as we’re modeling effects, and we want to make sure the effects happen the right way. * (well, really it’ll be bind) is going to make sure that happens, ‘cause it and it alone is allowed to /do/ the application of functions to monadic arguments. So if * (bind) is right, then the whole process is right. We’ve deputized * (bind) as the function-apper. And because * (bind) has to obey the Monadic Laws if it’s to be a genuine, bonified, monad. Since we’re using pre-certified monads, we’re certain that they’re up to snuff, so if we just use’em correctly * (bind) will make all the applications work properly.

Alright, I’m done writing bind in parens. Let’s describe bind, so that we can just get to using it. A couple of things.

1. Writing code with nested calls to * starts to get uuuugly.

((* (lambda (x)
     ((* (lambda (y)
          ((* (lambda (z) ...))
           arg3)))
      arg2)))
 arg1)

The flow of control is going to the right. Programs written this way end up building these giant rightward dagger shapes.

1. By doing all of our monadic code with calls to a function-apper mechanism, it makes sense to think of that part of the program as doing work in units of function-apping. “Do a *, which then demands another *, which …”. Why bother to curry *? Nothing’s gonna happen until we give it both parts, and it’s not really of use to do’em one at a time.

It’d be nice if my code read linearly, down the page, rather than having to follow it out in that triangle pattern, and if I treated these applications of function to argument as the real unit of work.

Bind does both of those.

The type of bind is

bind : (Malpha x (alpha -> Mbeta)) -> Mbeta

That is, it takes two arguments at once, the argument and the function, and it takes’em in that order. Notice, now, if we have some stuff that’s nested, then the work that we do next, that’s part of the function body, will be underneath the stuff above. We can read what’s going to happen in order down the page.

(define bind-maybe
  (lambda (ma f)
    (cond
      [(eq? (car ma) 'Just) (f (cadr ma))]
      [(eq? (car ma) 'Nothing) '(Nothing)])))

So here’s our definition of bind-maybe, again. We can see it’s doing at least part of what we wanted it to do. It takes two arguments, in the right order. We know that ma is one of the things in my maybe monad. Which means it’s either a (Just ) or (Nothing). In the first case, it's a real and actual value. In the second, there was an error/failure/exception/badness up the road. If there was an error, we can't compute on it, and we wanna propagate that forward. So if we had an error, we return an error.

If instead we had a (Just ), a non-error value, well we wanted to do that application. f takes a pure value. We see that, here. Look, it's taking the cadr of ma. bind, as we theorized, knows how to take the ma, unwrap the burrito and get ahold of the a, and call f on it. Whatever comes out of bind needs to still be in the monad. Pretend this bind is the last thing we do before we end the computation. Well, I want to make sure I can tell the difference between returning (Just (Nothing)) and (Nothing), like that yahoo tried to pull earlier.

f, the function we pass in, the one we’re gonna build, needs to be of alpha -> Mbeta. That way, the thing we hand back is still safely nestled in the monad. That’s the reason behind the “monads are space-suits” metaphor. You can’t open a space-suit willy-nilly. You’ve got to do it nestled safely inside a space-capsule. If you do it outside, or go outside not wearing one, you’ll die in the cold, cold, blackness of space. Alone. That’s what happens to you if you try to get at the pure inside the monad when you aren’t supposed to.

A word about those alphas and betas there. They don’t /have/ to be distinct types. They can be. But they don’t have to be. I’m gonna put some !s around the parts that you really wanna pay attention to about the type of bind.

bind : (!Malpha! x (!alpha! -> Mbeta)) -> Mbeta

The point is that the thing f takes as an argument is exacty the same type as the first argument to bind, except the first argument to bind has it all wrapped up in the monad (burrito).

So that’s the gist of what maybe is. Let’s real quick write findf-maybe and, ‘cause findf-maybe doesn’t show off everything we’re gonna wanna do, we’ll write a somewhat contrived example that’ll show off bind-maybe, too.

(define findf-maybe
  (lambda (p ls)
    (cond
      ((null? ls) (fail))
      ...)))

So far, so good, this makes sense. We’ve been promising that we’ll return (Nothing) when we can’t findf the thing. Whelp, that’ll do it.

(define findf-maybe
  (lambda (p ls)
    (cond
      ((null? ls) (fail))
      (else (let ((a (car ls)))
              (cond
                ((p a) ...)
                (else ...)))))))

So here, we’re just setting up and being a bit fancy. I happen to know for a fact that we’re going to need a couple of times, potentially, so I’m let-binding it above. There’s the remaining two cases: either (p a), or not. We’ll handle’em one at a time.

(define findf-maybe
  (lambda (p ls)
    (cond
      ((null? ls) (fail))
      (else (let ((a (car ls)))
              (cond
                ((p a) (return-maybe a))
                (else ...)))))))

We wrap the thing up in the monad. findf-maybe is written to have return-type Mbeta. Which makes sense, according to our spec. We wanted it to return the stuff wrapped up, again, so we could tell the difference. That’s why we put it through return. Final case, the recursive call. Well, findf-maybe spits back something of Mbeta, which is what we’re after, so nothing special to do here, just the plain-ol’ regular recursion.

(define findf-maybe
  (lambda (p ls)
    (cond
      ((null? ls) (fail))
      (else (let ((a (car ls)))
              (cond
                ((p a) (return-maybe a))
                (else (findf-maybe p (cdr ls)))))))))

Voilà. Go forth and findf to your heart’s content. I promised another example, this time with bind-maybe. We’re gonna try to write an operator that’ll take a list of numbers and return the product of their reciprocals. Why? You caught me, no good reason. But let’s do it anyway, for sport. Or something.

Now, the thing about reciprocals is that zero doesn’t have one. Division by zero is undefined. So when we try to do this, we’re gonna have to be on the lookout for a zero, and if we hit one, we come back out with (Nothing).

(define prod-recip-maybe
  (lambda (ls)
    ...))

We’re just gonna blast right through to the new and interesting bit.

(define prod-recip-maybe
  (lambda (ls)
    (cond
      ((null? ls) (return-maybe 1))
      (else
       (let ((a (car ls)))
         (cond
           ((zero? a) (fail))
           (else ...)))))))

So we’ve got a non-zero number in the car. Let’s do the recursion, get that value, and then use it to return the value we’re really after. I’m doing the recursion, which means I’m coming back with a value in the monad. And then I wanna do something with the value of that recursive call, to get the value of the whole expression. This is a job for bind-maybe. If this was being done non-monadically, and we were using curried-app, again, it’d look like

((curried-app (lambda (rec) (* a rec)))
 (prod-recip-maybe (cdr ls)))

But we’re not, we’re 1. in the monad, and 2. really /done/ with that curried-app thing. Since we’re in the monad, bind-maybe’s gonna do the job of pulling the pure out of the monadic value. And we’re gonna make sure that that function returns a monadic value, ‘cause the next fella up the line is expecting a value in the monad.

(define prod-recip-maybe
  (lambda (ls)
    (cond
      ((null? ls) (return-maybe 1))
      (else
       (let ((a (car ls)))
         (cond
           ((zero? a) (fail))
           (else
            (bind-maybe
             (prod-recip-maybe (cdr ls))
             (lambda (rec)
               (return-maybe (* (/ 1 a) rec)))))))))))

Well done. Buut, that is looking a little long, and is slightly obscuring. That do syntax we introduced would certainly clean some of this up.

(define-syntax do
  (syntax-rules (<-)
    ((_ bind e) e)
    ((_ bind (v <- e) e* e** ...)
     (bind e (lambda (v) (do bind e* e** ...))))
    ((_ bind e e* e** ...)
     (bind e (lambda (_) (do bind e* e** ...))))))

It’s your standard, run-of-the-mill syntax-rules macro. We take which bind function it is, and a whole bunch of expressions, and expand out into nested calls to that bind in the right fashion. For our case, this yields

(define prod-recip-maybe
  (lambda (ls)
    (cond
      ((null? ls) (return-maybe 1))
      (else
       (let ((a (car ls)))
         (cond
           ((zero? a) (fail))
           (else
            (do bind-maybe
              (rec <- (prod-recip-maybe (cdr ls)))
              (return-maybe (* (/ 1 a) rec))))))))))

And /there/ we go.

Now, Go Eat A Burrito! Maybe While Wearing A Space-Suit!

(straight-use-package 'eri)
(straight-use-package 'agda2-mode)

I included both of these in my .emacs configuration, asking straight.el to load, and install if necessary, both of these packages at start-up. However! It turns out agda2-mode already includes eri! But straight doesn’t know that. So instead we need to inform it of that fact.

(straight-use-package '(agda2-mode :includes eri))

It turns out that agda2-mode contains within it a couple of things, so straight.el provides some extra syntax for passing a list of options.

(straight-use-package '(agda2-mode :includes (eri annotation)))