Michael Olson <[EMAIL PROTECTED]> writes: > I'm fairly certain that CL.el does not have any sort of union structure.
Ok. > And even if it did, we would not want to use it if it would > introduce a dependency on cl at run time (since RMS does not want > code to (require 'cl)). It would probably be best just to leave that > particular part of the structure unchanged. I think it's too late for that. At least for the xmtn back-end; it uses cl runtime extensively. grepping dvc/lisp shows that tla-core and tla-defs also have "require 'cl" not inside "eval-when-compile". Although I'm not sure specifying 'eval-when-compile' really means there is no run-time dependence; I think it more precisely means there _is_ a _compile-time_ dependence (via macros). RMS is stepping down as Emacs maintainer (sometime; I'm not reading the emacs-devel list anymore, so I don't know if it has actually happened yet). So maybe we could lobby for a change in this policy. Since cl is distributed as part of Emacs, the policy doesn't make much sense to me. It's like saying "we distribute diff-mode, but please don't use it"! If the argument is "cl is slow" then the response is "it's fast enough for 90% of users" combined with "getting it right is more important than making it really fast". Allowing cl runtime does make the code easier to understand and write, and therefore makes it easier to get right. Although it also makes it more tedious to debug. I don't know how it affects executing speed; at the moment there are more obvious things we could do to speed things up (that's another several threads :). If the policy does not change, we will need a distribution mechanism that allows xmtn as an add-on. I certainly don't want to rewrite it to get rid of the cl runtime. Hmm. I suspect I'm also introducing cl runtime dependence in the DVC front-end, by using ecase and defstruct in dvc-status. If this is is a problem, I could go back to using cond instead of ecase. I'm not clear if defstruct requires cl runtime; how do I tell? -- -- Stephe _______________________________________________ Dvc-dev mailing list [email protected] https://mail.gna.org/listinfo/dvc-dev
