Misplaced details in 4.1 about next-700-module-systems

[alhassy]

Here's the proposed update:

Moreover, the prototype goes to great lengths to ‘fit’ into the usual workflow
of an Agda user.  In particular, after the initial setup, the prototype is
implicitly invoked whenver users perform Agda's usual typechecking in Emacs.
Since the prototype is mostly string manipulation, its presence is barely
noticable, and its results are then checked by Agda itself.  In addition, to
mitigate the burden of increasing the toolchain, the silent preprocessing would
not transform user code but instead /produce auxiliary files/ containing core
language code which are then /imported/ by user code ---furthermore, such import
clauses could be automatically inserted when necessary.  The benefit here is
that /library users/ need not know about the extended language features; since all
files are in the core language with extended language feature appearing in
special comments.

[JacquesCarette]

So even though I used the exact words in the first sentence in my own description of the issue, it doesn't mean that those are good for you to use in your thesis. They were meant for rapid communication between us, not as a means of exposition to the committee -- different audience requires different communication.

Let me attempt something.

The usual workflow of an Agda user involves writing some code (types and terms alike), then asking for Agda 
to typecheck it. The typechecking operation is done quite frequently. Thus, one way for our prototype to fit in 
well to this workflow is to extend the emacs hook that triggers Agda's typechecking to also invoke our prototype.

The prototype implementation works via string manipulations. Although we have no formal proof of this, the
manipulations all seem quite straightforward, and none seem to be overly time-consuming.  While we can't
be assured that these are linear in the size of the code, in practice, it seems like this is the case. To guard
against bugs potentially introduced through this untyped "wild manipulation" phase, Agda typechecks
everything that the prototype generates, thus ensuring eventual soundness.

Unlike Agda itself, which rewrites user code, such as when doing case-split, and will occasionally produce
incorrect code, we eschew that. Instead, our prototype produces auxilliary files that contain Agda code,
which are then imported into user code. Currently, these import clauses must be manually inserted, but
they could also be automatically inserted.

One benefit of this approach is that library users do not need to know about the extended language, as
what is imported is pure Agda, albeit with the extended language features appearing in special comments.

Yes, this is a lot longer. But I also say a lot more. I don't make statements like "barely noticeable", I say a lot more about that. I don't just say that it fits into the workflow, I explain what the workflow is, and where to insert a hook. I don't use words like 'silent preprocessing', instead I try to describe things more fully.

I don't claim that my rewrite is perfect. It might even be wrong in places. It is meant as an attempt to show what a 'deeper' explanation that details what is really going on, and instead of using various "you must believe me" adjectives, I give concrete explanations instead.

Note that I'm not sure what you mean by 'core language code' and 'user code' and 'core language'. If I don't, I think other readers would be even more confused. If you wish to use that terminology, that's fine, but there should be explicit definitions of these terms. And by explicit, I mean \begin{defn} level explicit.

[alhassy]

I liked that phrasing and adapted into 4.1; thanks! ---closing.