Singletons and Types

[apblack]

We were right to take Singleton types out of the spec: we don't need them to be there, because they can be in a library. But we do still need to resolve how to refer to types that are in objects.

Let me explain. Right now, minigrace defines Singleton like this:

def Singleton is public = object {
    class new {
        inherits BasicPattern.new
        method match(other) {
            if (self == other) then {
                SuccessfulMatch.new(other, [])
            } else {
                FailedMatch.new(other)
            }
        }
    }
    ...

If we add to Singleton another attribute

        type T = Pattern & ...

then a single request on Singleton.new can generate a unique singleton object and its type.

    def Unused = Singleton.new
    def Element = Binding | Unused.T

If we want each Singleton to have a unique type, then the ... will need to be a brand, or, equivalently, we make a magic trait generates a new method with a gensym'd name. That's not necessary for type safety, though.

The outstanding problem is that Unused.T isn't manifest, because Unused could be overridden.

[apblack]

I opened issue #101 for the above-mentioned outstanding problem.

[kjx]

If we can seal the singleton class - make it final - does the problem go away? I think the only issue is inside singleton, not outside

[apblack]

On 24th Jan 2017 @KimBruce wrote in email:

On the issue of what we should do about singleton types, we knew we couldn’t make decisions without [@kjx]. However, at this point I’m willing to abandon singleton types until we get the static type system straightened out and indeed see if we need them. I think right now there are relatively simple work-arounds, though quite frankly, I haven’t needed the singleton types at all (I have only one example that I’ve never used in teaching).

[apblack]

On 24th Jan 2017 @kjx responded via email:

I'm happy with all that; basically even if we wanted them they are a much lower priority. If you're happy with functional maybes, the main use-case isn't there (although they are odd in dynamic code).

[apblack]

Since we have "functional maybes" — in the module option — I'm declaring this issue resolved, at least for now: Singletons are no longer types. Note that singleton objects are still in standardGrace, and they can still be used as patterns, if desired.

[apblack]

I've removed Singleton types from the spec in commit 7bae9d22d.