Ahnfelt / funk

PROTOTYPE: A minimal scripting language - OOP via lambda functions and pattern matching
53 stars 2 forks source link

Sending messages to self #2

Closed edcrypt closed 7 years ago

edcrypt commented 7 years ago

Currently the only way I found to send messages to self is like this:

:newDog {| barkPhrase | {
    | Bark | system.Log(barkPhrase)
}}

:newChiwawa {
    :parent newDog("yip!")
    :self {
        | Yap | self.Bark
        | m | parent(m)
    }
    self
}

:aDog newDog("woof!")

:myChiwawa newChiwawa()

aDog.Bark
myChiwawa.Yap

Should Funk define a "self_" function on the prelude?

Ahnfelt commented 7 years ago

Possibly - as an experiment in syntax, you can now write:

:newChiwawa {
    :parent newDog("yip!")
    :self {
        | Yap | self.Bark
        | m | parent(m)
    }
}

Omitting the final self. What do you think of it?

edcrypt commented 7 years ago

Yes, having attributions return their right side would be useful in other contexts too I guess.

In this case my lazy ass would prefer being able to omit self entirely like in Self Language. What would happen if starting an expression with Caps meant sending the message to the current object?

Ahnfelt commented 7 years ago

I don't think caps could work. Consider this example:

:newChiwawa {
    :parent newDog("yip!")
    {
        | Yap | when (day == Monday) { Bark }
        | m | parent(m)
    }
}

The intention here is obviously that Bark is an argument to the outer function - but syntactically it'd have to be the inner function (the one that's at the last argument of when). And since lambda functions are used for control structures, you're bound to encounter this problem all the time.

In the original Funk from 2008, you could mark the "self object" with :@ and then refer to it as @:

:newChiwawa {
    :parent newDog("yip!")
    {:@
        | Yap | when (day == Monday) { @Bark }
        | m | parent(m)
    }
}

But I think that syntax is way too arcane. Removing the :@ marker would lead to the problem above of which function is the "self object".

Requiring the programmer to name the "self object" as is the case now has a benefit: if you have nested "self objects", they don't have to fight over who gets to be called "self".

edcrypt commented 7 years ago

Right. I clearly Didn't Think This Through. I think your solution to omit the final self is enough.