42 comments

[ 3.1 ms ] story [ 91.8 ms ] thread
Hi Hacker News PL enthusiasts. This is off topic, but I hope you will have mercy on me.

I'm reaching out for some help from you. I've been working on interpreters this whole year, taking on no more work for pay than needed for rent and food, so that I can realize my programming language dream. I'm writing a couple of interpreters every week, trying out new ideas. But there is one hurdle I've been unable to overcome for a long time.

I'm trying to write a typechecker for a simple lambda calculus with polymorphic functions. My acceptance criteria is being able to typecheck the K combinator. I've been stuck at this point for months. Have read all I can find on the internet, and have read TAPL many times.

Am honestly feeling really stupid for not having been able to complete this.

What I'm struggling with beta reducing expressions that are type lambdas (i.e. the expression related to `Forall`).

Λ means type lambda, i.e. the set of expressions indexed by type

λ means expression lambda, i.e. the set of expressions indexed by expression

E.g. Λa.λx:a.x is the polymorphic "identity" function, which in javascript looks like `x => x`

k = ΛA.ΛB.λx:A.λy:B.x

k_intint = ((k IntTy) IntTy)

What I have yet been unable to do is type_of k_intint, and this because beta reduction should return an expression, but type_of should return a type.

I'll paste the source code of my latest attempt below, the function in question is `typ_of_expression`. I've written this in OCaml, but would be very thankful for a response in any language, or pseudocode, or just explained in English.

Many thanks for taking the time to read this. For any reply or pointer in the right direction I would be greatly thankful. You know what, I'd be happy to pay €100 for any help that lets me solve this (SEPA, Bitcoin).

  (* λ calculus, with Forall and simple types *)
  type 'a binding =
    | SymBind of 'a
    | QuantifierBind

  type 'a context = (string * 'a binding) list
  
  type typ =
    | UnitTy
    | IntTy
    | Arrow of typ * typ
    | Forall of string * typ
    (* Thought it simpler to separate Closure and Lambda, for w  hen I later add records/unions etc *)
    | ClosureTy of (typ context) * typ
    | SymbolTy of string
  
  type expr =
    (* again thought it simpler to separate Closure and Lambda,   for when I later add records/unions etc *)
    | Closure of (expr context) * expr
    | Unit
    | Symbol of string
    | Int of int
    | Lam of string * typ * expr  (* turns into Arrow. Takes ex  pr as argument, returns expr *)
    | App of expr * expr
    | TLam of string * expr       (* expr version of Forall. Ta  kes typ as argument, returns expr *)
    | TApp of expr * typ
  
  let rec lookup context key =
    match context with
    | [] -> Error "No result"
    | (k, QuantifierBind) :: rest -> lookup rest key
    | (k, SymBind v) :: rest -> if key = k
                                then Ok v
                                else lookup rest key
  
  let str = String.concat ""
  
  let rec string_of_typ t = match t with
    | UnitTy -> "UnitTy"
    | IntTy -> "IntTy"
    | Arrow _ -> "Arrow"
    | Forall (s, t) -> str ["Forall "; s; " "; string_of_typ t]
    | ClosureTy (_ctx, t) -> str ["Closure "; string_of_typ t]
    | SymbolTy s -> str ["SymbolTy "; s]
  
  let string_of_expr e = match e with
    | Unit -> "Unit"
    | Closure _ -> "Closure"
    | Symbol s -> str ["Symbol "; s]
    | Int i -> str ["Int "; string_of_int i]
    | Lam _ -> "Lam"
    | App _ -> "App"
    | TLam _ -> "TLam"
    | TApp _ -> "TApp"
  
  (* Convert between context types, such as (expr context) or (  typ context) *)
  let rec convert_context converter_fn original_context exprcon  text acc = (* カリたべたい *)
    let con...
> λ calculus, with Forall and simple types

Just fyi, this is called System F.

I do not remember any OCaml and I get an error when trying to run it (File "./test.ml", line 123, characters 6-7: Error: Syntax error: operator expected.) so I do not know if I can be of much help. What is the result of typ_of_expr [] (app k_intint (Int 1))? I presume that you expect it to be IntTy -> IntTy, right?

Thanks for your reply.

It is indeed system F I'm trying to implement :-)

My formatting for HN seems to have screwed the program up. You'll find the contents of systemf.ml in this paste: https://pastebin.com/gw20LBNR

Here is the result from my OCaml repl:

  # typ_of_expr [] (app k_intint (Int 1));;
  - : (typ, string) result =
  Error "Type mismatch. t0_0: SymbolTy a, t0_1: Arrow, t1: IntTy"
You are correct about what `(k_intint (Int 1))` should be. I hope for `k_intint` to be `IntTy -> IntTy -> IntTy`.
I am pretty sure that the type variable is not binded properly (when type checking App on the part where it says "(Ok (ClosureTy (ctx, Arrow (t0_0, t0_1)))," I get a symbol for t1, you are doing t1 = t0_0 which would be false in any case but the thing is that even when I use lookup in the enviroment I do not find said symbol). I would suggest instead of having closures to replace every occurrence of the type variable (or any variable really) during evaluation. So if you have something like ((\Lambda t (\lambda x t x)) int) to evaluate it into (\lambda x int x) directly instead of (\lambda x (sym "t") x) + a separate environment thing. I can give you my System F implementation in haskell that uses this method if you want.
I'm not gonna read all your code, and I'm not even sure if this is your problem, but just as a pattern match based on what you said: for System F, only the first and second ranks have decidable inference, not the whole thing. Inference in the first rank is often referred to as the "Hindley-Milner" algorithm; you can infer types for the second fragment but I'm not aware of an implementation. After that it's undecidable.

