Coalton development model and Lisp interface #180
Replies: 2 comments
-
Overall this sounds like a great plan. The original intent of Also I would prefer to use |
Beta Was this translation helpful? Give feedback.
-
Good point; I don't think it matters. I think what matters is about what types/constructors/accessors will be present at all. Like, do we still optimize into symbols? Maybe we decide "no" because it makes the interface very easy to describe. (We can generate symbols in
Agreed. |
Beta Was this translation helpful? Give feedback.
-
@eliaslfox's PR #179 spurred a lot of interesting and important discussion around the Coalton philosophy, how it ought to interop with Lisp, etc. I would like to propose two things:
Developing in Coalton
Coalton is just intrinsically different than Common Lisp in that Coalton tries to build a coherent and static understanding of the program at compile-time, so that run-time can be safe and efficient.
Common Lisp development simply doesn't work that way. As such, I think we ought to distinguish between "development" and "release" modes of operation.
Development mode should prioritize interactivity above all else. The program is incrementally developed, things are re-defined, etc.
Release mode should prioritize efficiency offered by the static guarantees. The program may not tolerate redefinition.
To implement this, I propose a global variable
coalton:*interaction-mode*
which has type(member :development :release)
and defaults to:development
.Ideally there is no semantic difference between
:development
and:release
modes, however, it may be the case that the abstraction leaks, and we should be vigilant to minimize this.:development
ModeIn
:development
mode, all objects are re-definable. This means thatdefine-type
will always expand into quantities that allow re-definition. This means nodefconstant
, nodefstruct
, and no automatic inlining. It also means that there is no automatic unboxing, except perhaps for standard library types. (Why? Well if we change a constructor of a type and it becomes a newtype, then it becomes unboxed, and we can't "eliminate" what already exists.)In
:development
mode, there should also be more diagnostics-as-warnings, and error as little as possible.Note that
:development
mode does not imply an optimization quality!:release
ModeIn
:release
mode, we pull the stops. The program is static. We can optimize layouts and whatever to our heart's content.Concretely, I would suggest using
defstruct
for all type defintiions, automatic newtyping,defconstant
, etc. Even more importantly, I would suggest we try wrapping the output ofcoalton-toplevel
with block compilation directives, so SBCL can optimize the calls as if they werelabels
.Note that one may still compile a system at the REPL in release mode, there will just be caveats on re-definition.
The Lisp interface
We've been informal about the Lisp interface. I think that if we have several modes of compilation, we need to label what we export as visible to the Lisp image. As such, I propose a new top-level operator called
pragma
which takes either keywords or keyword conses. For example:What should
(pragma :lisp)
do? I think we need to flesh it out, but I would suggest that it creates a CLOS-based representation, no matter what.What else should
pragma
do? I think that's up for discussion, but at least it gives us metadata hooks.I think if we go in a direction like this, we can satisfy the goals of keeping Coalton usable in an interactive fashion, having a well-defined way of interacting with Coalton code, and allowing code to be fast.
I look forward to your thoughts.
Beta Was this translation helpful? Give feedback.
All reactions