DEV Community: James Liu

Symbolic logic and programming

James Liu — Sun, 13 Sep 2020 00:19:10 +0000

I am working my way through VanDrunen's Discrete Math and Functional Programming. Symbolic logic is dealt with in a single chapter from beginning through multiple quantification. Here are some thoughts.

It took a quarter-long course, Logic I, in college to get through that material. It was a long time ago, and I am glad it has stuck as well as it did. I am breezing through the chapter as if through well-trodden ground.
This chapter is 1/7 of what the author thinks should be covered in a semester-long class with "bright" math and CS undergrads. So I guess about 2 weeks.
The book, as the title suggests, also covers programming. I think the programming aspect helps with the comprehension of logic, so that partly explains how it is squeezed into so much less space.
All the extra how-to-prove-it material would have been really helpful when I got to Logic II. Logic I was way too slow, Logic II, which proved the soundness and consistency of first-order logic, was much too fast.

Use Dr. Racket for Reading The Little Schemer (or the missing setup instructions for The Little Schemer)

James Liu — Sun, 26 Jul 2020 04:38:31 +0000

TL;DR

Mostly, note cards and pencil is fine.
Use Racket, and in fact, use the Dr. Racket IDE.
Wrap strings in ""
Quote list literals, so '(a b c)
Use Dr. Racket's testing capabilities to save yourself work

Use Dr. Racket for Reading The Little Schemer (the missing setup instructions)

Why The Little Schemer

The Little Schemer is a classic Lisp book, which often comes recommended for newbies to Lisp who need an easier on-ramp to Structure and Interpretation of Computer Programs. Personally, I tried working my way through SICP on my own, made it some way in, and decided learning how to program in Scheme and understanding SICP was too much all at once.

In the preface, the authors write that "The Little Schemer is based on lecture notes from a two-week 'quickie' introduction to Scheme for students with no previous programming experience and an admitted dislike for anything mathematical." Great. I definitely have at least as much programming and math aptitude as that.

Mostly, I have been working on it with note cards with pencil. The advantage is that I can cover the answer while I read the question, and I get the benefit of working out the question before I see the answer. But sometimes, I want to run the code to check my work before revealing the answer.

Setting up Scheme 💾

Unfortunately, there are not setup instructions. Since the book was published in 1996, it seems unlikely setup instructions are going to do much good--it being the era of Windows 95 and Mac System 7. Back then, the internet came in the form of AOL CD-ROMs! 💽

At the time of writing, the first Google result for "install scheme" points to this tutorial, which is for installing MIT Scheme on Windows. Unfortunately, MIT Scheme no longer even supports Windows. But don't worry, if you want, you can get a dialect called Chez Scheme with a Windows installer, as an apt package, or even using Homebrew.

Really, just get Racket 🏸

But don't do any of that. Instead, get Racket. Racket is a descendant of Scheme, and as far as I can tell it stopped calling itself a Scheme because it stopped being so purely minimalist (a sense I get mostly from listening to podcasts).

Racket is nice enough to come with an installer. It also comes with an IDE, which, OK, I was skeptical at first because it looks a little outdated, but it is actually quite nice. Further, it comes with a book called How to Design Programs (which comes with its own manifesto about how SICP is too hard for beginners).

For something simple, you can use Racket from the REPL, and type in the form in the preface for checking if something is an atom. What happens when we try typing this in?



(define atom?
      (lambda (x)
        (and (not (pair? x)) (not (null? x)))))

Uh oh.

To correct that, try (atom? "atom"). Ok, so string literals have to be wrapped in double quotes. But also take a look at what has to happen with lists:

So you need to quote lists so the interpreter knows the difference between a list, (quote (a b c)), or '(a b c) for short, and a function a with arguments b and c, (a b c). When people say that in Lisp, code is data, it refers to being able to quote and unquote lists.

But really, use Dr. Racket

Dr. Racket, despite looking like it is from the early 2000s, is great. It supports auto-indentation, auto-closing parens, and Unicode (so you can write λ instead of lambda, or use emoji). There are other nice features, like drawing lines to indicate the scope of variables.

Use Dr. Racket by writing your definitions in the definition area. After you run them, you can interact with your functions in the interaction area. Since Dr. Racket supports many languages, you have to declare #lang racket at the top, or select another language from the language dropdown at the bottom right. For Little Schemer, just use Racket.

Also, Racket includes a test-runner, so you can write tests to make sure that the code does what you expect. Some of the questions and answers give you test cases you can manually run to check the function you are writing. But that gets tiresome, and it is easy to write out your test cases as automated tests.

You can begin your exploration like this:

Here is the definition area as text:



#lang racket
(require test-engine/racket-tests)

(define atom?
  (λ (x)
    (and (not (pair? x)) (not (null? x)))))


