Mutating Programming Language

language-designprogramming-languages

For fun I was thinking about how a programming paradigm could differ from OOP and came up with this concept. I don't have a strong foundation in computer science so it might be common place without me knowing it (more likely it's just a stupid idea 🙂

I apologize in advance for this somewhat rambling question, anyways here goes:

In normal OOP methods and classes are variant only upon parameters, meaning if two different classes/methods call the same method they get the same output.

My, perhaps crazy idea, is that the calling method and class could be an "invisible" part of it's signature and the response could vary depending on who call's an method.

Say that we have a Window object with a Break() method, now anyone (who has access) could call this method on Window with the same result.

Now say that we have two different objects, Hammer and SledgeHammer. If Break need to produce different results based on these we'd pass them as parameters Break(IBluntObject bluntObject)

With a mutating programming language (mpl) the operating objects on the method would be visible to the Break Method without begin explicitly defined and it could adopt itself based on them). So if SledgeHammer calls Window.Break() it would generate vastly different results than if Hammer did so.

If classes are black boxes then mutating classes are black boxes that knows who's (trying) to push it's buttons and can adapt their behavior accordingly.

You could also have different permission sets on methods depending who's calling them rather than having absolute permissions like public and private.

Does this have any advantage over OOP? Or perhaps I should say, would it add anything to it since you should be able to simply add this aspect to methods (just give access to a CallingMethod and CallingClass variable in context)

I'm not sure, might be to hard to wrap one's head around, it would be kinda interesting to have classes that adopted themselves to who uses them though.
Still it's an interesting concept, what do you think, is it viable?

Here's some potential dummy code from a game where a player has is damaged by something. In normal OOP most things would instead be passed as parameters to the method whereas here Damage "pulls" the properties it uses. Different? yes, better? perhaps not 🙂

Class Player
{
    [AccessableBy:Terrain,Player]
    void Damage
    {
        if (#CallingClass has property HitPoints)
        {
            this.health -= #CallingClass.HitPoints;
        }

        if (this.health < 0 && #CallingClass is Terrain)
        {
            ShowMessage("was killed by the environment");
        }
        else if (health < 0 && #CallingClass is Player &&  #CallingMethod is RocketLauncher)
        {
            ShowMessage("was killed with a rocketlauncher by player" + #CallingClass.PlayerName);
        }

    }
}

To reduce if-else statements you could have method overrides based on caller methods and classes

Best Answer

Let me see if I understand what you're getting at.

In traditional OOP languages like C++ or C#, the action of a method depends on the runtime type of the receiver:

Window w1 = new GlassWindow();
Window w2 = new PlexiglassWindow();
w1.Break(new Brick());
w2.Break(new Brick());

Which method is actually invoked depends on the runtime type, not the compile time type, of the receiver, provided that Break is "virtual".

Languages which have this property are called "single virtual dispatch" languages.

Your proposal is that the action of Break depend also upon the runtime type of the argument. Suppose Break takes an Object:

w1.Break(new Hammer());
w1.Break(new Pillow());
w2.Break(new Hammer());
w2.Break(new Pillow());

and now perhaps four different things happen depending on the runtime types.

This sort of double dispatch operation is very common in things like games, where you want to have different logic for every possible kind of collision: player with laser, laser with laser, laser with player, player with wall, laser with wall...

Languages that have this property are called "double dispatch" languages; languages that can do more than double dispatch are said to be "multiple dispatch".

This is a pretty well-studied area; do a web search on "visitor pattern" to learn more about simulating double dispatch in a single dispatch language.

Only one looping construct

A loop can look like one of the following:

Infinite loop

for {
}

While loop

for <conditional> {
}

Traditional for loop

for i := 0; i < 10; i++ {
}

Foreach loop

// works for maps or arrays
for k, v := range arr {
}

Multi-purpose switch

switch {
    // cases must be evaluate to a boolean
}

switch <value> {
}

switch t := <value>; t {
    // can use t inside
}

Multiple return

return val1, val2, ...

Removes the need for throw (pass the error as last return value)
Removes the need for out parameters
Removes the need for tuples

Interfaces

type X interface {
    DoSomething()
    String() string
}

Solves similar problems as generics
Allows abstraction

Embedding

type A struct {
    Thing string
}

type B struct {
    A // embeds A in B, so B.Thing refers to A.Thing
}

Solves same problem as inheritance
Obviates need for classes

Channels

Can be used to implement semaphores

var c = make(chan bool, 1)
c<-true // semaphore lock
<-c // semaphore free

Used for message passing between threads

func produce(c chan<- bool) {
    for {
        c <- true
    }
}
func consume(c <-chan bool) {
    for {
        <-c
    }
}

var c = make(chan bool)
go produce(c)
go consume(c)

Can be used to handle asynchronous events

func async() chan bool {
    var c = make(chan bool)
    go doSomethingAsync(c)
    return c
}

// wait for long async process to finish
c := async()
select {
    case _ = <-c:
}

Conclusion

I'm not going to go into every part of the syntax, but hopefully you can see what minimalism can do. The language is intriguing not because it adds a ton of new features, but because it uses the best features from other languages without anything extra.

There's usually one "best" way of solving a problem. For example, on the mailing list, a lot of users complain about not having generics. After discussion, they realize that everything they want to do can be done with interfaces. Read up on effective go for examples on idiomatic syntax.

The benefit of KISS languages is it's possible to write idiomatic code, because code style is restricted by the language. For example, in Go, you cannot write something like this:

if <condition>
    statement;

You have to use curly-braces:

if <condition> {
    statement;
}

There are many other examples of this in the syntax, which makes reading other peoples code easier.

Benefits of KISS language over featureful languages:

easier to understand others' code
easier to grok the entire language (C++ is notorious for being hard to understand)
focus on algorithm, not the syntax

Programming Languages – Does This Kind of Language Exist?

You may want to look at Julia.

It's a modern, dynamically typed language with Lisp inspired meta programming. It also JIT compiles using LLVM. The standard library is written in Julia too and is compiled and cached on first use I.e. A form of install time AOT compilation. As the LLVM IR is statically typed, I think this has most of the features you were looking for although, as with many dynamic languages, REPL usage was an important consideration hence the JIT compilation.

One interesting paper I saw (section 5.2). The standard library has around 135k variables of which about 80k had a fixed, static type. The rest had to stay represented as the variant type Any.

Depending on why you're interested in dynamic to static, this may be of value when you look at how dynamic you make your language. Obviously, this has some bearing on performance although, in practice, Julia seems quite quick.