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

By: Petar Marendic

Petar Marendic — Tue, 05 Oct 2010 12:43:20 +0000

After making a long break from the book I skimmed through the first chapter to quickly brush up on the terminology and this sentence struck me as dubious:

page 14, line 12

"To define regularity of a unary functional procedure, we write..." - and yet on page 9 it is stated: "A functional procedure is a regular procedure defined on regular types..."

Seems redundant, or not?

Additionally, the precondition immediately following this sentence introduces the notion of function equality in its definition of procedure regularity ("Application of equal functions to equal arguments gives equal results"), something that was not mentioned on page 8, where regular procedures are defined as: "A procedure is regular if and only if replacing its inputs with equal objects results in equal output objects."

In my opinion, equality of functions deserves to be defined beforehand, as it's not a trivial idea. As far as I can see, it hasn't been explicitly introduced anywhere in the preceding portion of the text.

By: Sean Parent

Sean Parent — Sat, 11 Sep 2010 23:31:36 +0000

Yes. Various languages will ignore one or more properties of objects but the objects still exist as they are a “side effect” of providing a physical representation for a value. Functional languages deal with values and ignore address and mutability of parts (single assignment). Reference semantic languages (Java as an example) put a lower emphasis on copy (assignment assigns references, not objects). With FP languages the choice is to use a computational basis which simplifies reasoning but isn’t necessarily an efficient basis. The move with reference semantic languages come largely from dealing with variable sized, polymorphic, types. EoP seeks to provide a framework to reason about programming on current machine architectures, providing mathematical rigor without compromising efficiency. It can be viewed as an extension of FP, providing a framework to reason about object instead of simply ignoring them since under the hood they do exist in any FP system. Some of the ideas in EoP, such as an underlying type, are not particularly practical to implement in C++, yet the notion of an underlying type exists regardless of what language one is using.

By: Marcin Zalewski

Marcin Zalewski — Thu, 09 Sep 2010 20:23:28 +0000

Could it be that some languages choose to represent values instead of objects? For example, in most functional languages, including Haskell, one mostly works with values, and objects are usually considered hacks. For example:

data List a = Nil | Cons a (List a)

myList = Cons 1 (Cons 2 Nil)

myList does not have any of the properties of objects, including an address. It is a value representing a well-defined (abstract?) entity.

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.