alhassy / next-700-module-systems

PhD research ;; What's the difference between a typeclass/trait and a record/class/struct? Nothing really, or so I argue.

The Next 700 Module Systems

Extending Dependently-Typed Languages to Implement Module System Features In The Core Language

This repository contains the research proposal for my doctoral studies at McMaster University under the supervision of Jacques Carette and Wolfram Kahl.

What are and what should be the module systems of DTLs? DTLs remove distinctions between packaging systems and so using pedestrian modules systems is not necessarily the best route.

• A requirements driven approach to coherent modularisarion constructs in Dependently-typed languages.

• Main Question: What are the module systems for Dependently-Typed Languages?

• Goal: Extend Agda to be powerful enough to implement the module system features, in the core language, that people want to do.

  In user facing libraries, redundancies are desirable since they may utilise a a variety of aliases for what user want, this is useful flexibility.

  • However, in the source file, each item should only exist once.
  • The front-end redundancy should be produced by machine generation,

rather than by hand.

◈ Website ◈

A super simple description of this work, for the layman, can be found here.

Prototype and a Preprint

◈ Prototype ◈ MathScheme: 200+ Math Theories in (Clickable) Agda ◈ A Language Feature to Unbundle Data at Will ◈ Slides ◈ Youtube

The Context Library ---An Agda Counterpart of the PackageFormer Prototype

◈ [PhD Thesis](./thesis.pdf) ; [Youtube](https://youtu.be/hTQG2QbBPhA) ◈ [Slides](./phd-defence.pdf) ◈ AIM 2020: [Youtube](https://youtu.be/lSIFM5lhnWc); [Slides](./diy/agda-implementors-meeting-2020.html)

Proposal

◈ PDF ◈ HTML ◈ Slides ◈ translate code ◈ monoid code ◆ Demo

Related

◈ Metaprogramming Agda --- IFIP Program Generation Talk

next-700-module-systems's Issues

meta data

Verify that title, authors and affiliation are generated via \maketitle and not org-mode.

4.1 Why textual transformations? IV

This is based on commit 2a1878f

The last paragraph on p.8 contains very interesting information, but could be clearer. Let me write a paragraph that I think says the same thing.

Lisp uses a rather small number of constructs, such as macros and lambda, which themselves are used to build 'primitives', such as \texttt{defun} for defining top-level functions~\cite{XXX}. Knowing this about Lisp encourages us to emulate this expressive parsimony.

I did not use words like 'expected', 'minimal', 'orthogonal', 'day-to-day', on purpose. Because to use them, I would then have to justify them, and that is a unnecessary distraction.

Last page should be \balanced

Both p.4 and p.5 should be balanced.

Provide affiliation country

This is probably related to using the wrong way to get the title page -- the full address of all the authors is not shown.

ICFP 2020 :: 3-for-1 Monadic Notation: Do-it-yourself module types

Any feedback regarding the tremendously rough draft would be super helpful!

Besides the draft, there is also its associated code, as well as the associated library code which may be read literately here.

The ICFP deadline is March 3 ---next week--- with a 25 page limit using acm-small; the draft is at 13 single-column pages.

Verify that Type 1 fonts are used

There is no explicit (that I could see) fontenc specification.

Ch. 4 introduction

This is based on commit 2a1878f

• "we concluded that metaprogramming is an inescapable road on the journey toward first-class modules in DTLs".
  'inescapable' is just plain wrong. metaprogramming is a reasonable road to take to explore the ideas involved.
• "As such, we begin by forming an ‘editor extension’ to Agda with an eye toward the minimal number of
  ‘meta-primitives’ for forming combinators on modules."
  This sounds fantastic! Too bad the chapter does not deliver on the "eye towards the minimal number of 'meta-primitives'.
  Of course, 'minimal' is dangerous, as that would require some kind of proof. But let's assume 'small' instead. So what do I expect to read?
  • an overview of the tasks that are in scope for these combinators (example-driven would be great)
  • an analysis of what the tasks actually involve (again example-driven)
  • a synthesis of the features needed to perform these tasks
  • a presentation of that small set of meta-features
    So chapter 4 has to go hand-in-hand with chapter 3, which is supposed to do some of the above (but does not, at least not yet)
• "The purpose of writing the editor extension is to show that the ‘flattening’ of value terms and module terms is not only feasible, but practical"
  This was essentially already known, via the MathScheme prototype. But the prototype at hand actually does quite a bit more. Unfortunately, because the 'story' is not systematic (see the previous point), that the prototype actually delivers quite a bit more is buried.

Issue with exposition / example in 2.6

I can't see any difference in the output of 𝒱-primed-attempt between 2.5 and 2.6. Most definitely no elision of repeated parts seem to be happening. Or maybe I'm expecting the wrong thing and the exposition is misleading me.

Use proper capitalization of all headings

See https://grammar.yourdictionary.com/capitalization/rules-for-capitalization-in-titles.html for the rules of English. The capitalization is inconsistent, to say the least.

Introduction to ch. 5

(read from thesis.pdf). The style here harkens back to somewhat earlier writing, and needs to be revised (which I understand will be done for the margin-ful version). But things to remember when editing:

1. Context is probably not a 'module system'. [It is still extremely useful!]
2. in point 1 you claim to show that "Languages with sufficiently powerful type systems and meta-programming can conflate record and term datatype declarations into one practical interface"; this is an over-statement on at least two fronts: 1) this is mostly shown via example, and 2) only for Agda. I do believe that you can show this - but if you want to claim it, you need to actually show it.
3. 'on-demand' is not good CS terminology. I believe you might mean 'dynamically'? You should be clearer.
4. point 3 "... as simple as..." would require an actual evaluation. That would take too much time. Choose less loaded words instead. [There is a strong current in CS right now to not let informal claims like this going unjustified.]
5. "Astonishingly": to whom? This is obvious to people who know enough category theory. You should not be astonished either. Instead, you should show these examples (as you do), and then explain the reason for them, in careful and precise categorical terms.
6. "The informal form is presented with the understanding that such functions need to be extended homomorphically..." Showing this formally is not hard. I've (re)written the code to do this (in Haskell, using Lenses, for the Tog-based prototype), and it's a few easily explained lines of code. This is core to your Ph.D. thesis, you must explain this in careful, precise, mathematical detail.

