Meaning and Reference in Programming Languages

Round 1

Reviewer 1 Report

Comments and Suggestions for Authors

General Comments: 

 

Overall, I found the paper to be very thoughtful and informative, without being too challenging for those approaching the subject for the first time or with partial knowledge of the topics discussed. My main concern is with how the central result is presented–rather than with the result itself. I believe all of my concerns can be resolved with modest changes to the original draft. 

 

Specific Comments:

 

Intention vs. Intentional Stance: In line 12, the author mentions the “intentional stance” of agents, but this appears (based on later discussion) to be distinct from the intentional stance of Dennett. I would either (i) drop talk of an “intentional stance” or (ii) take some time to disambiguate the kind of intentional approach here from that of Dennett. I think (ii) would be very interesting, and I think I might even favor an interpretationist approach like Dennett’s in this case, but it does seem to be different from the “intentionalist” approach under discussion here. However, I also understand if (i) is preferred for reasons of brevity since doing justice to (ii) would be non-trivial.

 

Meaning and Truth Values: This is probably a linguistic issue, but it seems odd to say (as the author does in lines 351-361) that the meaning of a sentence “is its truth value.” I think “truth conditions” might be more appropriate since I tend to think of a truth value as simply a Boolean value assigned to a sentence. I think the author’s examples lend themselves to talk of “truth conditions.” For example, in the FOL example given, the sentence is true iff a is an element of the set defining the extension of P.

 

Programming Semantics: The central result of the paper seems to be that “meaning alone does not suffice to pick out a referent for programming languages; developers’ intentions are needed as well” (lines 590-591). This result, however, seems to depend on thinking that the approaches to semantics and reference discussed in the paper are exhaustive. For example, what stops us from saying that the right approach to semantics is actually some kind of (as yet unconsidered) intentional approach? The result above assumes that intentions are something over and above meaning as defined by our semantics, but that only makes sense on a non-intentional account of program semantics. Also, there are accounts of reference not considered here (e.g., reference magnetism) that could (in theory) be relevant but are not discussed.

 

I think the author can work around this problem by doing two things. First, do a bit more to explain why we can restrict our attention to operational, denotational, game theoretic, and axiomatic semantics. This might be because these are the live options among computer scientists. This might be because other (e.g., more intentional approaches) cannot deliver key desiderata sought by computer scientists in any account of program semantics. Essentially, what is needed is to show that a result restricted to “meaning” as countenanced by these approaches is nevertheless interesting (which I strongly suspect is true!).  Second, the author should be more explicit in addressing the limitations of the key results to the views discussed–if only because of the massive amount of work in the philosophy of language on meaning and reference.  Again, I don’t think that this undermines the value of the results presented here.

 

External World: Looking at the second result (lines 593-595), why wouldn’t the right sort of “intentional act” (combined with relevant semantics) be sufficient to secure reference to the external world? For example, if I write a program and intend the variable “temp” to represent a particular temperature, why doesn’t “temp” represent that temperature rather than (merely) the value in some input register connected to a thermistor?   

 

Ending: I found the very ending of the paper rather abrupt. Perhaps one more short paragraph might be added on future directions. 

Grammatical/Typographical Issues:

 

Line 86: “given e set” > “given a set”

 

Line 102: “the system object of study” > “the system as an object of study” or “the system” or “the object of study”

 

Line 151: “execution traces… maps” > “execution traces… map”

 

Line 157: “actuall” > “actually”

 

Line 157: “mnaipulates” > “manipulates”

 

Line 204: missing reference

 

Line 208: “Aim” > “The aim”

 

Line 226: missing reference

 

Line 350: (set of) > (sets of) [to be technical, you might want to mention sets of tuples of elements of the world to accommodate 2+ place predicates].  

 

Line 459: “propositions which” > “propositions whose”

 

Line 473: “Similarly considerations” > “Similar considerations”

 

Line 475: “permit to pick out” > “permit us to pick out” or “permit one to pick out”

 

Line 480: “corresponding to more referents” >  “corresponding to multiple referents”

 

Line 504: “is not many-to-one” > “is no many-to-one”

 

Line 504: “as it is” > “as there is”

Author Response

Dear reviewer,

I feel very grateful for the received remarks that helped me in better clarifying some points and improving my manuscript. I addressed all your comments; in the revised manuscript, the modified parts referring to your comments have been marked in blue, for your perusal. In the following you will find a point by point reply to your remarks.

- Intention vs. Intentional Stance. I believe I have been careless in using the expression ‘intentional stance’ in the abstract and the less demanding word ‘intention’ in section 4. For this reason I am now using ‘intention’ in the abstract and footnote 17 in section 4 clarifies that the expression ‘intentional stance’ is used in different ways in the philosophy of computer science and in the philosophy of mind (Dennett).

- Meaning and Truth Values. I replaced ‘truth values’ with ‘truth conditions’ in section 3, as indicated.

- Programming Semantics. Both your suggestions have been addressed in the revised manuscript: firstly, in section 2 I justified the choice of restricting my attention to operational, denotational, game theoretic, and axiomatic semantics by making reference to the distinction between static and dynamic semantics and arguing that only static semantics matters here; secondly, in section 5 I highlighted how the argued conclusions hold as long as one considers the main theories of meaning and of reference, while the meaning/reference problem is still an on-going debate with new emerging positions (reference magnetism is also mentioned in footnote 18).

- External World. This comment helped me in clarifying my point, and I am very grateful for this. It is now underlined in section 5 how an intentional theory of reference may make a program code refer to the external world, but not in virtue of the semantics of the used programming language.

- Ending. I added a final paragraph in the concluding section underling the relevance of the advanced arguments for the program as theories thesis.

- Grammatical/Typographical Issues. All issues have been fixed.

