back
5 comments
As a calculator, wouldn't it make more sense to use Num from the standard library than int?

FWIW, you don't end up doing a cumbersome amount of matching if you implement a full Lisp with an expression ADT as mentioned in the README. I have a little dynamically scoped Lisp interpreter in OCaml lying around somewhere that was about 100 lines taking that approach.

Also, a Num implementation is now available; thanks for the suggestion. However it just hits the 50-line limit :p

https://github.com/eatonphil/ocalc/tree/use-num

Cool. You might find selective use of "let open Num in" helps cut down on the added noise.

The #ocaml channel on freenode is a pretty good place to get review comments, BTW.

Obviously the branch was done quickly, but at a short glance it was easier not to use an extra line to add `open Num` at the beginning.

Good call on the irc channel. Thanks!

I was hoping for some feedback like this. You're right, I think I could solve it by using an ADT and splitting `apply` into two parts: atom-ops and list-ops.

  module LispData = struct
    (* eventually support more than just strings as ints *)
    type t = Atom of string | List of string list
    let create v = (v, if is_atom v then `Atom else `List)
    let recover (v, t) : t = if t = `Atom then as_atom v else as_list v
  end

  let rec apply car cdr = match LispData.recover car with
    | atom `Atom -> atom_ops atom cdr
    | list `List -> list_ops list cdr
This is what I'm thinking, roughly speaking.