Closed apblack closed 7 years ago
I opened issue #101 for the above-mentioned outstanding problem.
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
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).
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).
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.
I've removed Singleton types from the spec in commit 7bae9d22d.
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:If we add to Singleton another attribute
then a single request on
Singleton.new
can generate a unique singleton object and its type.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, becauseUnused
could be overridden.