4.1 editor extension

This is based on commit 2a1878f

• "... provides an extension mechanism ... neither is particular appealing". [Minor: particular -> particularly]. "particularly appealing" is too much of a subjective judgement. You can say "but both have drawbacks" (which you then indeed enumerate).
• "The former is dangerous ..." what you describe here is hacking in a new feature. That is indeed dangerous. What about designing a new feature instead? Do some theory, figure out what it out to be, implement it. No problem. [see below]
• "latter is tiresome" this is specious. You could create a Makefile by which you do all your compilations that automates this. You could put in a hook in the IDE (emacs) to do this. Your editor extension is exactly a pre-processor. It's just a well-integrated one.
• "a middle-road is not always possible". While this is true, this is also not applicable, as your editor extension is not a 'middle road'. It's a convenient preprocessor. [I had written "It's just a", but realized that that kind of phrasing is exactly the kind of stuff that I'm trying to get you to stop doing.]

This is somewhat all moot anyways. Your real story is that you needed to write a prototype to really understand what was going on. Because it was a 'figuring out' exercise, hacking the compiler is indeed not a good idea. Implementing it as an external preprocessor is feasible, but it turns out that there's another way that has a nicer usability profile: an IDE extension.

Your bolding of reasonable here is unreasonable.

Figure 4.1 does not help at all. I don't want to explain the many ways in which it is misleading. You should remove it.

2.9 missing render?

The 700 block of 'Example use' has 3 things in it, but the output only 2 -- this is quite suspicious.

