| ▲ | spooky_deep 2 days ago |
| Since the macros run at compile time, I am ok with them not being statically checked. Statically checked macros seems like an academic curiosity. What am I missing? |
|
| ▲ | reikonomusha 2 days ago | parent | next [-] |
| Then nothing. Macros work. Silly example: COALTON-USER> (defmacro rpn (x y op)
`(,op ,x ,y))
RPN
COALTON-USER> (coalton-toplevel
(define (double x)
(rpn 2 x *)))
;; DOUBLE :: ∀ A. NUM A ⇒ (A → A)
COALTON-USER> (coalton (double 3.0))
6.0
|
|
| ▲ | wk_end 2 days ago | parent | prev | next [-] |
| One concern I’d have is that any type errors would be reported on the macro expanded code and thus be pretty much inscrutable outside of toy examples. |
| |
| ▲ | reikonomusha 2 days ago | parent [-] | | I think you're right that debugging errors involving complicated macros can get difficult, but to at least make the situation more tolerable, when Coalton expands a macro, it remembers where the expansion came from, so an error will be reported in the right place with the right source code. For example, using the RPN macro from the sister comment, here's an intentional type error: COALTON-USER> (coalton (rpn "x" "y" +))
--> <macroexpansion>:1:9
|
1 | (COALTON (RPN "x" "y" +))
| ^^^^^^^^^^^^^^^ expression has type ∀. (NUM STRING) => STRING with unresolved constraint (NUM STRING)
| ^^^^^^^^^^^^^^^ Add a type assertion with THE to resolve ambiguity
[Condition of type COALTON-IMPL/TYPECHECKER/BASE:TC-ERROR]
|
|
|
| ▲ | rscho 2 days ago | parent | prev | next [-] |
| Statically checked macros are useful to introduce new syntax at no runtime cost. |
|
| ▲ | taeric 2 days ago | parent | prev [-] |
| The big miss here is that "compile time" is typically understood to be "batch compilation" time for languages. For Common LISP, macros run at read time. Which is often doable during runtime. |
| |
