the stuff in "library" is in coalton user. either put them in COALTON or make a new package COALTONLIB

Do you plan to implement them, or have you given up on the idea? I am very interested in the tpic and decided to dive into Coalton hoping maybe I could help with this at some point. (comparing to implementing some ad-hoc typeclasses atop of some half-baked self made static type checking it makes more sense anyway)

Write a function to check if two ty's represent exactly the same type. Be sure that (-> (a) a) matches (-> (b) b) but not (-> (a) b).

This can be used to avoid clobbering declared types.

Defining a macro with DEFMACRO is a simple solution, but it also conflates Coalton code with Lisp code a bit too much. We should probably have a define-macro form specifically for Coalton.

I'm following along with the README and noticed a weird interaction between coalton and ASDF, whereby coalton gets confused if I try to reload it after restarting my inferior lisp (sbcl). For example:

First run, A-OK

On the first compile/load, everything is fine:

CL-USER> (ql:quickload :coalton)
To load "coalton":
  Load 1 ASDF system:
    coalton
; Loading "coalton"
..................................................
[package coalton].................................
[package coalton-user]............................
[package coalton-impl]............................
[package coalton-global-symbols]..................
......
(:COALTON)
CL-USER> (in-package :coalton-user)
#<COMMON-LISP:PACKAGE "COALTON-USER">
COALTON-USER> (coalton-toplevel
                (define (gg x) (if x (left 1) (right x))))
COMMON-LISP:NIL

Second run

But if I then slime-restart-inferior-lisp and reload, coalton gets confused.

CL-USER> (ql:quickload :coalton)
To load "coalton":
  Load 1 ASDF system:
    coalton
; Loading "coalton"
.
(:COALTON)
CL-USER> (in-package :coalton-user)
#<COMMON-LISP:PACKAGE "COALTON-USER">
COALTON-USER> (coalton-toplevel
                (define (gg x) (if x (left 1) (right x))))
; Evaluation aborted on #<COALTON-IMPL:COALTON-PARSE-ERROR {10040AF5A3}>.

The exact error is

Failed to parse (TRUE) because: The constructor TRUE is unknown.
   [Condition of type COALTON-IMPL:COALTON-PARSE-ERROR]

Restarts:
 0: [RETRY] Retry SLIME REPL evaluation request.
 1: [*ABORT] Return to SLIME's top level.
 2: [ABORT] abort thread (#<THREAD "repl-thread" RUNNING {10023F9B63}>)

Backtrace:
  0: (COALTON-IMPL::ERROR-PARSING (TRUE) "The constructor ~S is unknown." TRUE)
  1: ((COMMON-LISP:LABELS COALTON-IMPL::PARSE :IN COALTON-IMPL::PARSE-FORM) (MATCH X (TRUE (LEFT 1)) (FALSE (RIGHT X))))
  2: ((COMMON-LISP:LABELS COALTON-IMPL::PARSE :IN COALTON-IMPL::PARSE-FORM) (FN (X) (IF X (LEFT 1) (RIGHT X))))
  3: (COALTON-IMPL::PARSE-DEFINE-FORM-FUNCTION GG (X) (IF X (LEFT 1) (RIGHT X)))
  4: (COALTON-IMPL::PROCESS-TOPLEVEL-VALUE-DEFINITIONS ((DEFINE (GG X) (IF X # #))))
  5: ((COMMON-LISP:MACRO-FUNCTION COALTON-TOPLEVEL) (COALTON-TOPLEVEL (DEFINE (GG X) (IF X # #))) #<unused argument>)
  6: ((COMMON-LISP:FLET SB-IMPL::PERFORM-EXPANSION :IN COMMON-LISP:MACROEXPAND-1) #<FUNCTION (COMMON-LISP:MACRO-FUNCTION COALTON-TOPLEVEL) {52E143BB}> COMMON-LISP:NIL)
  7: (COMMON-LISP:MACROEXPAND (COALTON-TOPLEVEL (DEFINE (GG X) (IF X # #))) #<NULL-LEXENV>)
  8: (SB-INT:SIMPLE-EVAL-IN-LEXENV (COALTON-TOPLEVEL (DEFINE (GG X) (IF X # #))) #<NULL-LEXENV>)
  9: (COMMON-LISP:EVAL (COALTON-TOPLEVEL (DEFINE (GG X) (IF X # #))))

Workarounds

Any of the following workarounds can be used immediately after restarting sbcl.

1. Manually LOAD the file library.lisp after loading the system: (ql:quickload :coalton) (load (asdf:system-relative-pathname :coalton "src/library.lisp"))
2. Use (asdf:load-system :coalton :force t) instead of (ql:quickload :coalton)
3. Remove cached FASL files and recompile
   1. In shell: $ rm ~/.cache/common-lisp/sbcl-1.4.16-linux-x64/home/ma/src/repos/coalton/src/*.fasl
   2. In REPL: (ql:quickload :coalton)

Pattern matching is a core and essential part of ML. Implement it. Syntax will be

<match> ::=
  (coalton:match <var>
    <clause>*)

<clause> ::= (<pattern> <result>)

<pattern>
  ::= <blank pattern>
    | <variable>
    | (@ <variable> <pattern>)
    |  <NullaryConstructor>
    | (<NaryConstructor> <pattern>*)

<variable> ::= a symbol excluding '_'
<blank pattern> ::= the symbol '_'

Types should be inferred, exhaustiveness checking should happen, etc.

This is a usability issue, not a technical one. The proper way to write the type as of writing is (-> ((Liszt t)) t), but it will certainly trip people up.

COALTON-TOPLEVEL processes forms manually. We should allow macroexpansion here so users can write their own define-* macros and the like.

Allow syntactic sugar for curried function types:

(fn <ty>* -> <ty>* -> ... -> <ty>* -> <ty>)

This would match Haskell et al. and be right-associative.

This would require being able to (a) parse these types, and (b) print these types.

The tyfun object shouldn't need to be modified.

Coalton should support standard tuples

This can be achieved like with TYAPP and TYFUN using a new TYTUP type. The hope would be to allow for tuples in the language without having to explicitly specify every sized tuple constructor.

Tuple decomposition in matches are also be a nice addition

right now we use DEFINE-GLOBAL-VAR*. Fixing this will require some understanding of compile-time vs load-time etc.

This provides a bad error message:

(define-type (Ref t)
  (Ref t))

bumbling about superclasses and whatever

Error messages coming from the macro expansions are very difficult to debug and trace through. Improve this experience.

How should objects be printed from Lisp? Should they be readable?

Right now, lists look especially awful:

> (range 0 10)
#.(COALTON-USER::KONS 0 #.(COALTON-USER::KONS 1 #.(COALTON-USER::KONS 2 #.(COALTON-USER::KONS 3 #.(COALTON-USER::KONS 4 #.(COALTON-USER::KONS 5 #.(COALTON-USER::KONS 6 #.(COALTON-USER::KONS 7 #.(COALTON-USER::KONS 8 #.(COALTON-USER::KONS 9 #.COALTON-USER::KNIL))))))))))

Can We Do Better?

The declared type of a global value isn't checked against its inferred type. Sometimes the declared type will be more specific, and we should have something like that.

(defun more-specific-type-p (general specific)
  "Is the type SPECIFIC a more specific instantiation of GENERAL?"
  ...)

COALTON-USER isn't a very nice package to use. Make it easy to write Coalton inside of Lisp without 100s of package qualifiers.

This will require answering the question "Can one use COMMON-LISP symbols for Coalton-defined functions?" The current answer is "no" since we define symbol macros/global static vars with those names.