:kind or :type?

The meta-primitive is listed as being called :kind, but the first example in section 2.3 uses :type. Are the examples in this web page live or fake? Or is :type undocumented? Or something else altogether?

Verify that the page 'geometry' is letter

There is no specification either way, and some style sheet default to A4.

CCS Concepts, keywords, ACM Reference Format

As per instructions, these are manditory.

The ACM style provides the three small sections 'CCS Concepts', 'Keywords', and 'ACM Reference Format' to follow the abstract; these are mandatory on the paper in the given order. Make sure you correctly classify your paper using the new 2012 ACM Computing Classification System (CCS). The content of the CCS has to be picked from the provided list (with the CCS tool). The order of the CCS concepts is based on their relevance. The keywords can be freely chosen. (You should also insert the CCS XML snippet into your sources: for LaTeX documents using the environment 'CCSXML' and for Word documents using the properties dialog.) 

and be aware of

During the submission of the camera-ready paper using our submission site, you need to copy the XML snippet from the ACM CCS tool into a text field of the submission form. 

4.1 overuse of bold

This is based on commit 2a1878f

On p.7, you use bold way too much. It is good to bold "Why Emacs?" and "Why Lisp?", but none of the rest requires bolding.

Set up the copyright, DOI, etc.

This is dependent on issue #21 is it will give back information that must be put here. And then

