typedef-like like syntax for strong typing keys

On Thu, Dec 31, 2009 at 09:54:41AM -0800, Josh Stratton wrote:
> I basically wanted to use ints as typesafe keys so one key would never
> be allowed to index another list. I give an example in the link. This
> feature is certainly not necessary [...]

I think it is necessary. It's clearly doable. We should do it.
Allowing user subtyping of AnyVal is a superficially appealing source
level model, but it would break code which assumes an AnyVal can only
represent nine types (especially since AnyVal is now sealed.) If we did
think that would be a good approach, we should unseal AnyVal.

Ignoring compatibility constraints for a second, I'd be more inclined to
shake up the inheritance hierarchy because frankly AnyVal is pretty
useless. There are subsets of AnyVal which could very usefully share a
common parent: Byte/Short/Int/Long, those + Float/Double, those + Char.
Maybe also Double/Long, Int/Float, Short/Char, although that's probably
not that useful in practice, especially because the JVM doesn't even
implement subrange types.

But there's no way to consume numeric types without having to take on
Boolean and Unit. Hello Boolean, you are not a number. Get your own
parent. And Unit? Don't even talk to me, Unit! You're dead to me!

Unit is Nothing to me

-----Original Message-----
From: Paul Phillips [mailto:paulp@improving.org]
Sent: Thursday, December 31, 2009 1:18 PM
To: Josh Stratton
Cc: scala-internals@listes.epfl.ch
Subject: Re: [scala-internals] typedef-like like syntax for strong typing keys

On Thu, Dec 31, 2009 at 09:54:41AM -0800, Josh Stratton wrote:
> I basically wanted to use ints as typesafe keys so one key would never
> be allowed to index another list. I give an example in the link. This
> feature is certainly not necessary [...]

I think it is necessary. It's clearly doable. We should do it.
Allowing user subtyping of AnyVal is a superficially appealing source
level model, but it would break code which assumes an AnyVal can only
represent nine types (especially since AnyVal is now sealed.) If we did
think that would be a good approach, we should unseal AnyVal.

Ignoring compatibility constraints for a second, I'd be more inclined to
shake up the inheritance hierarchy because frankly AnyVal is pretty
useless. There are subsets of AnyVal which could very usefully share a
common parent: Byte/Short/Int/Long, those + Float/Double, those + Char.
Maybe also Double/Long, Int/Float, Short/Char, although that's probably
not that useful in practice, especially because the JVM doesn't even
implement subrange types.

But there's no way to consume numeric types without having to take on
Boolean and Unit. Hello Boolean, you are not a number. Get your own
parent. And Unit? Don't even talk to me, Unit! You're dead to me!

--
Paul Phillips | We act as though comfort and luxury were the chief
Imperfectionist | requirements of life, when all that we need to make us
Empiricist | really happy is something to be enthusiastic about.
up hill, pi pals! | -- Charles Kingsley

This e-mail message (including any attachments) is for the sole use of
the intended recipient(s) and may contain confidential and privileged
information. If the reader of this message is not the intended
recipient, you are hereby notified that any dissemination, distribution
or copying of this message (including any attachments) is strictly
prohibited.

If you have received this message in error, please contact
the sender by reply e-mail message and destroy all copies of the
original message (including attachments).

It always seemed to me that subclassing AnyVal would be the natural way to declare CLR ‘struct’ types in the .NET port of the language, e.g.:

class SomeStruct extends AnyVal {
    // blah fields
}

would equate to the C# code:

struct SomeStruct {
    // blah fields
}

It’s elegant; it’s logical… but it would require unsealing AnyVal! (At the very least, struct types declared in external code should be represented as AnyVal subclasses.)
–Andrew

On 31 Dec 2009, at 18:17, Paul Phillips wrote:

On Thu, Dec 31, 2009 at 09:54:41AM -0800, Josh Stratton wrote:

I basically wanted to use ints as typesafe keys so one key would never

be allowed to index another list.  I give an example in the link. This

feature is certainly not necessary [...]

I think it is necessary.  It's clearly doable.  We should do it.  
Allowing user subtyping of AnyVal is a superficially appealing source
level model, but it would break code which assumes an AnyVal can only
represent nine types (especially since AnyVal is now sealed.) If we did
think that would be a good approach, we should unseal AnyVal.

Ignoring compatibility constraints for a second, I'd be more inclined to
shake up the inheritance hierarchy because frankly AnyVal is pretty
useless.  There are subsets of AnyVal which could very usefully share a
common parent: Byte/Short/Int/Long, those + Float/Double, those + Char.  
Maybe also Double/Long, Int/Float, Short/Char, although that's probably
not that useful in practice, especially because the JVM doesn't even
implement subrange types.

But there's no way to consume numeric types without having to take on
Boolean and Unit.  Hello Boolean, you are not a number.  Get your own
parent.  And Unit? Don't even talk to me, Unit! You're dead to me!

--
Paul Phillips      | We act as though comfort and luxury were the chief
Imperfectionist    | requirements of life, when all that we need to make us
Empiricist         | really happy is something to be enthusiastic about.
up hill, pi pals!  |     -- Charles Kingsley

