[asdf-devel] ASDF 2.0 requirements : simplify the output locations mechanism

[Faré]

>>>: fare
>>: james anderson
>
>>> And even then you'll have a hard time fixing things that users
>>> can now trivially do with the following translation:
>>>
>>> (:root ("C:/my/cl/cache" :implementation))
>>>
>>> This will work and make his file in
>>>   \\remote-host\myshare\cl\cl-foo\foo-V2.000\bar_baz.lisp
>>> be compiled as obvious from the spec into
>>>   C:\my\cl\cache\sbcl-1.0.38-windows-x86\remote-host\myshare\cl\cl-
>>> foo\foo-V2.000\bar_baz.fasl
>>
>> this would appear to be the equivalent of a translation on the order of
>>
>>  `("**;*.*.* ,(concatenate 'string "C:/my/cl/cache/"
>>                                    (asdf::implementation-identifier)
>>                                    "/**/*.*.*"))
>
Your solution is twice the size, requires the end-user to understand
at the same time logical pathnames, pathname translation patterns,
what are the limitations of LPNs, what is this ASDF internal function,
and last but not least where to configure those damn logical pathnames.
MOREOVER, it doesn't allow to map source that isn't from a logical pathname,
but from an absolute pathname using a non-trivial pathname host and device.
If I have one copy of my code in C:\src\foo and another in D:\src\foo,
I certainly don't want the two copies to share the same FASLs
(each in its own distinctly configured Lisp image).
With my solution, the user doesn't need do ANYTHING, it Just Works(tm).


>: Juanjo
>
> Let's try to clarify the discussion.
>
> * Fare insists on the validity of the current pathname translation
> mechanism, which allows the user to specify the destination of compiled
> files using physical pathnames and some configuration file or S-expr. If the
> user knows where the original file lived, he can find where the compiled
> file lives easily -- one to one mapping, no ambiguity, no names changes
> except mapping everything to a new tree.
>
Also: it's understandable by users who aren't done getting immersed into
the world logical-pathname and its wonderful limitations.


> * James is claiming that this can be implemented using _internally_ logical
> pathnames with a logical pathname tree structure that is constructed from
> the component names and not from the physical location of the files they
> represent. This would be complemented with a function to obtain the actual
> location of compiled files given the component object. The configuration can
> be mapped to this structure and the overall implementation would then be
> smaller.
>
James also says that his implementation is simpler; but it actually isn't.
It is doing one hundreds of what my implementation is doing: providing a UI
for the user in terms of configuration files including support for decent
behaviour and defaults under Windows.

Certainly, if we are to remove all of that, then my implementation is
*two* (2) functions and fifty-one (41) non-blank lines of code:
(defun apply-output-translations (path) ...)
(defmethod output-files :around (operation component) ...)
make it *four* (4) functions and sixty-five (62) non-blank lines
if we count in this bit of Windows support and its trivial helper:
(defun directorize-pathname-host-device (pathname) ...)
(defun last-char (s) ...)

This is as compared to *five* (5) additional functions and
eighty seven (87) non-blank lines of additional code
(take his patch, grep for ^\+ lines, remove comments, slot definition,
#+(or) code, trivial helpers, count 112 lines,
remove 25 lines of similar code removed).

Much of the complexity in my apply-output-translations itself was prompted
by Windows support where one must abstract over pathname host and device.
Also, the output-files method is made more complex to allow ASDF
extension writers to control the translation process. Things janderson
doesn't handle.

I claim my implementation is twice smaller and handles twice as many cases
with half the end-user-visible complexity.

"What? Foo_Bar/foo-bar.lisp and foo-bar/foo+bar.lisp are both mapped to
FOO-BAR/FOO-BAR.LISP and the system can't distinguish them?"


Also, for every line of configuration that a poor user must type in my
system (none for most users, one documented standardized line at most
for most other users, i.e. :disable-cache),
in a file he controls, once and for all,
with janderson's proposal, same user must somehow insert in the right place
of each and every system startup script he doesn't want to touch
massively complex logical pathname translation patterns;
and for each kind of translation he wants, he must adapt to the choice
of logical pathname for each and every system on his machine -
which is not trivial, and conflates two concerns that were orthogonal.
I say it is a huge complexity increase for janderson's "solution".

janderson's system forces everyone to adopt logical pathnames and their
limitations if any translation is intended. This is not backwards compatible
at all with existing practice, from any of A-B-L, clc, cl-launch or A-O-T.

And janderson's system doesn't play well at all with Windows.
Neither did A-B-L in centralize-binaries mode. A-O-T does it all.


> in principle, yes. in detail, there is no need to construct a global
> structure as the computation can proceed locally.
>
> I see shortcomings on both sides
>
> - Code size
I beg to differ. My code is much smaller and simpler than janderson's.

Much of the size addresses configuration concerns that janderson glosses
over and makes incredibly more complex for the user.
Much of the complexity in what is actually comparable
is directly attributable to support for non-Unix systems (e.g. Windows)
where physical pathname host and device matter.

> - A bunch of people already using asdf-binary-locations out there (which is
> what was merged in)
> which one should be able to continue to support in any case.
>
A-O-T provides limited but effective
A-B-L backward compatibility support.
janderson's "solution" provides none of it.

> - James' implementation only seems to allow one file per component and it
> does not seem to take into account when OUTPUT-FILES returns more than one
> file.
>
No, I think that characterization is unfair. On the other hand,
janderson's proposition makes it harder for writers of OUTPUT-FILES methods,
without offering the same control on the translation process.

Frankly, I'm tired of arguing with janderson.
Sorry James, it's not worth my time anymore.
I appreciate your talent and efforts, but your aesthetics is WAY warped
by your overly clever abstractness combined with weird love for LPNs;
I generally take your design preferences as a negative indicator.

[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
Young man, in mathematics you don't understand things,
you just get used to them. — John von Neumann (1903-1957)