(define lat?
  (λ (x)
    (cond
    [(null? x) #t]
    [(atom? (car x)) (lat? (cdr x)) #t]
    [else #f])))


(check-expect (lat? '()) #t)
(check-expect (lat? '("hi")) #t)
(check-expect (lat? '('())) #f)
(test)

And the interactions area:



Welcome to DrRacket, version 7.7 [3m].
Language: racket, with debugging; memory limit: 128 MB.
All 3 tests passed!
> (lat? '("Dr." "Racket"))
#t
> (atom? "️")
#t
>

How to use async/await with map and Promise.all

James Liu — Mon, 04 Nov 2019 03:44:27 +0000

I found myself stuck on using the map function with async and await. It took me relearning how to work with promises to figure it out, but once I figured it out, the syntax turned out to be pretty nice and readable.

JavaScript's async and await syntax is new as of ES2017. I think the syntax is really neat because it allows me to write shorter, easier to understand code than a pyramid of promises and thens, similar to how promises are an improvement on callback hell. There are more comprehensive explanations of async and await out there, like this one from MDN, from Javascript.Info, and from Dr. Axel R. Here is a JavaScript Jabber episode, super helpful.

But what happens when you want to get back a bunch of data from a bunch of requests? There is no await all in JavaScript. That's where Promises.all() comes in. Promises.all() collects a bunch of promises, and rolls them up into a single promise. Once all of the inner promises resolve successfully, Promise.all() returns a resolved promise with all of the inner promises as resolved. To make things faster, once any of the inner promises rejects, Promise.all() rejects.

The main point is that Promise.all() turns an array of promises into a single promise that, if things work, resolves into the array you want. Everything else is just details.

Somehow, it took me a long time to get unstuck. Here is the code that I finally got working, and hopefully this helps with that explanation.

Suppose you hit a REST endpoint and get an array of URLs for the REST endpoints which contain what you are ultimately after. For example, you know want to find some information about the movies R2-D2 was in from the Star Wars API. For whatever reason, you can't use the SWAPI GraphQL instead. We know that fetching from the network is an asynchronous operation, so we will have to use callbacks, promises, or the async and await keywords. Since R2-D2 was in several movies, will have several network calls to get all of them.

So first, let's set up. Let's focus on just the smallest bit of functionality we're working on, so we'll use Node.js on the command line. Node.js doesn't come with fetch, so let's install it with npm or yarn.

npm install node-fetch --save-dev

yarn add node-fetch --dev

One gotcha with async/await is that an await keyword is only allowed inside an async function. In a real program, you're probably encapsulated enough so that you can just slap an async keyword on the function you're using the await keyword in, but inside of a scratch file, we want to abstract away from the enclosing context. But as Javascript programmers, we know how to get around that by wrapping what we want in an instantaneously invoked function expression.

// prettier-ignore
const fetch = require('node-fetch')

// prettier-ignore
(async () => {
    try {
      let characterResponse = await fetch('http://swapi.co/api/people/2/')
      let characterResponseJson = await characterResponse.json()

      console.log(characterResponseJson)
    } catch (err) {
      console.log(err)
    }
  }
)()

So now we have the basic async/await syntax working, and we can inspect the response to see that we want the films field. It is an array of URLs.

let films = characterResponseJson.films.map(async filmUrl => {
  let filmResponse = await fetch(filmUrl)
  let filmResponseJSON = filmResponse.json()
  return filmResponseJSON
})

console.log(films)

When you run this code, you get an array of pending promises. You need that new async, otherwise the awaits inside the arrow function won't work. If you don't await for the fetch, you get a bunch of rejected promises, and errors telling you to handle your promise rejections.

But recall, a Promise.all() takes an array of promises and wraps them into a single promise. So we wrap our map function. And we already know some nice syntax for dealing with a single promise. We can await it.

let characterResponse = await fetch('http://swapi.co/api/people/2/')
let characterResponseJson = await characterResponse.json()
let films = await Promise.all(
  characterResponseJson.films.map(async filmUrl => {
    let filmResponse = await fetch(filmUrl)
    return filmResponse.json()
  })
)
console.log(films)

For the sake of comparison, the equivalent code in promises looks like:

fetch('http://swapi.co/api/people/2/')
  .then(characterResponse => characterResponse.json())
  .then(characterResponseJson => {
    Promise.all(
      characterResponseJson.films.map(filmUrl =>
        fetch(filmUrl).then(filmResponse => filmResponse.json())
      )
    ).then(films => {
      console.log(films)
    })
  })

For me, the first set of .then().then() is pretty semantic, I can follow that almost as well as the async/await syntax. But once we're inside the Promise.all(), things start getting hard to follow using only the promises syntax. Whatever action we are going to perform on the films will replace the console.log, and in the .then chaining syntax, that is already buried 3-levels of indentation deep. Shallow code is easy to understand code.