Ignore newlines that appear inside parens

Codegen is an implicit dependency in the build process. Alternative targets can be supported as either --target [target] if the target is bundled with the LM compiler, or alternatively with a --assembler [assembler.lm] arbitrary custom assembler.

The assembler must define a function assemble(options: S, program: S) which will then finish the compilation. The LM compiler in this case will still perform the functions of a parser, preprocessor, and build tool.

The example should really just work...

74 / 77 passing.

Architectures:

• x86-32
• x86-64
• ?

OS:

• Linux
• OSX
• Windows

I use nano...

It would be nice to have global namespace view vs local function definitions views in an editor. An integrated library search and project build manager would be nice too.

Typed LM Codegen is fairly different than the bootstrap release. I have pared down the bootstrap compiler to just tokenization and parsing. Now we should introduce typechecking before reconstructing the codegen. Also some of the optimizations from the bootstrap book can reduce memory use by 50%.

It would be nice to provide a frontend to search for existing libraries with functions that provide some functionality. This could be links to github repos that get downloaded or crates that get added as dependencies.

This would be most useful after types and ad-hoc polymorphism get implemented to avoid conflicts in the global namespace.

let or other functions that manipulate volatile locals like registers or stack can't be called with normal operational calling conventions. The code actually needs to be expanded inline like a macro, but that makes things like labels and local jumps potentially problematic. There are a host of problems here.

I think the correct solution is type-sensitive specialization, but that isn't available in the bootstrap compiler.

It would be nice to have a reference implementation.

Turn typed assembly into PunC expressions. LM can provide the parser.

Only two registers are really needed to represent a cons cell. It might be an interesting exercise to try to generate a 2,3,4 register compiler version to see how flexible the register assignment strategy can be.

"I want to represent an S-Expression with 2 registers. Generate some code for me."

(side effect 1)
(side effect 2)
return

is better than

(tail(
   (side effect 1)
   (side effect 2)
   return
))

asm!( mov( $0 %r12 ) )

is different from just

mov( $0 %r12 )

The asm! rule has it's own namespace and calling conventions.

rewrite

expr := expr-mul '+' expr
expr := expr-mul '-' expr

as

expr := expr-mul |> '+' expr
                 |> '-' expr

to avoid exponential explosion in descent

Currently the default return is ().

eliminate argv construction if it is never referenced.

Add a --gradual flag for the compiler to enable implicit casts into/out-of S-Expression representation.

Bring this story to life:

rhs        := [a-z][_a-zA-Z0-9]*   //Variable
            | ( rhs* )             //Function Application
            | λ rhs* . rhs*        //Lambda Function
            | [^ ]+                //Literal Value

binding    := [a-zA-Z0-9]+ [:] [=] rhs \n

program    := binding*

example recursive descent parser:

• top to bottom (previous rule candidates have higher precedence over following rule candidates)
• terminal to non-terminal (terminal symbols have higher precedence over non-terminal symbols within same rule)
• left to right (left symbols have higher precedence over right symbols within same rule)
• this parser generator is for up-to free grammars and requires infinite lookahead in worst case

nibble-lhs := λ"a" a. a
nibble-rhs := λa "a". a
nibble-nonterminal := λ(nibble-lhs a) b. a b
nibble-empty := λ. "a"
nibble-tokens := λ(ident n) (eq _) (rhs r). (Assign n r)

Default Atom Representation should be (char* offset_start offset_end) instead of just char*.

Chain and Apply are the most primitive functional operations. They have default behaviors but there is also specialization to override that. Explicit vs Implicit arguments make this interesting too.

      Implicit    <->     Explicit
      ^                      ^
chain |                      | apply
      v                      v
      Implicit    <->     Explicit

After all the sugar gets taken off, f x just calls (chain implicits f x)

The program should accept a special symbol ::infer that can be used for type inference. This term will be applied with a Type Context and a Term, returning a new Term.

The chain rule for functions applies the function, otherwise it makes a Cons cell.
It would be nice if users could define custom chain rules.

( (App (: f (->(x y))) x) ... apply function ... )
custom chain rules go here
( (App l r) ... yield cons ... )

--tokenize
--parse
--compile

✓ Bootstrap Compile a CLI
✓ Bootstrap Compile a CLI that dumps S-Expression fragments
✓ Bootstrap Compile a CLI that normalizes then dumps S-Expression fragments
✓ Bootstrap Compile a CLI that parses, normalizes, then dumps S-Expression fragments
Bootstrap Compile a CLI that parses, normalizes, then assembles S-Expression fragments

there are roughly 15 symbols in the data section that are required by the runtime. This # should be 0.

The current compiler wastes too much memory to bootstrap.

Generating assembler as an intermediate is annoying and unnecessary. Assembly should only be used for debugging.

https://github.com/netwide-assembler/nasm

eval-soft can just echo parsed input for now. eval-hard can be eager reduction for simplicity.

compile the LM bootstrap to assembly and attach as another bootstrap option.

• ✓ car/cdr bootstrap for interpreter
• interpreted codegen bootstrap
• optimized binary generation from idyllic LM codebase

"abc"[0..2]

is better than

"abc".substring(0,2)

it also comes with free file position tracking.

This could help pinpoint corruption and help push this language from low-level to mid-level of abstraction.

This may have caused a memory issue, not sure.

There are 100s of Apps in the compiler but only one is necessary.

(f 1 2 3) is a lot easier to read than (f (1 2 3))

Define a generic interface to Cons/Atom allocators. This is necessary to bring the runtime down to zero implicits.

There are some test cases on the dev branch for this.

REPL

lambda_mountain repl
> p := λx. x x
> p := λx x. x
> p a a
a
>

LM can have an internal IR representation of assembler code. It would also be good to be able to read and write from different syntaxes. This starts to address the MxN problem of multiple frontends, multiple target platforms.

Internal Representation

• Platform Specific Functionality
• Platform Independent Logic

let is a macro that manipulates the stack frame, how should this be modelled? Assumptions about the registers and memory model are implicit parameters to all functions.

A simpler example would be to model the type signature of push %ax.