Lambda the Ultimate

A product of critical programming language design. Abstract:

bodyf*ck is a computer programming environment that translates bodily movement into computer programs. Each physical motion committed by the programmer/performer becomes an operation in the esoteric programming language brainf*ck. Theoretically, because bodyf*ck is Turing-complete, all computable operations are possible. Despite this, physical difficulty in implementing more complicated programs may prove to concede the theoretical limitations of the potentially computed output.

Expletives stared out because I'm a coward.

Hello,

I am interested to know if there are languages out there, or research projects, or people's wild private imaginings, that provide polymorphic multimethods over structural types.

I mean the non-parametric type of polymorphism where methods may have > 1 implementation. The dispatch mechanism would choose the most specific of those available for a given invocation.

I have found one mention of something that seems in this area, but I don't understand the paper enough to know if it's what I hope for:

Combining Structural Subtyping and External Dispatch
Donna Malayeri & Jonathan Aldrich

I'm not _even_ a language design noob, and have only recently found there is established terminology ("structural types") for what I've been edging towards for about 10 years.

But… I envisage that the dispatch mechanism would be able to examine implementations of a method for the signature they require of their arguments. Given a method invocation is would be able to find the most specific implementation given the types, or fail if there is no match or the match is ambiguous.

I also think that a kind of transitive closure is necessary here. I'll use an example to elucidate (the example is "single dispatch", btw):


def area(shape) # implementation 1.
return width(shape) * height(shape)
end

def height(shape)
return square_size(shape)
end


I can now evaluate:

area( {width: 2, height: 3} )
-> 6
# This is just as you would suspect – implementations 1 is used.

area( {square_size: 2} )
-> 4
# here, the record itself doesn't directly fit implementation 1, but because of the "width" and "height" methods, it _can_ be used, so 1 is used. This is the kind of transitive closure.


Implementations's parameters are not decorated with explicit type declarations because the type an implementation needs for each of its arguments _are_ the methods it calls on those arguments.

So, if this kind of thing is going on all over the place and well known, I'd love to know. Or if it's been tried and found a terrible idea, that'd be good to know too :-) I find the possibility enormously exciting because I think it'd "fix" an awful lot of what I find rather hobbling about the languages I generally use. Especially if it could be embedded in some kind of live-coding environment.

Thanks,
Benjohn Barnes