Comments on: Type safety and singletons http://existentialtype.net/2008/01/25/type-safety-and-singletons/ For People Who Like Type and Types Tue, 06 Jan 2009 03:29:44 +0000 http://wordpress.org/?v=2.7 hourly 1 By: washburn http://existentialtype.net/2008/01/25/type-safety-and-singletons/comment-page-1/#comment-21355 washburn Sun, 27 Jan 2008 15:16:52 +0000 http://existentialtype.net/2008/01/25/type-safety-and-singletons/#comment-21355 @Andrew: Thanks, I'll check that out and see if there is something useful in that work. @Andrew: Thanks, I’ll check that out and see if there is something useful in that work.

]]> By: Andrew http://existentialtype.net/2008/01/25/type-safety-and-singletons/comment-page-1/#comment-21325 Andrew Sat, 26 Jan 2008 02:04:35 +0000 http://existentialtype.net/2008/01/25/type-safety-and-singletons/#comment-21325 That also reminds me of dot notation. Though I don't remember how people usually avoid that problem there. That also reminds me of dot notation. Though I don’t remember how people usually avoid that problem there.

]]> By: washburn http://existentialtype.net/2008/01/25/type-safety-and-singletons/comment-page-1/#comment-21323 washburn Fri, 25 Jan 2008 15:52:08 +0000 http://existentialtype.net/2008/01/25/type-safety-and-singletons/#comment-21323 @Dan: Featherweight Scala does not presently have a notion of type equality, it just has type subsumption. I would hope that type equivalence can be defined in terms of type subsumption, but it would be a good idea to verify that it will truly form an equivalence relation. As for singletons inducing equalities, I would assume you mean "are there type subsumption rules concerning singletons"? Yes, there are two rules and they are quite similar to the ones that can be found in section 2.2 of "A Type System for Higher-Order Modules". The rules I am using currently can be found in some <a href="http://lamp.epfl.ch/teaching/foundations_of_software/docs/week13.pdf" rel="nofollow">slides</a> from a lecture Martin recently gave. In any event, I believe I have found a solution based upon how singletons were handled in the νObj calculus. However, it will require changing the operational semantics from what is given in the paper <a href="http://infoscience.epfl.ch/search?recid=95716&ln=en" rel="nofollow">A Core Calculus for Scala Type Checking</a>. @Dan: Featherweight Scala does not presently have a notion of type equality, it just has type subsumption. I would hope that type equivalence can be defined in terms of type subsumption, but it would be a good idea to verify that it will truly form an equivalence relation.

As for singletons inducing equalities, I would assume you mean “are there type subsumption rules concerning singletons”? Yes, there are two rules and they are quite similar to the ones that can be found in section 2.2 of “A Type System for Higher-Order Modules”. The rules I am using currently can be found in some slides from a lecture Martin recently gave.

In any event, I believe I have found a solution based upon how singletons were handled in the νObj calculus. However, it will require changing the operational semantics from what is given in the paper A Core Calculus for Scala Type Checking.

]]> By: Dan Licata http://existentialtype.net/2008/01/25/type-safety-and-singletons/comment-page-1/#comment-21322 Dan Licata Fri, 25 Jan 2008 15:42:30 +0000 http://existentialtype.net/2008/01/25/type-safety-and-singletons/#comment-21322 Hi Geoff, I haven't looked at the path-dependent types in Scala, but here's what happens with singletons in ML: the problem isn't so much the singleton introduction rule at the constructor level, but the elimination rule, which induces an equality (see Stone-Harper for details). The reason is that you then have a non-syntax-directed constructor equality (notated C1 = C2 :: K), with a rule that says equal constructors are equal classifiers: M : A A = B :: type ---------------------- M : B This rule is a problem for type safety because now all of your inversion and canonical forms lemmas go out the window. About 2/3s of the Twelf formalization of the SML IL is devoted to solving this problem; i.e., to proving that int isn't equal to bool. The way you do this is to give an alternate algorithmic version of equality for which the necessary inversions are obvious. An alternative is to define equality algorithmically to begin with, but then you often need to show that most of the declarative rules (e.g. transitivity) are admissible for your proofs anyway. How does type equality work in Scala? Does a singleton induce an equality? Hi Geoff,
I haven’t looked at the path-dependent types in Scala, but here’s what happens with singletons in ML: the problem isn’t so much the singleton introduction rule at the constructor level, but the elimination rule, which induces an equality (see Stone-Harper for details). The reason is that you then have a non-syntax-directed constructor equality (notated C1 = C2 :: K), with a rule that says equal constructors are equal classifiers:

M : A A = B :: type
———————-
M : B

This rule is a problem for type safety because now all of your inversion and canonical forms lemmas go out the window. About 2/3s of the Twelf formalization of the SML IL is devoted to solving this problem; i.e., to proving that int isn’t equal to bool. The way you do this is to give an alternate algorithmic version of equality for which the necessary inversions are obvious. An alternative is to define equality algorithmically to begin with, but then you often need to show that most of the declarative rules (e.g. transitivity) are admissible for your proofs anyway.

How does type equality work in Scala? Does a singleton induce an equality?

]]>