Lambda the Ultimate

Thanks for the info. I'll take a closer look at CLOS, I'd be interested to see how it scales to more complex objects.

This technique is (sort of) used in the 'object systems' of scripting languages such as Perl/Python. The subs/functions (methods) of the packages (classes) by convention take a self (object) reference as their first parameter.

By calling these methods in static context and deliberately passing in the self object (instead of creating an implied self via new), these methods are called in a functional style. Indeed, this is the way I mentally model method calls when programming in these languages (by assuming all 'methods' are static). Further, this helps to localise the notion of 'state', as per functional programming.

Just like pattern matching is a selection of function based on a predicate, message dispatch is a selection of an implementation based on type; i.e. the predicate is the type.

Interesting, I never thought of it that way.

Classes are values too. Each number is a different class. If we think about each integer, for example, it has a different representation in the computer, i.e. it is a different structure of bits, i.e. a different record i.e. a different class. Therefore pattern matching on values is no different than pattern matching on classes.

In fact, the basis of all computing are the types bit 0 and bit 1. A combination of those yields a new type. Arithmetic operations for these types can be considered as overloads: for example, 2 + 1 is an overloading of + for types 2 and 1, respectively. Integers are records of union types of all possible products of 0 and 1. Records are tuples of integers, classes are records etc.

I personally consider type and value interchangeable concepts. By using this concept, I came to the understanding that a programming language should have a type system that also allows specific values to be declared as types. Modern mainstream programming languages fail on this point: algorithms often imply subtypes of the types used, but they offer no way to the programmer to define those subtypes.

I have an idea to make a programming language that has no type declarations, and all typing is done with binary operator as applied over expressions. I think it would be a very good type system, catching way more assumptions than those of mainstream PLs. The compiler would simply check if the expression on the left side is compatible with the result of the expression on the right side...this has the added benefit of using functions as type declarations, thus making functions executable at compile time.

(BTW, I had to read that last paragraph a few times before I noticed 'as' was in a slightly different font :)

Could you expand upon this idea? E.g. what would some simple code look like?

This reminds me of a paper on category theory that I've been trying to read -- true "equality" of two given objects is not really interesting, it is rather the two-way transformations/mappings (isomorphisms) that we make between them which are interesting; but sometimes we forget about the original objects, and we lose a lot of information.
(to paraphrase, "Take an apple and cut it into two equal pieces -- of course, they are not really equal, because if they were there would have only been half an apple". paper is by Baez & Dolan)

Likewise, aren't types a kind of isomorphism?

example of overloading based on values:

let factorial(n : n > 0) = n * factorial(n - 1)
let factorial(0) = 1
let factorial(n) = raise error

In the above example we can see the function 'factorial' implemented in 3 versions: one for positive numbers, one for 0, and one for negative numbers.

The style of programming resembles overloading methods, as there are 3 different functions with the same name.

The types of parameters are: positive, zero and negative.

The above is also pattern matching, because the function would actually be coded like this:

template  T factorial(T n) {
    if (n > 0) return n * factorial(n - 1);
    if (n == 0) return 1;
    throw error;
}

OK, but what if there are more than integers?

E.g. if you construct everything out of integers, how can you define '+' differently for anything else (like complex numbers)?
Do you have "primitive" operators (prim+, prim=, etc.) for the low-level, and redefine '+' for higher-level types (representations)?

I'm not sure if the latter part of your previous post,

I have an idea to make a programming language that has no type declarations, and all typing is done with binary operator as applied over expressions

