[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


1. Numbers: I agree with full naming.  Even when I was actively working
   on a full numbers package I couldn't remember what these were
   wiuthout looking them up.  Perhaps implementations should be free
   to support single-letter names in "not recommended" status for
   the sake of downward compatibility.

2. LOAD: This is sticky.  The beast probably should not exist in this
   or any other language, because files themselves are a bad idea
   left over from the early days of computer science when we didn't
   know any better and allowed hardware to dominate software design.
   The problem is that not having LOAD available requires that we
   have an alternative available, which means either (a) having a
   transparent or essentially transparent object filing system or (b)
   having a non-transparent object filing system with an explicit
   object-writing operator (e.g. WRITE or some variant would have to
   be able to render permanent any arbitrary object, such as functions
   that make lexical reference to variables from an enclosing scope
   and similar LISP objects that can have very messy state in a
   lexically scoped environment).
   If we have LOAD available but we don't document it, we have simply
   ignored the problem, rather than either solving it or admitting we
   can't yet.  The fact is that, unlike EVAL, LOAD is something that
   everyone will have to use, including newcomers; it's not esoterica,
   even if it does interfere with intellectual cleanliness.  The means
   to address such cleanliness issues is probably design, not selective

   A good compromise might be to add a paragraph of comment,
   something like what appears in the RRRS for macros, stating that
   this is currently a difficult area in LISP design and that LOAD
   is provided but that work on alternatives (e.g. object filing systems)
   is encouraged.