Comments on: “Elements of Programming” Chapter 1: Foundations

By: Ahmed Charles

Ahmed Charles — Fri, 26 Feb 2010 18:19:03 +0000

I noticed that Domain as defined at the bottom of page 12 is used to determine both the domain and codomain of the square procedure on page 13. That seems a bit less than precise.

By: Dave Abrahams

Dave Abrahams — Wed, 27 Jan 2010 17:37:18 +0000

Sean Parent: Relationships are external to the type – regardless of how important that relationship is. Consider an array, “a”, with 3 elements. a[1] is after a[0] and before a[2]. Those are very important properties of a[1]. But copying a[1] severs those relationships.

Yeah, but so does moving. That makes memory order a very different kind of relationship.

Let’s not go too far down this path though since it is outside the scope of EoP – and on this topic I can’t speak for Alex and Paul except that I suspect they would agree with me that there is enough material in dealing with relationship properties to write another book.

I'm willing to "not go too far" down this path, but just for the record, I don't buy what you're selling here. I believe these types do undercut the statement about all types being intrinsically (or logically) Regular, principally because they break the relationship between move and copy that makes Regular meaningful.

By: Dave Abrahams

Dave Abrahams — Wed, 27 Jan 2010 17:32:36 +0000

I would have an easier time with this if it didn't circle back to a statement that "the type is still intrinsically regular." Still, if I put that together with its context ("we can still use equational reasoning"), I may be able to understand. What I think you're saying is that, even if we can't implement equality, there is still a fundamental platonic notion of equality that applies and allows us to reason about programs.

Fine, as far as it goes. But "Regular" as defined does include efficiency guarantees. When you say "intrinsically regular" it implies to me that Regular is in there somewhere waiting to be realized. I think you really mean something more like "logically regular," i.e. the phrase needs a qualifier that implies a weakening of the notion of regularity, and "intrinsic" implies strengthening (or at least, not weakening).

By: Mark Ruzon

Mark Ruzon — Tue, 12 Jan 2010 00:19:34 +0000

I think it’s no more complicated than saying (e.g.) that ‘int’ refers to a fixed-size integer type and not Z, the set of all integers.

By: Andrzej Krzemienski

Andrzej Krzemienski — Sun, 10 Jan 2010 11:45:10 +0000

Hi, in section 1.3 (Objects) we read "This book uses a programming language that has no way to describe values and value types as separate from objects and object types." I am having trouble imagining how would such a separation look like, and how/if it would be helpful. Could anyone give me a hint?

Regards, &rzej

By: Sean Parent

Sean Parent — Wed, 30 Dec 2009 23:55:26 +0000

It’s about time to get moving on to Chapter 2. Please e-mail your homework for Chapter 1 to eop-study@cpp-next.com and Dave and I will summarize.

By: Sean Parent

Sean Parent — Wed, 30 Dec 2009 23:51:40 +0000

It wasn’t intended to be a Zen meditation. Let’s use one of the above examples – graph isomorphism. We can define that two graphs are equal iff they are isomorphic. Now, we can claim that if we copy a graph, the new graph is equal to the original. We know that representational equality implies true equality so we could use representational equality to verify our copy. We can’t implement a general, useful, equality (one that terminates for graphs beyond some size) so our implementation is necessarily incomplete. But the type is still intrinsically regular and we can still use equational reasoning to reason about our code, although there may be many operations for which we can’t verify the results – even though we can prove them correct.

By: Sean Parent

Sean Parent — Wed, 30 Dec 2009 23:35:11 +0000

[Sorry for the break - buried by the holidays!] “p belongs to Domain(f)” does not imply “p belongs to definition space of f”. But for any such definition you can read an implied “where op is defined”. In early drafts the book was very rigorous about always stating that requirement, but it was observed that the definition space is better managed as pre-conditions, not type requirements, and so these requirements were pulled. The book is still rigorous about managing the pre-condition that the values passed to a function are within the definition space for the function (we’ll see discussion of this in Chapter 2).

By: Mark Ruzon

Mark Ruzon — Tue, 29 Dec 2009 23:13:51 +0000

Domain(f) is a type, and the definition space of f is a set of values. So "p belongs to Domain(f)" does not imply "p belongs to the definition space of f." The converse is true, of course.

BinaryOperation (p. 31) is defined as an Operation that takes two parameters. An associative binary operation satisfies the condition you mention, but this is merely a property of some binary operations.

By: Andrew Suton

Andrew Suton — Mon, 14 Dec 2009 19:39:03 +0000

Well, the first take turned out to be a total failure. Not surprising… A diagram–even multiple diagrams–probably won’t be sufficient to capture the number of concepts (not a pun) established in this chapter. Part of the problem is that this chapter addresses such a broad scope of topics and the semantic connections between them are numerous and sometimes not easily defined. I’ll have to give a diagrammatic presentation some more thought, sketch out some ideas, etc.

It might be that the optimal presentation is actually a wiki. That might also be useful for attaching specific conversation threads to a definition or concept. Just a thought.