My experience so far

[chebert]

Overall I think it's been a good experience. I'm working through an idea I had for an OOP system within the FP paradigm. It's not quite there yet, but I'll definitely share it when I have something ready.

I will bring up a few issues I had and some things that I liked.

---

It'd be great if there were type aliases: like Haskell's type keyword. These wouldn't define a new type or data constructors, but just be different names for existing types. This is probably the number one thing I want most.

---

I would hope for a relevant error when I accidentally name a variable the same as a type constructor, but I got something like:

error in FORMAT: Unknown format directive (character: Return)
Pattern variable ~/coalton-impl::sexp-fmt/ matches name of known ~
constructor. If you meant to match against the constructor then ~
use ~/coalton-impl::sexp-fmt/ instead.
[Condition of type SB-FORMAT:FORMAT-ERROR]

Once I figured out what ^^ actually means it was no problem, but I think more relevant error messages is a VERY close 2nd for thing I want most.

---

I actually frequently want to name the value the same as its constructor -- but all lowercase. I think I was under the impression that Coalton was case-sensitive (based on the naming conventions in the examples). but I don't think it is. I'll probably adopt some kind of type-name convention so I don't pollute my variable & function namespace.

---

I encountered some package locks when I was first setting up my package that uses Coalton, and it wasn't able to define-instance eq.

Just to verify my package looks like:

(defpackage #:my-package
  (:use #:coalton #:coalton-library))

Are there more packages I can easily just USE?

---

In order to get better error messages I break up all of my top level forms into (coalton-toplevel ...), this is because SBCL is able to give SLIME the source info. Is there a way to have a "coalton" file where they are all automagically put into coalton-toplevel forms?

---

I like the error messages I get when there is a type mismatch. They are very helpful.

---

I feel good about the syntax for the most part.

---

It's kinda interesting to look at the macro-expansions for the code. I think it generates pretty reasonable code.

[chebert]

One more thing I realize stood out to me: Tuple types only work for pairs. I was able to do (Tuple a (Tuple b c)) before reverting to a named type constructor. Just curious if this is by design. I think the word 'tuple' indicates that it could be n-elements, where Pair might indicate 2 elements.

[chebert]

Couple of updates on this:

Using _ to prepend constructor names works pretty well for me actually. It's easy to remember and I never have a conflict.
I looked at how #:coalton-user loads packages, and got that sorted out, so no more package conflicts. Just needed to reboot my lisp.

I have run into a couple of more blocking issues.

---

1. I want to be able to have mutually referential functions/variables within a scope. In CL I would use labels. In Scheme I would use defines. What is the way to do that in Coalton?

---

2. I was able to define a state monad with two type variables. This turned out nice. I'll share in a new discussion.

[stylewarning]

For #1, use LET. LET in Coalton is like LETREC elsewhere.

(let ((f (fn (_) (g)))
      (g (fn (_) (f))))
 ...)

[chebert]

wrt to tuples, I just discovered the Tuple2/3/4/etc. constructors, and I think that's sensible: I just missed it before. I looked into it and Haskell gets away with it by having (,) be a separate type constructor from (,,) (,,,) etc.

[colescott]

error in FORMAT: Unknown format directive (character: Return)
Pattern variable ~/coalton-impl::sexp-fmt/ matches name of known ~
constructor. If you meant to match against the constructor then ~
use ~/coalton-impl::sexp-fmt/ instead.
[Condition of type SB-FORMAT:FORMAT-ERROR]

This looks like a bug caused by the coalton error message failing to format but I can't reproduce locally. I think it might be caused by some difference in the way format strings are handled on different lisps. What lisp implementation version are you running this on?

You can get this by running

(format t "~A ~A ~A ~A"
  (lisp-implementation-type)
  (lisp-implementation-version)
  (software-type)
  (software-version))

which should print something like
SBCL 2.1.9.nixos Linux 5.10.77

[chebert]

Here is a minimal example demonstrating the error message.

(ql:quickload :coalton)
#||
Output:
To load "coalton":
Load 1 ASDF system:
coalton
; Loading "coalton"


||#
;; => (:COALTON)

(lisp-implementation-type)
"SBCL"
(lisp-implementation-version)
"2.1.11"
(software-type)
"Win32"
(software-version)
"10.0.19042"

(cl:defpackage #:format-bug
  (:use #:coalton #:coalton-library))

(cl:in-package #:format-bug)

(coalton-toplevel
  (define-type uid (uid integer))
  (define-type uid-container (uid-container uid)))

(coalton-toplevel
  (define (matches-uid-container uid-container)
    (match uid-container
      ((uid-container uid)
       uid))))

"error in COMMON-LISP:FORMAT: Unknown format directive (character: Return)
  Pattern variable ~/coalton-impl::sexp-fmt/ matches name of known ~

        constructor. If you meant to match against the constructor then ~

        use ~/coalton-impl::sexp-fmt/ instead.
                                                                    ^
   [Condition of type SB-FORMAT:FORMAT-ERROR]
"

That format error is copied and pasted but in my emacs the ~ appear as ~^M indicating the windows return. These Windows line-ending characters are added by SLIME when I compile, and aren't actually part of my file. I think this might be easier to reproduce on a Windows machine.

[colescott]

This looks like a bug in SBCL (https://bugs.launchpad.net/sbcl/+bug/1342005 and https://bugs.launchpad.net/sbcl/+bug/310185) but it seems like it isn't going to be fixed anytime soon. It might be best to just fuse all format control strings in the Coalton codebase to avoid this problem

(cc @stylewarning @eliaslfox)