Support :import
Description
Environment
Attachments
Activity
The original :import
-handling logic + the type/record support of the working patch rolled into one commit.
Ok, so the last patch is broken in that it causes duplicate type names to become errors at the REPL. The original goog.provide
patch doesn't suffer from this problem.
Given the above I think the original goog.provide
patch may actually be the correct one to use.
I suppose it could be simplified to emit goog.provide
when in compile-file*
without regard to which types have been emitted, but that wouldn't be that much of a simplification and can wait for proper warning/error functionality (which I'm planning to figure out in any case).
Ok. So we can just emit goog.provide
always (as we do for ns
forms) and disallow multiple deftype
/ defrecord
calls within a single body of code delivered to GClosure. The attached patch does this (and adjusts the tests appropriately).
As for providing our own errors, the straightforward approach fails because for some reason deftype*
forms get processed by parse 'deftype*
. No idea why that is (and whether it happens for all such forms or only under special circumstances), will need to investigate. The GClosure error, on second glance, does include the full type name, so the user should be able to deduce what's wrong, so this patch needn't necessarily wait for a proper error check of our own.
Note that this is really about an error rather than a warning – if we only want to warn about duplicate types (and then handle them gracefully), then the original goog.provide
patch is more appropriate (and we need to figure out how to warn the user / deal with the double parse
).
(It would be easy enough to produce the error/warning at emit time rather than in the analyser, avoiding the double parse
problem entirely... This just doesn't feel right though.)
I also agree about producing our own warnings about only one type/record.
Details
Details
Assignee
Reporter
Priority

Useful for bringing in ctors.
See the ggroup discussion:
https://groups.google.com/d/topic/clojure/etFN-sdBS6c/discussion