%%% The following is specific to GPCE '19 and the paper
%%% 'A Language Feature to Unbundle Data at Will (Short Paper)'
%%% by Musa Al-hassy, Wolfram Kahl, and Jacques Carette.
%%%
\setcopyright{ACMUNKNOWN}
\acmPrice{}
\acmDOI{10.1145/3357765.3359523}
\acmYear{2019}
\copyrightyear{2019}
\acmISBN{978-1-4503-6980-0/19/10}
\acmConference[GPCE '19]{Proceedings of the 18th ACM SIGPLAN International Conference on Generative Programming: Concepts and Experiences}{October 21--22, 2019}{Athens, Greece}
\acmBooktitle{Proceedings of the 18th ACM SIGPLAN International Conference on Generative Programming: Concepts and Experiences (GPCE '19), October 21--22, 2019, Athens, Greece}

needs to be in the paper itself.

Referee comments

It seems that this one

• Page 3, References: URLs and ISSNs are superfluous when a DOI is provided.
  [Ler00], [Nor07]: add DOIs if available (then remove the URLs).

has not been taken care of.

4.1 Why textual transformations? III

This is based on commit 2a1878f

Given that #33 advocates for removal of the content before "Thus, rather than work with abstract...", the "Thus" becomes pointless.

On the other hand the 'design decision' to rewrite "phrases" from an extended syntax does need to be commented on. "legitimate existing syntax" can be deleted, as "Agda syntax" already contains that information.

There are alternatives to phrases. One could have considered annotations, for example. I'm sure there are other possibilities.

I am quite sure that the choice in the prototype was quite pragmatic. Your job is to convince your reader of that too.

PhD Thesis Writing

Hello!

I've written a brief Story that is intended to be the guide for writing the thesis.

It, more or less, tells the story of how we got to where we are right now.

From that, I've extracted a more detailed outline.

Any feedback on these items before I began to write large chunks of sections would be appreciated ^_^

Ensure that are no page numbers

The current PDF does have them. They should be removed.

Lack of organization

Everything is at the top-level, and not organized. Some stuff is obsolete, some isn't. It would be nice to use directories for organization, and a roadmap in the README to enable one to understand all the different artifacts available here.

Misplaced details in 4.1

The whole last paragraph "Moreover, to mitigate ..." is based on low-level implementation details that are both unknown to the reader, and irrelevant to the reader.

What is true and relevant is that the prototype goes to great lengths to 'fit' into the usual workflow of an Agda user. That is something that should be talked about (and in those terms, and via outlining a little bit what the workflow is). The intent of the paragraph seems to be to communicate this idea, but does not use those words - if I am interpreting it correctly.

Aiming for PEPM 2020?

Please see commit a7b9ac9 or, temporarily, here for the PDF of rough notes for ideas to be submitted to PEPM 2020.

In-particular:

0. Do the ideas in the rough notes communicate something somewhat useful to submit as a paper?

1. If so, please provide direction on the particular question marks interspersed in the document.

Exageration in "the middle path"

Two points:

1. To a naive user, the IDE for Agda is the compiler. Few ever use the raw compiler, so do not distinguish the editor interactions from Agda itself.
2. strictly speaking, the Prototype is a preprocessor. It is just integrated into the IDE, itself a preprocessor, in such a way that it does not feel like it. It is not a "manual command-line preprocessor", that is true.

In other words, the 3 circles picture is slightly more misleading than explanatory. [The text is not as imprecise.] I would recommend deleting the 3 circles picture. The arrow "How does it work" is fine.

Review GPCE Draft

@JacquesCarette and @WolframKahl, please.

Is the title appropriate?

I think the thesis sub-title is fine, in that it is an adequate description of some of the results. I don't think the title is.

Progressing towards a type theory for PackageFormers

Please take a look at prototype/pf.agda, line ~250 has a JC clause.

Please provide guidance and feedback.

4.1 Why textual transformations? I

This is based on commit 2a1878f

This section should start with citations to a number of overviews of metaprogramming.

The statement "Metaprogramming is notoriously difficult to work with
in typed settings, which mostly provide an opaque Term type thereby essentially resolving to
working with untyped syntax trees." is incredibly misleading. You are

• ignoring typed metaprogramming (like metaocaml and TTH), which is indeed difficult
• assuming that metaprogramming in a typed host language is done using the lowest available techniques (i.e. Expr), ignoring both GADTs and finally tagless
• claiming that somehow this Expr type is 'opaque' ? [this seems just plain false]

Roughly speaking, this statement of yours, rather than illuminating the reader, will tell a reader who actually understand the subtleties of metaprogramming, that the thesis author does not. Which I don't think is actually true, but it sure is what you wrote.

About the prototype - what to read?

I'd like to read about the prototype, try it out, understand it. But I can't tell how to do that. Independently of #5 , I would like to know what to look at to understand what the 5 key ideas (like 'waist') are in here.

Colour scheme confusion

The two diagrams in 4.1 (middle path and "how does it work") use similar colours, which confuses the reader (aka me) into thinking same-colour-same-meaning -- but this is quite false.

Two potential solution:

1. visual distance between the two diagrams, so that one isn't tempted to relate them
2. different colours in each, to not risk the confusion

level dec doesn't work?

The second example, of level dec, in section 2.4 of the document doesn't seem to actually do what it is documented to do.

4.1 over-explanation of the design choices

This is based on commit 2a1878f

Given the need for a convenient prototype (see #29), doing it in elisp in emacs just makes sense. Yes, it's funny (and the comments to that effect can stay in), but you're over-justifying yourself. There are 3-4 lines of text's worth of information on p.7. Try to make the explanation factual rather than 'aggressively defensive' of this reasonable design choice.

Review final version of GPCE paper

It is due in final form tomorrow (Wednesday). See Issue #1 for some earlier discussion, and recent commits.

4.1 Why textual transformations? II

This is based on commit 2a1878f

Starting at "For instance, consider the Lisp term ...", the write-up now assumes that the reader knows Lisp. And that Lisp uses anaphoric macros instead of proper binders matters to the thesis - it really doesn't. [If it does, then this is not communicated here at all.] I would delete this.

Has the abstract been adjusted to match the thesis?

It does not match the title, and seems too focused on a single sub-part of the thesis contents. It should reflect the thesis as a whole. Now is a good time to rewrite it.

Submit publishing rights agreement

See the email sent to us on how to do that. [I won't put it here as it's not public.]