It would be simpler to make an abstract class Struct extends AnyVal. Then AnyVal can continue to be sealed, and you extend Struct instead of AnyVal, which is rather more elegant, imho.

On Tue, Jan 5, 2010 at 7:30 PM, Andrew Forrest <andrew@dysphoria.net> wrote:

It always seemed to me that subclassing AnyVal would be the natural way to declare CLR ‘struct’ types in the .NET port of the language, e.g.:

class SomeStruct extends AnyVal {
    // blah fields
}

would equate to the C# code:

struct SomeStruct {
    // blah fields
}

It’s elegant; it’s logical… but it would require unsealing AnyVal! (At the very least, struct types declared in external code should be represented as AnyVal subclasses.)
–Andrew

On 31 Dec 2009, at 18:17, Paul Phillips wrote:

On Thu, Dec 31, 2009 at 09:54:41AM -0800, Josh Stratton wrote:

I basically wanted to use ints as typesafe keys so one key would never

be allowed to index another list.  I give an example in the link. This

feature is certainly not necessary [...]

I think it is necessary.  It's clearly doable.  We should do it.  
Allowing user subtyping of AnyVal is a superficially appealing source
level model, but it would break code which assumes an AnyVal can only
represent nine types (especially since AnyVal is now sealed.) If we did
think that would be a good approach, we should unseal AnyVal.

Ignoring compatibility constraints for a second, I'd be more inclined to
shake up the inheritance hierarchy because frankly AnyVal is pretty
useless.  There are subsets of AnyVal which could very usefully share a
common parent: Byte/Short/Int/Long, those + Float/Double, those + Char.  
Maybe also Double/Long, Int/Float, Short/Char, although that's probably
not that useful in practice, especially because the JVM doesn't even
implement subrange types.

But there's no way to consume numeric types without having to take on
Boolean and Unit.  Hello Boolean, you are not a number.  Get your own
parent.  And Unit? Don't even talk to me, Unit! You're dead to me!

--
Paul Phillips      | We act as though comfort and luxury were the chief
Imperfectionist    | requirements of life, when all that we need to make us
Empiricist         | really happy is something to be enthusiastic about.
up hill, pi pals!  |     -- Charles Kingsley

--
Daniel C. Sobral

I travel to the future all the time.

Has the status of this changed much since Scala 2.7? Any plans of
this coming down the pipeline?

On Tue, Jan 5, 2010 at 2:59 PM, Daniel Sobral wrote:
> It would be simpler to make an abstract class Struct extends AnyVal. Then
> AnyVal can continue to be sealed, and you extend Struct instead of AnyVal,
> which is rather more elegant, imho.
>
> On Tue, Jan 5, 2010 at 7:30 PM, Andrew Forrest wrote:
>>
>> It always seemed to me that subclassing AnyVal would be the natural way to
>> declare CLR ‘struct’ types in the .NET port of the language, e.g.:
>>
>> class SomeStruct extends AnyVal {
>>     // blah fields
>> }
>>
>> would equate to the C# code:
>>
>> struct SomeStruct {
>>     // blah fields
>> }
>>
>> It’s elegant; it’s logical… but it would require unsealing AnyVal! (At the
>> very least, struct types declared in external code should be represented as
>> AnyVal subclasses.)
>> –Andrew
>>
>> On 31 Dec 2009, at 18:17, Paul Phillips wrote:
>>
>> On Thu, Dec 31, 2009 at 09:54:41AM -0800, Josh Stratton wrote:
>>
>> I basically wanted to use ints as typesafe keys so one key would never
>>
>> be allowed to index another list.  I give an example in the link. This
>>
>> feature is certainly not necessary [...]
>>
>> I think it is necessary.  It's clearly doable.  We should do it.
>> Allowing user subtyping of AnyVal is a superficially appealing source
>> level model, but it would break code which assumes an AnyVal can only
>> represent nine types (especially since AnyVal is now sealed.) If we did
>> think that would be a good approach, we should unseal AnyVal.
>>
>> Ignoring compatibility constraints for a second, I'd be more inclined to
>> shake up the inheritance hierarchy because frankly AnyVal is pretty
>> useless.  There are subsets of AnyVal which could very usefully share a
>> common parent: Byte/Short/Int/Long, those + Float/Double, those + Char.
>> Maybe also Double/Long, Int/Float, Short/Char, although that's probably
>> not that useful in practice, especially because the JVM doesn't even
>> implement subrange types.
>>
>> But there's no way to consume numeric types without having to take on
>> Boolean and Unit.  Hello Boolean, you are not a number.  Get your own
>> parent.  And Unit? Don't even talk to me, Unit! You're dead to me!
>>
>> --
>> Paul Phillips      | We act as though comfort and luxury were the chief
>> Imperfectionist    | requirements of life, when all that we need to make
>> us
>> Empiricist         | really happy is something to be enthusiastic about.
>> up hill, pi pals!  |     -- Charles Kingsley
>>
>
>
>
> --
> Daniel C. Sobral
>
> I travel to the future all the time.
>