~jojo/Carth

ref: 749208029494a7c48ce04444a513424f4b998416 Carth/carth.cabal -rw-r--r-- 4.1 KiB
Update stackage release & use default-extensions in cabal file

Also, fix some minor breakages caused by ghc update, fix the
literate.org example, fix some new warnings, and get rid of the need
for a bunch of Data implementations by using basic parsing functions
in SystemSpec.hs.
Update carth.cabal to reflect move to sourcehut and .md README
Add primitive, single pattern macros

E.g. `(defmacro (plus a b) (+ a b))`
Make parser act on token trees instead of chars
Reorder build-depends in cabal to clarify which are test only deps
Begin work on lexer

I feel like adding a token(tree)izer for mainly two reasons.

1. Separation of concerns. Parsing code will be simpler if we can
   separate out the lexing part.

2. In preparation for macros. Macros should act on token trees, so
   creating an in-between step is pretty much needed.

Currently, Lex.hs and Lexd.hs work and feel pretty much done, but
they're not connected to the rest of the compiler. What remains is to
rewrite Parse.hs to act on TokenTree:s instead of parsing text from
scratch.
Elim need for mods LLCompunit, LLSubprog with DuplicateRecordFields

They only existed to reexport a subset of LLOp in order to avoid name
collisions in record fields. The language extension
DuplicateRecordFields eliminates the need for this, by using magic to
disambiguate when there are duplicate fields in different records in
the same module.
Add skeleton module Optimize between Monomorphize & Compile
Make GC_malloc take NatSize instead of IntSize

I mean, how the heck do you allocate a negative amount of memory, right?
Test that good programs produce expected output

For the programs in test/tests/good/, compile and run the program,
capturing stdout. If the string of stdout matches the text in the
first comment of the file, the test passes.
Extract tests from CheckSpec to individual files in test/tests/bad

SystemSpec now runs those and verifies the type errors match what's expected
Define carth type literals only once in TypeAst

Like mainType, tUnit, etc. Use the class TypeAst to allow them to
construct any Type, e.g. Parsed.Type.
when debug, write file ".dbg.gen.ll"
Change domain from carth.jo.zone to carth.pink
Add `transmute` special form

Use to change the type of an expression without modifying the bits in
any way -- just interpret them as if they represented the new type.

Example:
    (: (transmute (: 4623716258932001341 Int)) F64)
results in
    (: 13.37 F64)
Better printing of verify exception
Instead of ccc everywhere, generate fastcc wrappers around externs

Pros:

- Extern declarations can now be written in a carth
  interpretation, with currying and all, because the generated wrapper
  will be curried. No need to manually write curried wrappers!

- Fastcc is faster and can optimize tail calls *way* better than
  ccc. We now have almost guaranteed tail call elimination in most
  possible cases.

Cons:

- Carth functions can now not be called from the outside, as they
  don't conform to the C abi. Maybe we'll add a feature to generate
  "reverse-wrappers" for marked carth functions.
Move non-AST related codegen operations to Gen.hs

Before, it was a bit unclear exactly where Gen.hs ended and Codegen.hs
began. Now it's a little more clear, though still slightly
ambiguous. Gen.hs contains codegen operations that may be useful when
manually generating stuff, so almost like an abstraction above
llvm-hs. Codegen describes how LLVM code is generated for a
Monomorphic AST using the generation operations in Gen.hs.
Don't warn on missing export lists
Update stackage release to lts-15.1

Had some trouble building the thing on new laptop, both on Guix and
with Stack on Arch. I couldn't find much info about it, but one person
suggested memory error. I hoped this wasn't the case, since the laptop
is brand new, but that it instead was some kind of GHC/Cabal
bug. Indeed, the GHC version in both cases was 8.6.something. Updating
to 8.8.something with LTS 15.1 seems to have helped! While the
miscompilation occured a bit randomly before, it was still likely to
happen, but now the compilation succeeded on the first try, so that
was probably it!
Next