respond to comments of 8 April 2024

Comments follow.

[x] Lint 1, title: "Replacement" has troublesome connotations, including the suggestion that you can replace pattern matching in existing code. How about "An alternative to pattern matching"?
[x] Lines 6 to 10: For now, time to remove your advisors' names, I think.
[x] Line 11: Abstract should be signposted as such.
[ ] Citation: It's late in the day for this, but the process of citation can be much simplified by using nbibtex (https://www.cs.tufts.edu/~nr/nbibtex/).
[ ] Revision of the abstract: Return to Landes. You're looking for the most essential information in the paper. Last sentence is a good start. Can you characterize the subset? "We explore" is not so good. What's the essential info there?
[x] Line 55: strike "rich"
[x] Line 55: "A primary appeal ..." fails the nominalization (Williams) test. And "dominance over observer functions" is not going to mean anything. If you are starting near this level, you should say what is the common problem that is solved by both pattern matching and observer functions. This intro can resolve the "observers" vs "observer functions" issue in favor of "observers."
[x] And for it you should cite Liskov and Guttag. One of the following, I don't remember which one (both should be in my office):

@book{liskov:abstraction, author = "Barbara Liskov and John Guttag", title = "Abstraction and Specification in Program Development", publisher = "MIT Press/McGraw-Hill", address="Cambridge, MA", year = "1986", keywords = "CLU, programming language, abstract datatype data type, ADT, module, modular, OO OOP", abstract = "XXXISBN 0-262-12112-3 CLU is in an appendix", }

@Book{liskov:program, author = "Barbara Liskov and John Guttag", title = "Program development in {Java}: abstraction, specification, and object-oriented design", publisher = "Addison-Wesley", address = "Reading, Mass", pages = "xix + 443", year = "2001", XXXISBN = "0-201-65768-6", LCCN = "QA76.73.J38 L58 2001", bibdate = "Mon May 6 06:26:30 MDT 2002", keywords = "Java (computer program language); object-oriented programming (computer science)", }
[x] Line 75: About error prone, state the case concretely: Direct use of tl can cause a program to halt with an uncaught Empty exception, a possibility that the compiler cannot rule out. By contrast, pattern matching can fail only with a Match exception, a possibility the compiler can rule out.
[x] Line 75: For verbose, present two examples and as the reader to compare.
[x] Formatting: Combine figures 1 and 2 to show the alternatives side by side.
[x] Line 97: Needs a comparison, and also a better verb. The actor here is the programmer and the action is simplifying the code. What's possible with PM + clausal definitions? What's possible with observers + clausal definitions?
[x] Line 114: What's the purpose of this sentence? How does "serves as a cornerstone" relate to the presentation in section 2.2?
[x] Line 115, "However, ...": What are the actors and actions here? Hint: language designer.
[x] Line 119: At this point you should focus on your thesis, so "we" needs to become "I."
[x] Line 120, "streamline clunky or verbose code": who's the actor here?
[x] Line 127: "Need" is awfully strong.
[x] Line 145, "The reader likely sees...": Huh? If you mean "you," say "you." But for this particular sentence, I prefer "this code can be simplified by using the pattern NAME n with a side condition."
[x] Formatting: Numbered figures in the middle of the text look weird to me, but I don't object to them.
[x] Line 157: Coherent subjects suggests that the subject of this sentence be changed to "Side conditions."
[x] Lines 159 to 165: Consistent diction with the verbs, please. E.g., "exploit" in both places.
[x] Line 167: Notice how much better this opening is with the correct subject. Now please fix the main verb "serve."
[x] Lines 169 to 170, "But what...": Baffling because there is no example. The rest of the paragraph describes a problem that only the author understands. Make your readers understand also.
[x] Lines 178 to 181: Far too general to be useful. What is the problem you are trying to solve? I can't tell until lines 221 to 231, and even then I'm not confident. "Given two keys, if both are associated with values, return the sum of the associated values, otherwise fail."
[x] Lines 221 to 231: A bit of a straw man, since the classic workaround is as follows:

clunky env var1 var2 = 
    case (lookup env var1, lookup env var2) of 
        (Just val1, Just val2) -> val1 + val2
        _ -> fail

[x] Incidentally I think it would help in this example simply to assume that fail is bound in the environment, with a suitable type.
[x] Line 256: Not sure the conclusion "elegant" is warranted based on what you show. You might be better served to lift the footnote and to characterize the examples.
[x] Overall: I'm not buying the generalities about "what kind of pattern are we matching now." E.g., "match all parts of a sequence, match any part of a sequence." IMO you'll be better served by showing the examples on a different basis: "these are the extensions commonly found in the literature and implemented in common compilers." Only then, after they are all presented, might it make sense to fit them into a common, general framework. TL;DR: particular (specific) before general, please.
[x] Lines 284 to 286: Information in these footnotes is too important to be relegated to footnotes.
[x] Lines 310 to 317: A whole paragraph is too long to say that or-patterns enable programmers to establish a single point of truth. (And in a footnote you could consider mentioning that this avoids the workaround of defining a bunch of nested functions, duplicating calls rather than logic.)
[x] Line 327: See if you can turn that off.

rogerburtonpatel / vml

respond to comments of 8 April 2024 #39