is referring to something different than your factorial example, or not (you didn't mention 'as').

what you lose here is the ability to hide information. in some cases it is useful to have methods with privileged access to information

Yes, I think I might have taken the thought too far.

I can see that pulling methods out from simple classes, for example 3DVector, Colour, 4x4Matrix as I originally mentioned is probably a good idea, since someone may suddenly come up with a new operation you can perform on matrices and could add it and share the method without having to submit the change to the origional author of the class.

But I can see that as soon as you have a more complex class, say a motorcar, then you would want hidden state, and the ability to privately manipulate that state within the confines of the class (encapsulation).

But I can see that as soon as you have a more complex class, say a motorcar, then you would want hidden state, and the ability to privately manipulate that state within the confines of the class (encapsulation).

This could be handled by a more complex type system such as ocaml. While ocaml uses the object=attributes+methods model, it can easily hide information via interfaces:

Say you create a simple ocaml module named foo.ml:

open Printf;;

class point =
object (self)
  val x = 0
  val y = 0
     
  method private print_y = 
    printf "y: %d\n" y;
    ()

  method print =
    self#print_y; 
    printf "x: %d\n" x;
    ()
end;;

but you want to completely hide everything but the #print method in the foo.mli interface:

class point :
object
  method print : unit
end;;

then if you have another module, bar.ml, you can do this:

let p = new Foo.point in
  p#print;;

running:

> ocamlc foo.mli foo.ml bar.ml
> ./a.out
y: 1
x: 0

but trying to access #print_y will fail with a type error:

bah.ml:

let p = new Foo.point in
  p#print_y;;

running:

> ocamlc foo.mli foo.ml bah.ml
File "bah.ml", line 2, characters 2-3:
This expression has type Foo.point
It has no method print_y

Taking this mechanism, one can see how one could separate attributes and methods from the definition site via multiple interfaces to the same object. Unfortunately, I don't think ocaml supports hiding public methods, so you can't completely implement this technique in it, though.

Encapsulation should be a matter of accessibilty, not syntax. It could be possible that different parts of a more complex class are only trusted to certain functions only.

sure, but in practice you may want to control who decides this. one way of doing so is to only allow the programmer to grant access to hidden state within the lexical scope of the definition of the data structure.

that and how dispatch is decided seem to be the important issues here. are there any languages that provide both guaranteed (fixed at compile time) access control and multiple dispatch? if so, what syntax do they use? if not, is an elegant syntactical solution possible?

maybe there's an obvious example i'm missing...

I like the idea of changing the state of the system and asking it to create a record of the changes.

I will look more closely at smalltalk, but is it possible for people to publish the modifications without thought or do all changesets go through some sort of "conflict resolution" before release to the public?

You can create changesets whenever you like, but they aren't automatically published to anyone (you just get a .cs (changeset) file).

There are internal tools for examining/editing changesets (what classes were changed, which lines of which methods, etc.) and I believe for merging changesets, although I haven't used the latter.

Changes to Smalltalk classes and methods are automatically recorded in a file called the change log, as snippets of Smalltalk code which could recreate those changes. So if we changed something and as a result lost all our work, we could grab a clean new image and source file and replay the old change log up-to just before the bad idea, and get back to where we were.

That's Smalltalk as a personal computing environment - for decades there have been fine-grained version control systems that create a team programming environment for Smalltalk.

Some hint of the incredibly playful personal system they were trying to create comes through in this video - imagine programming a new kind of number, and then having that new kind of number be used to calculate the window coordinates of all the windows Smalltalk displayed...

Thanks for the link. I wish there was a cable channel that played these types of videos 24/7, but Google will do. At least their video section was smart enough to give me a list of similiar stuff.

Isn't the public (and to some degree protected) interface of a class a contract? I believe Herb Sutter would agree. And therefore aren't contracts themselves a form of information-hiding?

Although I agree with you that in certain domains data should be separated from methods, I myself struggle with the semantic difference between interfaces and contracts.

I didn't realise you could make methods friends of a class.

..but does it separate the methods from the class? since you still have to modify the class each time you need to add a new friend:

class Vector3D {
private:
    float x;
    float y;
    float z;	
    friend float Length(Foo &foo);
    friend float Dot(Foo &foo, Vector3D &other);
    friend Vector3D Cross(Foo &foo, Vector3D &other);
};
float Length(Foo &foo) {
    return Sqrt(foo.x*foo.x + foo.y*foo.y + foo.z*foo.z);
}
float Dot(Foo &foo, Vector3D &other) {
    ...
}
Vector3D Cross(Foo &foo, Vector3D &other) {
    ...
}

You are right that the class needs to be modified to add more friend functions. In this example, the option to use friend functions only means that the syntax of calls isn't tied to encapsulation, so you can make decisions about the syntax and encapsulation separately.

private strictly decreases the power of a programming language.

I guess I should have said, it decreases the power of code that uses it. It's funny that something so purely negative in its meaning can be of such tremendous value to people, but I don't think it's hard to see why.

Information hiding is an essential component of software engineering. Indeed, it is one of the few ideas in the field that survived the test of time.

Support for information hiding increases the expressivness of a programming language (or a module language, if that's more to your liking).