Reviewer 2 Report

Comments and Suggestions for Authors

This article asks an interesting and to my knowledge original question what formal semantics say about the reference of high level programming language. It explores this question with explicit reference to many positions in philosophy of language about meaning and reference. Unfortunately, and rather often I might add, to rather confusing effect. There are other topics that are touched upon in passing, like the view that programs are theories, which the authors believes formal semantics say something about. But in the end it becomes clear that their main interest lies in the limits of program verification. 

The core argument, as far as I could reconstruct it goes like this:

1. There are different formal semantics for programming languages.
2. One of them (denotational semantics) is similar to mathematical model theory in that it provides meanings by reference.
3. Because there are different (presumably referentially) equivalent semantics for programming languages, there is a many-to-one relationship between meaning and reference.

There is an interlude where the different semantics are identified with different Fregean senses (the author writes "different modes of presenting the meaning" which is, if not outright wrong, at least misleading). In any case the referent is presumable the abstract machine which corresponds to a program. (N.b.: the author really should distinguish more carefully between programming language, program, program trace). 
The argument then proceeds, by noting that:

4. between abstract and physical machines there is a one-to-many relation (because of multiple realizability).
5. Thus, the relation between the semantics of a program and physical machines there is a many-to-many relationship.

This many-to-many relationship between program semantics and physical machines is thought to contradict Fregean descriptivism and it is suggested that an intentional theory of reference is at play. It is also concluded that formal software verification is not enough if one is interested in the correct operation of physical computers (probably something that even the most hardcore formalist would agree with). In a way these conclusions are obvious, because the discussed formal semantics are formal and thus can only refer formally. 
One point where I think the argument needs to be strengthened is the presumed equivalence of formal semantics. It is quite unclear how this equivalence is established. There is some allusion to the full abstraction property, but the reader is left in the dark about what it is. Some words should also be spent on the transition from formal semantics to physical machines. Why should we care about physical machines? In a more general vein, the very general and basic discussion of positions in philosophy of language should be reduced. I don't see how they contribute to or advance the argument the author brings forward. A similar thing can be said about the presentation of formal semantics. If we don't get an explicit argument about why they are equivalent, why devote so much space to examples? Furthermore I think the introduction needs to be reworked. In its current form it reads like a mini argument against programs as theories which doesn't fit into the general setup of the article. I would especially recommend paying attention to an informal presentation of the central concepts of the paper and how they relate. Some examples: programs and program execution traces, programming language construct. The different senses of model (at least to are equivocated), theories informal and formal, syntax, semantics, meaning, implementation, reference, specification and correctness. It would be very helpful for the reader if the intended meaning of these terms is introduced before they are used. 

Comments on the Quality of English Language

Typos/grammar/clarification:

24: inquires upon
34: "Just as natural languages, the formal languages of computer science are defined by a syntax and a semantics" - Do you really thing natural languages are defined like this?
67: "This paper examines whether meaning determines reference for high-level programming languages." - Just out of curiosity, what would define meaning for low level programming languages?
79: Herbert Symon
86: given e set of initial
93: Not only, program execution traces are analogs of mental processes
125: scientific models do with their target empirical systems
137: scientific models do with their target empirical systems
151: execution traces of simulative programs directly maps onto
154: More in general
157: not actuall add two numbers, it simply mnaipulates
182: "In other words, for a machine code to be an implementation of a high-level language code means, for the former, assigning meaning to the latter in that medium of implementation given by the low-level language." This is an extremely contrived sentence.
204: problem [? ].
208: Aim of this paper
210: on what is meaning and what is reference
226: [24? ].
247: As state above,
313: to each program construct is associated an axiom
439: whether Fregean slogan holds true
Footnote 11: I think you mean the intensional (!=intentional) theory of reference here.
476: as it is for Fregean descriptions.
503: there is not many-to-one correspondence between meaning and reference as it is for Fregean descriptivism
527: Aim of programming language semantics
570: The choice of which level of abstraction implements the upper one is intentional, done in this case by developers.

Author Response

Dear Reviewer,

Thank you for your comments and remarks; in the revised manuscript I tried to address all of them and I believe now my arguments are clearer and the manuscript improved. In the revised manuscript, the modified parts referring to your comments have been marked in green, for your perusal. In the following you will find a point by point reply to your remarks.

- Presumed equivalence of formal semantics.

The full abstraction property and the full abstraction problem are now extensively defined in section 2. It is now more explicitly stressed how, whereas only game theoretic and operational semantics can be considered formally equivalent, the paper assumes the so-called definitional priority of operational semantics, requiring that all the other semantics adhere to it.

- The very general and basic discussion of positions in philosophy of language should be reduced/ A similar thing can be said about the presentation of formal semantics/  I think the introduction needs to be reworked. In its current form it reads like a mini argument against programs as theories which doesn't fit into the general setup of the article.

I deleted section 2 on the program as theory thesis and included its most relevant points in the introduction. I preferred not to reduce the discussion of the positions in philosophy of language and the presentation of formal semantics since the other reviewer appreciated the fact that, so conceived, the paper can be read by both philosophers and computer scientists.

- I would especially recommend paying attention to an informal presentation of the central concepts of the paper and how they relate. Some examples: programs and program execution traces, programming language construct. The different senses of model (at least to are equivocated), theories informal and formal, syntax, semantics, meaning, implementation, reference, specification and correctness.

A footnote for each of the listed concept has been added providing the respective definition.

- N.b.: the author really should distinguish more carefully between programming language, program, program trace)

Due to the cut of the old section 2, no reference to program traces is now made; some passages have been modified to distinguish, in a more careful way, programs from the programming languages with which they are encoded.

 

- Typos/grammar/clarification.

All the listed issues have been fixed or deleted due to the reworking of the old section 2.