Lambda the Ultimate

About posting (I really should update the FAQ, I know. But I am very busy at the moment. It will happen. Sorry):

Members can post to the discussion group. Only editors can post to the home page. Editors are usually members that frequently come up with good links and have insightful comments. But anyone can apply. I haven't refused anyone yet.

We usually don't link from the home page to projects we are involved with directly, but prefer other editors to give such links, if they find the work interesting enough. This gives us a two-level system: The discussion group is not moderated, but the home page is. So if a LtU reader is only interested in reading quality papers, and isn't interested in our rambling discussions, he can use the RSS fead, or just read the home page.

Often, when a discussion becomes interesting enough and editor will decide to link to it from the home page.

Reading the essay was fascinating and hard: as-fascinating-as a visit to an alien culture, and so hard not to scream ;-)

What does the essay mean exactly by multi-paradigm design? I expected to see something about functional programming and logic programming and constraint programming as included paradigms (Mozart/Oz). If that isn't what it means, what does it mean?

Is the essay about multiple paradigms or the unification of multiple paradigms in a single language? (Beta)

the problem domain and the solution domain Here's a rich and concise exposition on problem domains Practice, Principles and Prejudices.

As Coplien says, “All other languages debates aside, one advantage of C++ is that it directly expresses the intent of the analysis in a way that Smalltalk can only do by convention.”

Personally, I am interested in what both these groups bring to the table.

I was trying to stretch and learn something
Help me learn something! I ask those questions because I don't have a background in C++. I'm asking you to find other ways to explain it to me.

I will try to write some more later.

Let me try. I don't know Smalltalk at all so I don't know if I will make any sense-) He says "In C++, we can write a single List template - one set of source - that can maintain lists of any kinds if objects. We can do the same thing in Smalltalk, though the mechanisms that make the same genericity possible are implemented in a much different way. All other language debates aside, one advantage of C++ is that it directly expresses the intent of the analysis in a way that Smalltalk can do only by convention."

Can you fill in the Smalltalk mechanism? Coplien is refering to the original FAST method [Weiss, David Family Based Domain Engineering, Reading Mass. Addison Wesley, 1987] which uses commonality and variability analysis to chacterize families of software artifacts or abstractions. Instead of leaving the programming langauge to chance, FAST builds a structured vocabulary of family members as the basis for a custom programming language for each domain. He is using Weiss' principles to underly most of what he proposes in the book. He states that he parts company with Weiss only at the point of choosing a programming language/ Multi=paradigm design does not derive the structure of a custom programming language from the application domain analysis. Rather, it extracts the structure from a rich, general-pupose programming language such as C++ and matches it to the needs of the application domain. It uses that structure to guide design with more regulariry than with the original synthesis process but with more flexibility than with the FAST process alone. Thats the context leading to his comments.

Does that help?

Many language features are focused primarily on exploiting commonality and accommodating variability. Language mechanisms are designed to a support particular paradigm or group of paradigms such as procedural, functional, object-based, and object-oriented. Each of these paradigms reflects a recurring pairing of commonalities and variabilities.

If I've understood correctly; scope, commonality, and variability (SCV) analysis can be used with any programming paradigm. Which would lead me to think of it as cross-paradigm design. Maybe it depends on what your definition of a paradigm is:

A paradigm, as the term is popularly used in contemporary software design, is a way of organizing system abstractions around properties of commonality and variation. The object paradigm organizes systems around abstractions based on commonality in structure and behavior and variation in structure and algorithm. The template paradigm is based on structural commonality across family members, with variations explicitly factored out into template parameters. Overloaded functions form families whose members share the same name and semantics, and in which each family member is differentiated by its formal parameter types.

SCV seems an interesting descriptive tool and technique. Can someone on LtU can provide an example of SCV for functional programming?

All other languages debates aside, one advantage of C++ is that it directly expresses the intent of the analysis in a way that Smalltalk can only do by convention.
Maybe this doesn't say more than the obvious: C++ is statically typed - so there's type information in the source code; Smalltalk isn't statically typed - so there isn't type information in the source code (apart from naming conventions and comments).

Can you fill in the Smalltalk mechanism?
Smalltalk lists are polymorphic - they can contain any kind of object, they can contain different kinds of object at the same time.

In the usual Smalltalk way support for refactoring became part of the toolset: the Refactoring Browser.

I used to think we had three types of abstraction: data, control and syntactical. OO only addresses data abstraction. Functional programming also gives you control abstraction. Macros gives you syntactical abstraction. There are levels of expressitivity in each dimension. Not all OO languages address data abstraction equally. C++ has parametric polymorphism, aka generics, aka templates. Java doesn't. There are also different approaches in each dimension. OO and FP decompose data abstraction in different ways. OO makes it easy to add new data, FP to add new operations. Some languages laughingly pretend to intergrate the two (Python, Ruby, O'Caml, PLT Scheme) but support distinct functional and OO features. Some language really intergrate the two (CLOS, Dylan, Cecil, EML) by providing multiple dispatch systems.

I'm beginning to think that time is the fourth level of abstraction. Staged evaluation systems seem like a really good thing. Being able to specify distinct configuration-time and run-time code seems to capture many uses of templates (e.g. the smart-pointers), AOP and units. I think one wants many evaluation times, not some language defined set. This idea is still hazy but it feels to me like a good one.

Functional programming also gives you control abstraction
First class functions, higher level functions, & functional composition address control abstraction. How does functional programming address data abstraction?

If guess HOF has nothing to do with data abstraction, but functional programming has become (largely) synonymous with static type systems in which data abstraction is via the good old sum-of-product type and pattern matching on constructors.

it takes you a second
Longer than that, looks like Modula2 ;-) A high-level Modula2 & pattern matching is nice.

By the way, I think it's a bit misleading to say that functional programming languages give you control abstractions. To the extent that an iterator is a control abstraction, I'd agree. However, if you want arbitrary control abstractions you need something like scheme's call/cc, which is not a feature of most functional languages.

data Point =P Float Float
data Shape = Circle Point Float |
             Rectangle Point Point


isRound ::Shape -> Bool
isRound (Circle __)=True
isRound (Rectangle __)=False


shapeArea ::Shape ->Float
shapeArea (Circle _r )=pi *r *r
shapeArea (Rectangle (P x1 y1)(P x2 y2))=abs (x1 –x2)*abs (y1 –y2)

isRound and shapeArea are functions that behave differently, acccording to the type of their argument (analogy: virtual functions/dispatching). They are not part of the type (i.e, there's no class construct, so no class interface and encapsulation. These can be implemented using the module system). The operations are defined for the various types using pattern matching (which is more declerative).

A list of Shapes can be heterogeneous and contain both Circles and Rectangles.