[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: LOAD
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
non-documentation.
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.
asc