Contents
- This doesn't actually matter but in my opinion having the table of contents in black would look cleaner
Introduction and Motivation
- I like the quote
- I would remove the word and here: "smart devices to vehicles, and to national defense systems"
- I would put "that" before "there" in this sentence: "programming languages to help verify there are no bugs "
- I don't really like "indeed" here "all programs written indeed perform as intended "
- add comma after "example": "For example we say that true and false are "
- I am not sure what types is here. I understood type system but what are the types?: "program specifications can be encoded in the types, allowing the program"
- make to makes: "code redundancy and make specifications more intuitive "
- represents to represent in both times in "l and let n represents the length of the list and a represents the type of the list elements."
- Maybe italicize the variables instead of the slight bold to make it more obvious when a single variable is in a sentence, not the code part. I had to reread a few sentences because I missed the fact that it was a variable.
Background
- 2.1
- I found the brief example of functional programming helpful
- 2.3
- I would either get rid of etc or make "and" a comma: "respect to times), and sometimes divergence (non-termination) etc. "
- 2.3.1
- I would try to say this a different way. I found it confusing: "actually a simple idea wrapping a value into the wrapped value,"
- attempts to attempt: "One attempts is to specify the function with type"
- find to finds: "Yet one quickly find himself in trouble as"
- put comma before etc. when it is used in a list: "State monad to simulate in-place value updates etc."
- Do this throughout the paper
- 2.4
- 2.4.1
- Is this a pun or reference to something? If not, I would change the section name "Learn You a Haskell" to be more grammatically correct
- Is there a reason you used semicolons and not commas here when listing? Is that allowed grammatically? Also I would make the third "and" a comma and add a comma before etc.: "no variables will be mutated; no reading and writing to standard inputs and outputs or connecting to a socket is allowed; and no error handling is performed etc."
- exactly to exact: "the function always returns the exactly same result,"
- I would maybe switch the second a third paragraph in this section so the definitions of statically typed and strongly typed come sooner. As a reader I didn't know those terms and thought they weren't going to be defined. I would really have to think about if switching them is the right move though. (maybe I wouldn't change it after reading the entire section but I would definitely think about it)
- add dash to "statically typed": "Haskell is statically typed, where every variable’s"
- There is no dash again in this sentence "Java is strongly typed". Is there a rule on when to dash and when not to? If not, I would standardize this throughout your paper
- "result of an operation is only computed unless they’re required." change to "result of an operation is only computed if they’re required." or "result of an operation is not computed unless they’re required."
- This is ok "afore-defined" since it is proper English. I think it sounds weird though and had to google its meaning.
- I would put commas around "inner" because right now it reads to me that there should be 2 inner doubles and we are talking about the 2nd one: "a result from the second inner double"
- make first "and" a comma and change "produce" to "produces": "from the second inner double and the second inner double will be executed to produce the doubled list, and finally the outer double takes the resulting doubled list as input and produce the quadrupled "
- I think that whole sentence is a run on sentence. Either reduce the number of "and"s or split it up into 2 sentences
- 2.5
- 2.6
- Break this up into at least 2 sentences if not 3: "F* is said to be general-purpose as it is expressive enough to support programming in various practical domains; it is verification-oriented as it applies formal verification techniques to prove the correctness of programs written in F*; F* is also effectful, for it allows programs with side-effects, such as I/O, exceptions, stateful processing, or programs that potentially diverge."
- 2.6.1.1
- Could you write the double function from before in F* if it is not going to be the exact same as Haskell. If it is the same maybe say that it would be the same.
- Good explanations of the languages!
3. Approach and Novelty
- I would start this section off by defining your goal again since it has been awhile this you talked about what you are doing since you had all the needed background info
- Did you at any point say why you choose these two languages to compare?
4. Current Results
- I just noticed this but it is throughout the entire paper, I would indent the first paragraph of every section.
5. Related work
- Should this be before your work?
Check throughout the paper for the grammatical mistakes shown in specific examples above.
I think your paper has a very nice flow and order to it. I believe it also reads very well. The main advise I have is to look over the sentences that list things for grammatical errors.
I would add a few times sentences about what your goal is because I forgot it by the end of the paper.