To put that another way, if `forall a.` introduces types (it's like the big lambda), then you can only have a type with `forall`s on the left on the outside. So:

`forall a. forall b. a + b` is a type but

`forall a. a -> forall b. b -> c` is not a type since that `forall` isn't all the way on the left in a chain like the first one.

If you're not in that fragment, and you're trying to infer types, you're gonna have a bad time unless you've got something exceedingly clever up your sleeve.

So `ForAll` should not be one of the "Type" type constructors. It should be its own type, like

    # The int is the number of variables bound, then the type is the type that uses them
    data Scheme = Int Type
    data Type = 0 | 1 | Var Int | Product Type Type | ...
As far as I see, you don't really seem to even try to infer types. With fixes to `string_of_*` routines (yeah, some cases are missing) the particular failure is as follows:

    ty(TApp ...) = Closure (Arrow (SymbolTy a) (Arrow (SymbolTy _b) (SymbolTy a)))
    ty(Int 1) = IntTy
    ty(App (TApp ...) (Int 1)) = Failure
      "Type mismatch. t0_0: SymbolTy a, t0_1: Arrow (SymbolTy _b) (SymbolTy a), t1: IntTy".
Here `t0_0` is a formal argument type and `t1` is being applied, so even though they are structurally different it should be inferred that `SymbolTy a` equals to `IntTy` (probably by updating the context). But your code doesn't do that.

I strongly recommend to first familize yourself with Hindley-Milner type system (and possibly Algorithm W) which type inference is efficient and easy enough to understand. Even though the decidable type inference in System F is impossible, the basic techniques for (partial) type inference are not too different.

Calling this a lisp is a bit of a stretch. S-expressions aren't lisp if they don't have lisp semantics.
What part of the code that will compile under this simple compiler (i.e. `(+ 2 (+ 3 4))`) _doesn't_ have lisp semantics?
Lisp uses S-expressions but not all the S-expressions are lisp. If you cannot define functions with free variables then is not lisp.
Integer overflow.
Not all historic dialects of Lisp have bignum integers. I don't know what the current situation is in Emacs Lisp, but it had only fixnums at one point.
Eval... as in REPL, is tough without an interpreter in process.
I would say this:

- tokens are just collections of non-space characters, passed raw through to an assembler, where it is assumed that they denote machine words. Whatever happens, happens. The "symbol" eax will refer to a register, for instance. (If this project had stuck with AT&T assembly syntax, at least that would have been qualified as %eax%).

- functions aren't registered under Lisp symbols but are just global references to assembly-language labels. It seems we can just do (1234 4) and it will just call address 1234.

- no LIS)t P)rocessing to be seen here.

That said, there is no language that is just "Lisp", and so there is no prescribed set of semantics. We can make a prefix expression preprocessor for x86 assembly language and call it "Phil Lisp" (or whatever qualifier).

For those who don't know. What exactly are the semantics of lisp?
This is really a minimal translator from s-exprs to assembly. Which is still an interesting project.

To be a lisp, you need to be able to declare and call functions, and construct and manipulate lists. Once you have that, you can then manipulate the code itself since s-exprs are just lists of a certain construction.

"[Assembly is] 1:1 representation of the binary instructions the CPU can interpret". 99% correct.
Assembly is NOT a 1:1 representation of the binary instructions. It is for the 99% of a given assembly. Pseudo-instructions exist in most assemblers and they usually translate to several machine code instructions.
(comment deleted)
Ok, I get this is a DIY post, but wouldn't it make much more sense to use LLVM here? That way, you get low-level optimizations for free, and this allows you to focus on the rest of the language. You can always implement the code-generation part if you want to and have the time for it.
I think you answered your own question with the last sentence.
You could learn more from targeting an intermediate language than from targeting a specific architecture, imho.
Maybe you learn "more". But you learn very different things.
Compiler without a Grammar...
What do you mean?
The article is about "compiler basics", but it never mentions PLs are parsed according to context-free grammars, let alone giving one. Just throws a bunch of code and says "yeah this'll parse it".
Maybe because compilers nowadays are mostly not about syntax? Parsers are the boring part.
Why not just compile "primitive" functions call to respective assembly code? (+ => "add")
> In a better compiler, we would not make plus a built-in function. We'd emit code for the assembly instruction ADD. However, making plus a function makes code generation simpler and also allows us to see what function calls look like.

:)

Years ago I read an article or paper about writing a lisp compiler. The compiler started with regular looking lisp, then through macro expansion lisp primitives were defined in terms of each other. Then the small subset of lisp primitives were expanded to goto's and conditionals. The gotos and conditionals were still expressed in lisp S Expressions. Finally the gotos and conditionals were implemented in terms of assembly looking lisp primitives. Then they removed the parentheses and it left an assembly program.

I can't remember the name of the paper. Any ideas? It was such an elegant way of walking through a compiler implementation.