Commit b0a38790 authored by Francois-Rene Rideau's avatar Francois-Rene Rideau
Browse files

Integrate feedback from Theam Yong Chew.

parent a9e4696f
......@@ -23,7 +23,7 @@ clean: semiclean
semiclean:
-rm -f ${OBJ}
website:
rsync main.pdf common-lisp.net:/project/asdf/public_html/ilc2010.pdf
website: main.pdf
rsync main.pdf common-lisp.net:/project/asdf/public_html/ilc2010draft.pdf
.PHONY: clean semiclean view website
......@@ -407,14 +407,16 @@ in addition to simple function definitions.
to use FASL files instead of recompiling the source code every time,
as some scripting languages do.
Modern Lisp implementations typically include some kind of compiler that
produces reasonably fast code, but take some time to optimize their output.
Some implementations (such as ECL) also include an interpreter simply evaluates
the input code more or less directly. This is practical for code that only gets
run once, while building or interactively. Other implementations (such as SBCL)
eschew an interpreter altogether. For such implementations, evaluation of an
interactive form is done by compiling it then immediately executing the compiled
code.
Modern Lisp implementations typically include
some kind of compiler that produces reasonably fast code,
but take some time to optimize their output.
Some implementations (such as ECL) also include
an interpreter that simply evaluates the input code more or less directly.
This is practical for code that only gets run once,
while building or interactively.
Other implementations (such as SBCL) eschew an interpreter altogether.
For such implementations, evaluation of an interactive form is done
by compiling it then immediately executing the compiled code.
Every implementation has a different format for fasl files,
reflecting different implementation strategies, etc.
......@@ -473,13 +475,12 @@ For {\compileOp} operations on {\clSourceFile} components,
the file pointed to by the \lisp{component-pathname} and write it to the
location pointed to by the \lisp{output-files} generic function.
By defining an \texttt{around} method for \lisp{output-files},
it is possible to redirect where {\ASDF} stores its outputs;
that methods may then use pathname transations.
for each operation to be \lisp{perform}ed what \lisp{output-files} there were,
applying some pathname translations to each of the considered pathnames and
substituting the translated pathnames for the original pathnames
when actually \lisp{perform}ing the operation.
it is possible to redirect where {\ASDF} stores its outputs:
such a method may apply some pathname translations
to each of the considered pathnames and
substitute the translated pathnames for the original pathnames.
All {\ASDF}-defined {\perform} methods cooperate with this protocol,
and user-defined methods are expected to do so as well.
{\longABL} (henceforth {\ABL}) was
a popular piece of software to redirect compiler output for {\ASDF},
......@@ -678,7 +679,7 @@ and either inherit system-provided configuration or override it,
depending on their needs.
In the end, the aim of our interface modifications was this
change in the how programmers interact with the machine and with each other,
change in how programmers interact with the machine and with each other,
smoothing the need for synchronization between experts
and lowering the barriers to entry for newbies.
......@@ -1037,7 +1038,7 @@ composite {\step}s and their constituent sub-{\step}s.
A consequence of this design is that the {\step}
corresponding to operating on the composite component
does not wrap {\em around} the {\step}s involving its constituents,
but is only a synchronization mark scheduled {\em after} all of them;
but is only a synchronization mark scheduled {\em after} all of them.
The {\perform} method over such an {\step} does nothing.
So, in {\ASDFi}, if one was to (compile and) load system
......
......@@ -374,7 +374,7 @@ However, it is possible to support dynamic code upgrade much better.
For instance, Erlang solves the issue of dynamic code upgrade
by providing syntactic distinction
between the two semantically different kinds of calls:
calls specifying an syntactically unqualified identifier
calls specifying a syntactically unqualified identifier
are always semantically static calls (to a function in the same module),
and calls to a syntactically module-qualified identifier (even in the same module)
are always semantically dynamic calls.
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment