Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add (LispArray :t), add specialized representations of LispArray and Complex #1015

Merged
merged 2 commits into from
Feb 9, 2024

Conversation

stylewarning
Copy link
Member

@stylewarning stylewarning commented Oct 11, 2023

This PR does three things:

  • Adds a LispArray type to match the semantics of (simple-array <t> (*)). I think this is a good compromise between my concerns and @eliaslfox's suggestions. The name LispArray was chosen intentionally to emphasize this behavior, and not place itself as a "competitor" to Vector or Seq.
  • Adds specialization of (Complex :t) type.
  • Adds specialization of (LispArray :t) type.

Addresses #1008 in principle.

COALTON-USER> (coalton-codegen
                (declare f ((coalton-library/math/complex:Complex Single-Float) -> Single-Float))
                (define (f z)
                  (coalton-library/math/complex:square-magnitude z))
                
                (define (g z)
                  (coalton-library/math/complex:square-magnitude z)))
firing type specialization: (COALTON-LIBRARY/MATH/COMPLEX:COMPLEX #T20689) => (COMMON-LISP:OR COMMON-LISP:NUMBER COALTON-LIBRARY/MATH/COMPLEX:COMPLEX)
firing type specialization: (COALTON-LIBRARY/MATH/COMPLEX:COMPLEX COALTON:SINGLE-FLOAT) => (COMMON-LISP:COMPLEX COMMON-LISP:SINGLE-FLOAT)
(COMMON-LISP:PROGN
 (COMMON-LISP:DECLAIM
  (SB-EXT:MUFFLE-CONDITIONS SB-KERNEL:REDEFINITION-WARNING))
 (COALTON-IMPL/GLOBAL-LEXICAL:DEFINE-GLOBAL-LEXICAL G
                                                    COALTON-IMPL/RUNTIME/FUNCTION-ENTRY:FUNCTION-ENTRY)
 (COMMON-LISP:DEFUN G (#:DICT1872 Z-3371)
   (COMMON-LISP:DECLARE (COMMON-LISP:IGNORABLE #:DICT1872 Z-3371)
                        (COMMON-LISP:TYPE
                         COALTON-LIBRARY/MATH/COMPLEX::CLASS/COMPLEX
                         #:DICT1872)
                        (COMMON-LISP:TYPE
                         (COMMON-LISP:OR COMMON-LISP:NUMBER COMPLEX) Z-3371)
                        (COMMON-LISP:VALUES COMMON-LISP:T
                                            COMMON-LISP:&OPTIONAL))
   (COALTON-LIBRARY/MATH/COMPLEX:SQUARE-MAGNITUDE #:DICT1872 Z-3371))
 (COMMON-LISP:SETF G (COALTON-IMPL/RUNTIME/FUNCTION-ENTRY::F2 #'G))
 (COALTON-IMPL/GLOBAL-LEXICAL:DEFINE-GLOBAL-LEXICAL F
                                                    COALTON-IMPL/RUNTIME/FUNCTION-ENTRY:FUNCTION-ENTRY)
 (COMMON-LISP:DEFUN F (Z-3370)
   (COMMON-LISP:DECLARE (COMMON-LISP:IGNORABLE Z-3370)
                        (COMMON-LISP:TYPE
                         (COMMON-LISP:COMPLEX COMMON-LISP:SINGLE-FLOAT) Z-3370)
                        (COMMON-LISP:VALUES COMMON-LISP:SINGLE-FLOAT
                                            COMMON-LISP:&OPTIONAL))
   (COALTON-LIBRARY/MATH/COMPLEX:SQUARE-MAGNITUDE
    COALTON-LIBRARY/MATH/COMPLEX::|INSTANCE/COMPLEX SINGLE-FLOAT| Z-3370))
 (COMMON-LISP:SETF F (COALTON-IMPL/RUNTIME/FUNCTION-ENTRY::F1 #'F))
 (COMMON-LISP:DECLAIM
  (SB-EXT:UNMUFFLE-CONDITIONS SB-KERNEL:REDEFINITION-WARNING))
 (COMMON-LISP:VALUES))

@stylewarning
Copy link
Member Author

I thought maybe something like

(repr :specialize (Complex Single-Float) :as (cl:complex cl:single-float)
      :specialize (Complex Double-Float) :as (cl:complex cl:double-float)
      :specialize (Complex :a) :as (cl:or cl:number Complex))

as syntax for specific parameter specializations. Maybe could be more flexible by binding lambda functions or something, but I'm not sure it needs to be that ostentatious.

@eliaslfox
Copy link
Collaborator

I would prefer to hard code these in lisp-type instead of adding an extension point. Common Lisp has a fairly small number of cases where this is necessary .

@digikar99
Copy link
Contributor

Common Lisp has a fairly small number of cases where this is necessary .

Within the Common Lisp builtins, the number of cases is small. But the extensibility looks important in the wider lisp ecosystem, although you can achieve the same things with a typeclass (?).

For example, one use case I imagine is defining a parametric coalton type with runtime representations given by magicl's tensor types. This way, a parametric coalton type (tensor :t) can have runtime representation given by magicl:tensor/single-float, magicl:tensor/double-float, etc. Now, instead of using the parametric type, one can also use a coalton typeclass. So, the extensibility isn't a must-have.

@eliaslfox
Copy link
Collaborator

In that case you should use a type class. The type isn't really parametric because it can't be instantiated with arbitrary types.

@stylewarning
Copy link
Member Author

I would prefer to hard code these in lisp-type instead of adding an extension point. Common Lisp has a fairly small number of cases where this is necessary .

I had a circularity issue: LISP-TYPE doesn't know about COMPLEX yet. Do you have any suggestions?

(I also started to sketch a language feature, but I thought it was too cumbersome for just a couple specialized parametric types, like complexes and simple-arrays.)

@eliaslfox
Copy link
Collaborator

Use find-symbol. We do it in a couple places already.

@stylewarning stylewarning force-pushed the specialized-complex branch 2 times, most recently from 144528c to 5ac9122 Compare October 12, 2023 04:22
@stylewarning stylewarning changed the title allow specializing representations and specialize (Complex :t) add (LispArray :t), add specialized representations of LispArray and Complex Oct 12, 2023
@stylewarning
Copy link
Member Author

The LispArray work will only be meaningfully completed when there's RandomAccess available.

@stylewarning stylewarning marked this pull request as ready for review October 12, 2023 05:33
library/lisparray.lisp Outdated Show resolved Hide resolved
@stylewarning stylewarning force-pushed the specialized-complex branch 4 times, most recently from f66e728 to 09fd6e4 Compare January 21, 2024 05:37
library/lisparray.lisp Outdated Show resolved Hide resolved
Copy link
Member

@colescott colescott left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Super cool! Just a few small nits

src/typechecker/lisp-type.lisp Outdated Show resolved Hide resolved
library/lisparray.lisp Outdated Show resolved Hide resolved
src/typechecker/lisp-type.lisp Outdated Show resolved Hide resolved

These arrays are represented as possibly specialized `(cl:simple-array <type> (cl:*))` and are meant to be used as a tool either to interface with Lisp code or to implement efficient data structures. One should consult `Vector` or `Seq` for more general sequential data structure needs.

Whether or not the arrays are specialized depends on the underlying Lisp implementation. Consult `cl:upgraded-array-element-type` to determine whether `LispArray` may get specialized.")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it be possible/useful to add a specialized? function which checks this within Coalton?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What would this check, the array object itself? A type?

@stylewarning
Copy link
Member Author

@colescott I addressed everything except specialized?, which I just need a spec for. :)

@@ -25,11 +25,18 @@
(cl:declaim #.coalton-impl/settings:*coalton-optimize-library*)

(coalton-toplevel
(repr :native (cl:or cl:number complex))
;; The representation of (Complex :t) is specially dealt with by the
;; compiler in lisp-type.lisp.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably change lisp-type.lisp to src/typechecker/lisp-type.lisp.

@digikar99
Copy link
Contributor

  1. If it's aref for array-ref, then (setf aref) or aset feels more consistent than set!. Not a hard requirement, so depends on what others find appropriate.

  2. Are the symbols from coalton-library/types package supposed to be accessible from coalton-user? If not, and perhaps even then, is it possible to make-unitialized depend on its return type? So that the following is legal code

(coalton-toplevel
  (define (make-u8-array size)
    (the (LispArray U8) (make-uninitialized size))))

instead of requiring the user to write the slightly esoteric

(coalton-toplevel
  (define (make-u8-array size)
    (make-uninitialized size (the (proxy u8) proxy))))
  1. This is probably not an issue with this PR, but Common Lisp has this quirk that the imaginary part can be float 0.0 but never the rational 0. I'm missing how Coalton is handling this.

library/lisparray.lisp Outdated Show resolved Hide resolved
library/lisparray.lisp Outdated Show resolved Hide resolved
library/lisparray.lisp Outdated Show resolved Hide resolved
((member lisp-to
*specialized-complex-part-types-considered*
:test #'lisp-type=)
`(cl:complex ,lisp-to))
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the cl: is unnecessary

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i put it there since there's a coalton/whatever:complex, and this file deals with both lisp types and coalton tycons

src/typechecker/lisp-type.lisp Show resolved Hide resolved
@stylewarning stylewarning force-pushed the specialized-complex branch 2 times, most recently from b0720cc to 667d133 Compare January 31, 2024 20:51
This commit does two main things:

1. Adds (LispArray :t). There are presently no constructors for it,
but there is logic to emit appropriately specialized (SIMPLE-ARRAY <t>
(*)) declarations in many common monomorphic cases.

2. Handles the repr of (Complex :t) specially from LISP-TYPE so that
more specific type declarations are emitted for floating point types.
@stylewarning stylewarning merged commit 22c6e2c into main Feb 9, 2024
17 checks passed
@stylewarning stylewarning deleted the specialized-complex branch February 9, 2024 00:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants