(Complex Single-Float) should have a repr CL::(COMPLEX SINGLE-FLOAT)

[stylewarning]

The current implementation is not wrong, but the repr is (COMMON-LISP:OR COMMON-LISP:NUMBER C:COMPLEX), which means any sort of (Lisp) compiler optimization is hosed. This is basically the same issue as specialized arrays, but doesn't deserve as much ceremony as specialized arrays, and there are only two specialized types worth caring about: singles and doubles. We should work to make Coalton emit these specialized types.

[digikar99]

How easy or difficult would it be to make specialize work for types? For example -

(in-package :coalton-user)

(coalton-toplevel
  (repr :native (or cl:number (cl:complex *)))
  (define-type (complx :a)))

(coalton-toplevel
  (repr :native (cl:complex single-float))
  (define-type complx/single-float)
  (specialize complx complx/single-float (complx single-float)))

Currently, the above results in an error that complx is an unknown function or variable. But if specialize also worked for types, then the case of complex as well as specialized-vectors/arrays seems solved (?).

[stylewarning]

@digikar99 I think we can have something similar-ish, where at the definition of complx we can specify different ways :a substitutions can lead to optimized representations. See the draft PR for example details where a proof of concept of the mechanics were implemented, but the syntax is still TBD.

[digikar99]

Yup, this looks good!

On a sidenote, I wonder if coalton should have tagged versions, and/or separate main and dev branches to avoid breaking things for coalton users.

[stylewarning]

Yup, this looks good!

On a sidenote, I wonder if coalton should have tagged versions, and/or separate main and dev branches to avoid breaking things for coalton users.

Eventually we'll tag versions when things sort of converge. We know we can't keep breaking things forever.