Re: Re: public kotlin demo

W dniu 12.01.2012 11:19, √iktor Ҡlang pisze:
>
>
> 2012/1/12 Piotr Kołaczkowski
> >
>
> W dniu 12.01.2012 10:52, √iktor Ҡlang pisze:
>
>
>
> 2012/1/12 Piotr Kołaczkowski
>
> >>
>
>
> W dniu 11.01.2012 13:16, Daniel Sobral pisze:
>
> On Wed, Jan 11, 2012 at 05:07, Simon Ochsenreither
>
> >>
>
> wrote:
>
> Exactly. They promised "reified generics", but they
> delivered some thinly
> disguised, prettified instanceOf test.
>
> What a shame. I was already excited to see how they have
> solved the millions
> of problems around reified generics vs.
>
> overloading/overriding/____inheritance/assignment-____compatibility
>
> on the JVM.
>
>
> This is an expectation I truly don't understand. I can't
> conceive of a
> way to reify generics without adding a whole layer
> between JVM
> and the
> generated code -- such as creating classes on demand.
> So, when
> people
> say they are going to have "reified generics", I always
> assume
> erasure
> + automatic manifests.
>
> I remember a recent question on Stack Overflow that used
> Kotlin and
> Ceylon as proof that reification was possible -- before
> either
> one was
> available. So, Ceylon was released without reification, and
> Kotlin has
> automatic manifests.
>
>
> Anyway, instead of bashing imperfect solutions in the other
> languages, maybe let's learn something and improve Manifests in
> Scala slightly?
> I mean, in Scala, I can't even check x.isInstanceOf[List[Int]]
> reliably, even if I do have all the runtime type info for x
> thanks
> to Manifest. A prettified instanceOf test would be still nice
> addition, IMHO.
>
>
> That means that you need to create and store 1 manifest per node
> in the
> List. Effectively adding a ton of memory usage.
>
>
> 1. It is one *pointer* per node more, I can't see why you imply all
> the nodes should allocate different Manifest objects.
>
>
> The extra pointer will make lists 50% fatter.

No need to store the pointer in the nodes.

> Also, either you need to
> cache all manifests in a global cache == String.intern()-hell all over
> again, or you need to create a new manifest per Node.
>
>
> 2. I don't know how lists are implemented internally, but keeping
> the Manifest in some kind of a wrapper object, instead of the list
> nodes, could be probably done. If not, why?
>
>
> How could you do that?
>
> val l1 = List(1)
> val l2 = 1 :: l1
> val l3 = l1 ::: l2

Three manifests. One for l1, one for l2 and one for l3.
But the List would have to be implemented by something like that:

class List[T](...) {
val manifest: Manifest[T] // one manifest per list
val head: ListNode[T] // no manifest pointers referenced from here
...
}

>
> How many manifests and where are they located?
> Also, you need to handle covariance, so:
>
> val l4 = "foo" :: l1
>
> Means that it has to have Manifest[Any], so cannot "reuse" l1's manifest.

Yes. But why do you insist it should reuse l1's manifest? The ::
operator can get an new implicit manifest for the type it returns and
put that into the returned List object.

>
>
> 3. Make that optional.
>
>
> So how would I know if the list has this feature?

Different type?

for any container, let the compiler transform instanceof List to List.head instanceof Int. false if the list is empty. never store null in list. problem solved.

def x(y:List[Int])
def x(z:List[String])

make compiler rename methods based on type parameters in secret:
def x_Int(y:List[Int])
def x_String(z:List[String])

overloading problem solved. new java interop problem introduced. new reflection problem introduced.

-------- Original-Nachricht --------
> Datum: Thu, 12 Jan 2012 11:39:21 +0100
> Von: "Piotr Kołaczkowski"
> An: scala-user@googlegroups.com
> Betreff: [scala-user] Re: public kotlin demo

> W dniu 12.01.2012 11:19, √iktor Ҡlang pisze:
> >
> >
> > 2012/1/12 Piotr Kołaczkowski
> > > >
> >
> > W dniu 12.01.2012 10:52, √iktor Ҡlang pisze:
> >
> >
> >
> > 2012/1/12 Piotr Kołaczkowski
> > >
> > > >>
> >
> >
> > W dniu 11.01.2012 13:16, Daniel Sobral pisze:
> >
> > On Wed, Jan 11, 2012 at 05:07, Simon Ochsenreither
> >
> > > >>
> >
> > wrote:
> >
> > Exactly. They promised "reified generics", but they
> > delivered some thinly
> > disguised, prettified instanceOf test.
> >
> > What a shame. I was already excited to see how they
> have
> > solved the millions
> > of problems around reified generics vs.
> >
> >
> overloading/overriding/____inheritance/assignment-____compatibility
> >
> > on the JVM.
> >
> >
> > This is an expectation I truly don't understand. I can't
> > conceive of a
> > way to reify generics without adding a whole layer
> > between JVM
> > and the
> > generated code -- such as creating classes on demand.
> > So, when
> > people
> > say they are going to have "reified generics", I always
> > assume
> > erasure
> > + automatic manifests.
> >
> > I remember a recent question on Stack Overflow that used
> > Kotlin and
> > Ceylon as proof that reification was possible -- before
> > either
> > one was
> > available. So, Ceylon was released without reification,
> and
> > Kotlin has
> > automatic manifests.
> >
> >
> > Anyway, instead of bashing imperfect solutions in the other
> > languages, maybe let's learn something and improve Manifests
> in
> > Scala slightly?
> > I mean, in Scala, I can't even check
> x.isInstanceOf[List[Int]]
> > reliably, even if I do have all the runtime type info for x
> > thanks
> > to Manifest. A prettified instanceOf test would be still
> nice
> > addition, IMHO.
> >
> >
> > That means that you need to create and store 1 manifest per node
> > in the
> > List. Effectively adding a ton of memory usage.
> >
> >
> > 1. It is one *pointer* per node more, I can't see why you imply all
> > the nodes should allocate different Manifest objects.
> >
> >
> > The extra pointer will make lists 50% fatter.
>
> No need to store the pointer in the nodes.
>
> > Also, either you need to
> > cache all manifests in a global cache == String.intern()-hell all over
> > again, or you need to create a new manifest per Node.
> >
> >
> > 2. I don't know how lists are implemented internally, but keeping
> > the Manifest in some kind of a wrapper object, instead of the list
> > nodes, could be probably done. If not, why?
> >
> >
> > How could you do that?
> >
> > val l1 = List(1)
> > val l2 = 1 :: l1
> > val l3 = l1 ::: l2
>
>
> Three manifests. One for l1, one for l2 and one for l3.
> But the List would have to be implemented by something like that:
>
> class List[T](...) {
> val manifest: Manifest[T] // one manifest per list
> val head: ListNode[T] // no manifest pointers referenced from here
> ...
> }
>
>
> >
> > How many manifests and where are they located?
> > Also, you need to handle covariance, so:
> >
> > val l4 = "foo" :: l1
> >
> > Means that it has to have Manifest[Any], so cannot "reuse" l1's
> manifest.
>
> Yes. But why do you insist it should reuse l1's manifest? The ::
> operator can get an new implicit manifest for the type it returns and
> put that into the returned List object.
>
> >
> >
> > 3. Make that optional.
> >
> >
> > So how would I know if the list has this feature?
>
> Different type?
>
>

On Thu, Jan 12, 2012 at 11:51 AM, Dennis Haupt <h-star@gmx.de> wrote:

for any container, let the compiler transform instanceof List<Int> to List.head instanceof Int. false if the list is empty. never store null in list. problem solved.

List[List[Int]]
 

def x(y:List[Int])
def x(z:List[String])

make compiler rename methods based on type parameters in secret:
def x_Int(y:List[Int])
def x_String(z:List[String])

overloading problem solved. new java interop problem introduced. new reflection problem introduced.


-------- Original-Nachricht --------
> Datum: Thu, 12 Jan 2012 11:39:21 +0100
> Von: "Piotr Kołaczkowski" <pkolaczk@elka.pw.edu.pl>
> An: scala-user@googlegroups.com
> Betreff: [scala-user] Re: public kotlin demo

> W dniu 12.01.2012 11:19, √iktor Ҡlang pisze:
> >
> >
> > 2012/1/12 Piotr Kołaczkowski
> > <pkolaczk@elka.pw.edu.pl
> > <mailto:pkolaczk@elka.pw.edu.pl>>
> >
> >     W dniu 12.01.2012 10:52, √iktor Ҡlang pisze:
> >
> >
> >
> >         2012/1/12 Piotr Kołaczkowski
> >         <pkolaczk@elka.pw.edu.pl
> >         <mailto:pkolaczk@elka.pw.edu.pl>
> >         <mailto:pkolaczk [at] elka [dot] pw [dot] edu." rel="nofollow">pkolaczk@elka.pw.edu.__pl
> >         <mailto:pkolaczk@elka.pw.edu.pl>>>
> >
> >
> >             W dniu 11.01.2012 13:16, Daniel Sobral pisze:
> >
> >                 On Wed, Jan 11, 2012 at 05:07, Simon Ochsenreither
> >         <simon.ochsenreither@__googlem__ail.com <http://googlemail.com>
> >         <mailto:simon.ochsenreither@__googlemail.com
> >         <mailto:simon.ochsenreither@googlemail.com>>>
> >
> >                   wrote:
> >
> >                     Exactly. They promised "reified generics", but they
> >                     delivered some thinly
> >                     disguised, prettified instanceOf test.
> >
> >                     What a shame. I was already excited to see how they
> have
> >                     solved the millions
> >                     of problems around reified generics vs.
> >
> >
> overloading/overriding/____inheritance/assignment-____compatibility
> >
> >                     on the JVM.
> >
> >
> >                 This is an expectation I truly don't understand. I can't
> >                 conceive of a
> >                 way to reify generics without adding a whole layer
> >         between JVM
> >                 and the
> >                 generated code -- such as creating classes on demand.
> >         So, when
> >                 people
> >                 say they are going to have "reified generics", I always
> >         assume
> >                 erasure
> >                 + automatic manifests.
> >
> >                 I remember a recent question on Stack Overflow that used
> >         Kotlin and
> >                 Ceylon as proof that reification was possible -- before
> >         either
> >                 one was
> >                 available. So, Ceylon was released without reification,
> and
> >                 Kotlin has
> >                 automatic manifests.
> >
> >
> >             Anyway, instead of bashing imperfect solutions in the other
> >             languages, maybe let's learn something and improve Manifests
> in
> >             Scala slightly?
> >             I mean, in Scala, I can't even check
> x.isInstanceOf[List[Int]]
> >             reliably, even if I do have all the runtime type info for x
> >         thanks
> >             to Manifest. A prettified instanceOf test would be still
> nice
> >             addition, IMHO.
> >
> >
> >         That means that you need to create and store 1 manifest per node
> >         in the
> >         List. Effectively adding a ton of memory usage.
> >
> >
> >     1. It is one *pointer* per node more, I can't see why you imply all
> >     the nodes should allocate different Manifest objects.
> >
> >
> > The extra pointer will make lists 50% fatter.
>
> No need to store the pointer in the nodes.
>
> > Also, either you need to
> > cache all manifests in a global cache == String.intern()-hell all over
> > again, or you need to create a new manifest per Node.
> >
> >
> >     2. I don't know how lists are implemented internally, but keeping
> >     the Manifest in some kind of a wrapper object, instead of the list
> >     nodes, could be probably done. If not, why?
> >
> >
> > How could you do that?
> >
> > val l1 = List(1)
> > val l2 = 1 :: l1
> > val l3 = l1 ::: l2
>
>
> Three manifests. One for l1, one for l2 and one for l3.
> But the List would have to be implemented by something like that:
>
> class List[T](...) {
>    val manifest: Manifest[T]  // one manifest per list
>    val head: ListNode[T]   // no manifest pointers referenced from here
>    ...
> }
>
>
> >
> > How many manifests and where are they located?
> > Also, you need to handle covariance, so:
> >
> > val l4 = "foo" :: l1
> >
> > Means that it has to have Manifest[Any], so cannot "reuse" l1's
> manifest.
>
> Yes. But why do you insist it should reuse l1's manifest? The ::
> operator can get an new implicit manifest for the type it returns and
> put that into the returned List object.
>
> >
> >
> >     3. Make that optional.
> >
> >
> > So how would I know if the list has this feature?
>
> Different type?
>
>

--
Viktor Klang

Akka Tech LeadTypesafe - The software stack for applications that scale

Twitter: @viktorklang

Future?

On Thu, Jan 12, 2012 at 6:06 AM, Francois <fanf42@gmail.com> wrote:

On 12/01/2012 12:01, √iktor Ҡlang wrote:

On Thu, Jan 12, 2012 at 11:51 AM, Dennis Haupt <h-star@gmx.de> wrote:

for any container, let the compiler transform instanceof List<Int> to List.head instanceof Int. false if the list is empty. never store null in list. problem solved.

List[List[Int]]

List.head.head !

-- 
Francois ARMAND
http://fanf42.blogspot.com
http://www.normation.com

On 12/01/2012 12:01, √iktor Ҡlang wrote:

CANPzfU86sX6NprF77Dqx7yQDcrhgNZwYf0tod7oqnSSuYY+Xcg [at] mail [dot] gmail [dot] com" type="cite">
On Thu, Jan 12, 2012 at 11:51 AM, Dennis Haupt <h-star [at] gmx [dot] de" rel="nofollow">h-star@gmx.de> wrote:

for any container, let the compiler transform instanceof List<Int> to List.head instanceof Int. false if the list is empty. never store null in list. problem solved.

List[List[Int]]

List.head.head !

-- 
Francois ARMAND
http://fanf42.blogspot.com
http://www.normation.com

List.empty[Int] ?

W dniu 12.01.2012 11:51, Dennis Haupt pisze:
> for any container, let the compiler transform instanceof List to List.head instanceof Int. false if the list is empty. never store null in list. problem solved.
>
> def x(y:List[Int])
> def x(z:List[String])
>
> make compiler rename methods based on type parameters in secret:
> def x_Int(y:List[Int])
> def x_String(z:List[String])
>
> overloading problem solved. new java interop problem introduced. new reflection problem introduced.
>
>
> -------- Original-Nachricht --------
>> Datum: Thu, 12 Jan 2012 11:39:21 +0100
>> Von: "Piotr Kołaczkowski"
>> An: scala-user@googlegroups.com
>> Betreff: [scala-user] Re: public kotlin demo
>
>> W dniu 12.01.2012 11:19, √iktor Ҡlang pisze:
>>>
>>>
>>> 2012/1/12 Piotr Kołaczkowski
>>> >> >
>>>
>>> W dniu 12.01.2012 10:52, √iktor Ҡlang pisze:
>>>
>>>
>>>
>>> 2012/1/12 Piotr Kołaczkowski
>>> >>
>>> >> >>
>>>
>>>
>>> W dniu 11.01.2012 13:16, Daniel Sobral pisze:
>>>
>>> On Wed, Jan 11, 2012 at 05:07, Simon Ochsenreither
>>>
>>> >> >>
>>>
>>> wrote:
>>>
>>> Exactly. They promised "reified generics", but they
>>> delivered some thinly
>>> disguised, prettified instanceOf test.
>>>
>>> What a shame. I was already excited to see how they
>> have
>>> solved the millions
>>> of problems around reified generics vs.
>>>
>>>
>> overloading/overriding/____inheritance/assignment-____compatibility
>>>
>>> on the JVM.
>>>
>>>
>>> This is an expectation I truly don't understand. I can't
>>> conceive of a
>>> way to reify generics without adding a whole layer
>>> between JVM
>>> and the
>>> generated code -- such as creating classes on demand.
>>> So, when
>>> people
>>> say they are going to have "reified generics", I always
>>> assume
>>> erasure
>>> + automatic manifests.
>>>
>>> I remember a recent question on Stack Overflow that used
>>> Kotlin and
>>> Ceylon as proof that reification was possible -- before
>>> either
>>> one was
>>> available. So, Ceylon was released without reification,
>> and
>>> Kotlin has
>>> automatic manifests.
>>>
>>>
>>> Anyway, instead of bashing imperfect solutions in the other
>>> languages, maybe let's learn something and improve Manifests
>> in
>>> Scala slightly?
>>> I mean, in Scala, I can't even check
>> x.isInstanceOf[List[Int]]
>>> reliably, even if I do have all the runtime type info for x
>>> thanks
>>> to Manifest. A prettified instanceOf test would be still
>> nice
>>> addition, IMHO.
>>>
>>>
>>> That means that you need to create and store 1 manifest per node
>>> in the
>>> List. Effectively adding a ton of memory usage.
>>>
>>>
>>> 1. It is one *pointer* per node more, I can't see why you imply all
>>> the nodes should allocate different Manifest objects.
>>>
>>>
>>> The extra pointer will make lists 50% fatter.
>>
>> No need to store the pointer in the nodes.
>>
>>> Also, either you need to
>>> cache all manifests in a global cache == String.intern()-hell all over
>>> again, or you need to create a new manifest per Node.
>>>
>>>
>>> 2. I don't know how lists are implemented internally, but keeping
>>> the Manifest in some kind of a wrapper object, instead of the list
>>> nodes, could be probably done. If not, why?
>>>
>>>
>>> How could you do that?
>>>
>>> val l1 = List(1)
>>> val l2 = 1 :: l1
>>> val l3 = l1 ::: l2
>>
>>
>> Three manifests. One for l1, one for l2 and one for l3.
>> But the List would have to be implemented by something like that:
>>
>> class List[T](...) {
>> val manifest: Manifest[T] // one manifest per list
>> val head: ListNode[T] // no manifest pointers referenced from here
>> ...
>> }
>>
>>
>>>
>>> How many manifests and where are they located?
>>> Also, you need to handle covariance, so:
>>>
>>> val l4 = "foo" :: l1
>>>
>>> Means that it has to have Manifest[Any], so cannot "reuse" l1's
>> manifest.
>>
>> Yes. But why do you insist it should reuse l1's manifest? The ::
>> operator can get an new implicit manifest for the type it returns and
>> put that into the returned List object.
>>
>>>
>>>
>>> 3. Make that optional.
>>>
>>>
>>> So how would I know if the list has this feature?
>>
>> Different type?
>>
>>
>

2012/1/12 √iktor Ҡlang :
> On Thu, Jan 12, 2012 at 11:51 AM, Dennis Haupt wrote:
>>
>> for any container, let the compiler transform instanceof List to
>> List.head instanceof Int. false if the list is empty. never store null in
>> list. problem solved.
>>
>
> List[List[Int]]

You should take a look at the Typeable type class in shapeless,

http://goo.gl/KE9tm

Cheers,

Miles

my ideas are almost never perfect, but can be implemented quickly and cover 85% of all cases. that is my strategy :)

in this case, the instanceof check should be done recursively. and one should ask wtf one is doing :)

-------- Original-Nachricht --------
> Datum: Thu, 12 Jan 2012 12:01:38 +0100
> Von: "√iktor Ҡlang"
> An: Dennis Haupt
> CC: "Piotr Kołaczkowski" , scala-user@googlegroups.com
> Betreff: Re: [scala-user] Re: public kotlin demo

> On Thu, Jan 12, 2012 at 11:51 AM, Dennis Haupt wrote:
>
> > for any container, let the compiler transform instanceof List to
> > List.head instanceof Int. false if the list is empty. never store null
> in
> > list. problem solved.
> >
> >
> List[List[Int]]
>
>
> > def x(y:List[Int])
> > def x(z:List[String])
> >
> > make compiler rename methods based on type parameters in secret:
> > def x_Int(y:List[Int])
> > def x_String(z:List[String])
> >
> > overloading problem solved. new java interop problem introduced. new
> > reflection problem introduced.
> >
> >
> > -------- Original-Nachricht --------
> > > Datum: Thu, 12 Jan 2012 11:39:21 +0100
> > > Von: "Piotr Kołaczkowski"
> > > An: scala-user@googlegroups.com
> > > Betreff: [scala-user] Re: public kotlin demo
> >
> > > W dniu 12.01.2012 11:19, √iktor Ҡlang pisze:
> > > >
> > > >
> > > > 2012/1/12 Piotr Kołaczkowski
> > > > > > > >
> > > >
> > > > W dniu 12.01.2012 10:52, √iktor Ҡlang pisze:
> > > >
> > > >
> > > >
> > > > 2012/1/12 Piotr Kołaczkowski
> > > > > > >
> > > > > > > >>
> > > >
> > > >
> > > > W dniu 11.01.2012 13:16, Daniel Sobral pisze:
> > > >
> > > > On Wed, Jan 11, 2012 at 05:07, Simon Ochsenreither
> > > > > >
> > > > > > > >>
> > > >
> > > > wrote:
> > > >
> > > > Exactly. They promised "reified generics", but
> they
> > > > delivered some thinly
> > > > disguised, prettified instanceOf test.
> > > >
> > > > What a shame. I was already excited to see how
> they
> > > have
> > > > solved the millions
> > > > of problems around reified generics vs.
> > > >
> > > >
> > > overloading/overriding/____inheritance/assignment-____compatibility
> > > >
> > > > on the JVM.
> > > >
> > > >
> > > > This is an expectation I truly don't understand. I
> > can't
> > > > conceive of a
> > > > way to reify generics without adding a whole layer
> > > > between JVM
> > > > and the
> > > > generated code -- such as creating classes on
> demand.
> > > > So, when
> > > > people
> > > > say they are going to have "reified generics", I
> always
> > > > assume
> > > > erasure
> > > > + automatic manifests.
> > > >
> > > > I remember a recent question on Stack Overflow that
> > used
> > > > Kotlin and
> > > > Ceylon as proof that reification was possible --
> before
> > > > either
> > > > one was
> > > > available. So, Ceylon was released without
> reification,
> > > and
> > > > Kotlin has
> > > > automatic manifests.
> > > >
> > > >
> > > > Anyway, instead of bashing imperfect solutions in the
> other
> > > > languages, maybe let's learn something and improve
> > Manifests
> > > in
> > > > Scala slightly?
> > > > I mean, in Scala, I can't even check
> > > x.isInstanceOf[List[Int]]
> > > > reliably, even if I do have all the runtime type info
> for x
> > > > thanks
> > > > to Manifest. A prettified instanceOf test would be still
> > > nice
> > > > addition, IMHO.
> > > >
> > > >
> > > > That means that you need to create and store 1 manifest per
> > node
> > > > in the
> > > > List. Effectively adding a ton of memory usage.
> > > >
> > > >
> > > > 1. It is one *pointer* per node more, I can't see why you imply
> all
> > > > the nodes should allocate different Manifest objects.
> > > >
> > > >
> > > > The extra pointer will make lists 50% fatter.
> > >
> > > No need to store the pointer in the nodes.
> > >
> > > > Also, either you need to
> > > > cache all manifests in a global cache == String.intern()-hell all
> over
> > > > again, or you need to create a new manifest per Node.
> > > >
> > > >
> > > > 2. I don't know how lists are implemented internally, but
> keeping
> > > > the Manifest in some kind of a wrapper object, instead of the
> list
> > > > nodes, could be probably done. If not, why?
> > > >
> > > >
> > > > How could you do that?
> > > >
> > > > val l1 = List(1)
> > > > val l2 = 1 :: l1
> > > > val l3 = l1 ::: l2
> > >
> > >
> > > Three manifests. One for l1, one for l2 and one for l3.
> > > But the List would have to be implemented by something like that:
> > >
> > > class List[T](...) {
> > > val manifest: Manifest[T] // one manifest per list
> > > val head: ListNode[T] // no manifest pointers referenced from
> here
> > > ...
> > > }
> > >
> > >
> > > >
> > > > How many manifests and where are they located?
> > > > Also, you need to handle covariance, so:
> > > >
> > > > val l4 = "foo" :: l1
> > > >
> > > > Means that it has to have Manifest[Any], so cannot "reuse" l1's
> > > manifest.
> > >
> > > Yes. But why do you insist it should reuse l1's manifest? The ::
> > > operator can get an new implicit manifest for the type it returns and
> > > put that into the returned List object.
> > >
> > > >
> > > >
> > > > 3. Make that optional.
> > > >
> > > >
> > > > So how would I know if the list has this feature?
> > >
> > > Different type?
> > >
> > >
> >
>
>
>

do you really want this:

if (a instanceof List[Int])
goLeftIgnoreTheList() else goRightIgnoreTheList()

?

-------- Original-Nachricht --------
> Datum: Thu, 12 Jan 2012 12:12:48 +0100
> Von: "Piotr Kołaczkowski"
> An: scala-user@googlegroups.com
> Betreff: [scala-user] Re: public kotlin demo

> List.empty[Int] ?
>
> W dniu 12.01.2012 11:51, Dennis Haupt pisze:
> > for any container, let the compiler transform instanceof List to
> List.head instanceof Int. false if the list is empty. never store null in
> list. problem solved.
> >
> > def x(y:List[Int])
> > def x(z:List[String])
> >
> > make compiler rename methods based on type parameters in secret:
> > def x_Int(y:List[Int])
> > def x_String(z:List[String])
> >
> > overloading problem solved. new java interop problem introduced. new
> reflection problem introduced.
> >
> >
> > -------- Original-Nachricht --------
> >> Datum: Thu, 12 Jan 2012 11:39:21 +0100
> >> Von: "Piotr Kołaczkowski"
> >> An: scala-user@googlegroups.com
> >> Betreff: [scala-user] Re: public kotlin demo
> >
> >> W dniu 12.01.2012 11:19, √iktor Ҡlang pisze:
> >>>
> >>>
> >>> 2012/1/12 Piotr Kołaczkowski
> >>> >>> >
> >>>
> >>> W dniu 12.01.2012 10:52, √iktor Ҡlang pisze:
> >>>
> >>>
> >>>
> >>> 2012/1/12 Piotr Kołaczkowski
> >>> >>>
> >>> >>> >>
> >>>
> >>>
> >>> W dniu 11.01.2012 13:16, Daniel Sobral pisze:
> >>>
> >>> On Wed, Jan 11, 2012 at 05:07, Simon Ochsenreither
> >>>
>
> >>> >>> >>
> >>>
> >>> wrote:
> >>>
> >>> Exactly. They promised "reified generics", but
> they
> >>> delivered some thinly
> >>> disguised, prettified instanceOf test.
> >>>
> >>> What a shame. I was already excited to see how
> they
> >> have
> >>> solved the millions
> >>> of problems around reified generics vs.
> >>>
> >>>
> >> overloading/overriding/____inheritance/assignment-____compatibility
> >>>
> >>> on the JVM.
> >>>
> >>>
> >>> This is an expectation I truly don't understand. I
> can't
> >>> conceive of a
> >>> way to reify generics without adding a whole layer
> >>> between JVM
> >>> and the
> >>> generated code -- such as creating classes on demand.
> >>> So, when
> >>> people
> >>> say they are going to have "reified generics", I
> always
> >>> assume
> >>> erasure
> >>> + automatic manifests.
> >>>
> >>> I remember a recent question on Stack Overflow that
> used
> >>> Kotlin and
> >>> Ceylon as proof that reification was possible --
> before
> >>> either
> >>> one was
> >>> available. So, Ceylon was released without
> reification,
> >> and
> >>> Kotlin has
> >>> automatic manifests.
> >>>
> >>>
> >>> Anyway, instead of bashing imperfect solutions in the
> other
> >>> languages, maybe let's learn something and improve
> Manifests
> >> in
> >>> Scala slightly?
> >>> I mean, in Scala, I can't even check
> >> x.isInstanceOf[List[Int]]
> >>> reliably, even if I do have all the runtime type info for
> x
> >>> thanks
> >>> to Manifest. A prettified instanceOf test would be still
> >> nice
> >>> addition, IMHO.
> >>>
> >>>
> >>> That means that you need to create and store 1 manifest per
> node
> >>> in the
> >>> List. Effectively adding a ton of memory usage.
> >>>
> >>>
> >>> 1. It is one *pointer* per node more, I can't see why you imply
> all
> >>> the nodes should allocate different Manifest objects.
> >>>
> >>>
> >>> The extra pointer will make lists 50% fatter.
> >>
> >> No need to store the pointer in the nodes.
> >>
> >>> Also, either you need to
> >>> cache all manifests in a global cache == String.intern()-hell all over
> >>> again, or you need to create a new manifest per Node.
> >>>
> >>>
> >>> 2. I don't know how lists are implemented internally, but keeping
> >>> the Manifest in some kind of a wrapper object, instead of the
> list
> >>> nodes, could be probably done. If not, why?
> >>>
> >>>
> >>> How could you do that?
> >>>
> >>> val l1 = List(1)
> >>> val l2 = 1 :: l1
> >>> val l3 = l1 ::: l2
> >>
> >>
> >> Three manifests. One for l1, one for l2 and one for l3.
> >> But the List would have to be implemented by something like that:
> >>
> >> class List[T](...) {
> >> val manifest: Manifest[T] // one manifest per list
> >> val head: ListNode[T] // no manifest pointers referenced from
> here
> >> ...
> >> }
> >>
> >>
> >>>
> >>> How many manifests and where are they located?
> >>> Also, you need to handle covariance, so:
> >>>
> >>> val l4 = "foo" :: l1
> >>>
> >>> Means that it has to have Manifest[Any], so cannot "reuse" l1's
> >> manifest.
> >>
> >> Yes. But why do you insist it should reuse l1's manifest? The ::
> >> operator can get an new implicit manifest for the type it returns and
> >> put that into the returned List object.
> >>
> >>>
> >>>
> >>> 3. Make that optional.
> >>>
> >>>
> >>> So how would I know if the list has this feature?
> >>
> >> Different type?
> >>
> >>
> >
>
>

This would at least double the amount of memory for List.

8 byte for the reference + the Manifest itself.

Double the memory! Sounds great to me.  I'll take two.

On Thu, Jan 12, 2012 at 9:12 AM, Simon Ochsenreither <simon.ochsenreither@googlemail.com> wrote:

This would at least double the amount of memory for List.

8 byte for the reference + the Manifest itself.

That simply isn't true.  Objects have overhead.  See my other post on the subject.

  --Rex

On Thu, Jan 12, 2012 at 9:12 AM, Simon Ochsenreither <simon.ochsenreither@googlemail.com> wrote:

This would at least double the amount of memory for List.

8 byte for the reference + the Manifest itself.

> for any container, let the compiler transform instanceof List to
> List.head instanceof Int. false if the list is empty. never store
> null in list. problem solved.

I sincerely hope that this was intended to be a joke.

W dniu 12.01.2012 13:21, Dennis Haupt pisze:
> do you really want this:
>
> if (a instanceof List[Int])
> goLeftIgnoreTheList() else goRightIgnoreTheList()
>
> ?

No, but someone might write x.isInstanceOf[Int], and for x = Nil it
should return true or false but *not throw*.

W dniu 12.01.2012 16:45, Piotr Kołaczkowski pisze:
> W dniu 12.01.2012 13:21, Dennis Haupt pisze:
>> do you really want this:
>>
>> if (a instanceof List[Int])
>> goLeftIgnoreTheList() else goRightIgnoreTheList()
>>
>> ?
>
> No, but someone might write x.isInstanceOf[Int], and for x = Nil it
> should return true or false but *not throw*.
>
>

Oops, I meant: x.isInstanceOf[List[Int]].

W dniu 12.01.2012 16:17, Rex Kerr pisze:
> That simply isn't true. Objects have overhead. See my other post on
> the subject.
>
> --Rex
>

Not only they have overhead, but there is also memory alignment. Java
rounds object sizes to at least 8 bytes. So if you are lucky, sometimes
adding a single field doesn't increase memory usage at all.

And, anyway, if Class objects are cached and shared, I really don't
understand why Manifest objects could not be cached and shared. They are
immutable, aren't they?

I have no idea what you mean with that. Care to explain? Maybe I'm missing something?

Thanks!

Am 12.01.2012 16:39, schrieb Lars Hupel:
>> for any container, let the compiler transform instanceof List to
>> List.head instanceof Int. false if the list is empty. never store
>> null in list. problem solved.
> I sincerely hope that this was intended to be a joke.
>
50/50. it would work in many cases, but it would be a hack.

On Thu, Jan 12, 2012 at 3:01 PM, HamsterofDeath <h-star@gmx.de> wrote:

Am 12.01.2012 16:39, schrieb Lars Hupel:
>> for any container, let the compiler transform instanceof List<Int> to
>> List.head instanceof Int. false if the list is empty. never store
>> null in list. problem solved.
> I sincerely hope that this was intended to be a joke.
>
50/50. it would work in many cases, but it would be a hack.

It would fail painfully and horribly in many cases.  So many that you may as well define instanceof to always return true.

val xs = List(Some(5), None)
xs instanceof List<Some<Int>>   // True

Argh!

  --Rex

Guys, typesafety is for the bees.  that's why in Scala 2.9 I make *everything* Dynamic.  This way, there *are* no types to check at runtime, we just rely on *real* explosions.  None of this pansy class-cast-exception junk.
val x: Dynamic = List(Some("x"), None)  // Look, mah, no handlebars!
The language is like 20% more awesome without any safety nags whatsover, compiler time or runtime.
- Josh
Note: I'm a huge fan of erasure.  It forces me to carry around specific types in my programs, catching more errors at compile time and limiting the "dangerous" areas of my program (i.e instanceOf checks).  Languages like Koitlin are unnerving, and the .NET CLR is stifling in its rigidity of sticking to C#'s type assumptions (variance/covariance/etc.).  In C++ we used to have to *make our own erasure* template<class T>
class Vector<T*> extends Vector<void*> {.... /*reinterpret_cast<FTW>*/...};
PLEASE don't send us back to that....
On Thu, Jan 12, 2012 at 3:16 PM, Rex Kerr <ichoran@gmail.com> wrote:

On Thu, Jan 12, 2012 at 3:01 PM, HamsterofDeath <h-star@gmx.de> wrote:

Am 12.01.2012 16:39, schrieb Lars Hupel:
>> for any container, let the compiler transform instanceof List<Int> to
>> List.head instanceof Int. false if the list is empty. never store
>> null in list. problem solved.
> I sincerely hope that this was intended to be a joke.
>
50/50. it would work in many cases, but it would be a hack.

It would fail painfully and horribly in many cases.  So many that you may as well define instanceof to always return true.

val xs = List(Some(5), None)
xs instanceof List<Some<Int>>   // True

Argh!

  --Rex

On Thu, Jan 12, 2012 at 9:28 PM, Josh Suereth <joshua.suereth@gmail.com> wrote:

Guys, typesafety is for the bees.  that's why in Scala 2.9 I make *everything* Dynamic.  This way, there *are* no types to check at runtime, we just rely on *real* explosions.  None of this pansy class-cast-exception junk.
val x: Dynamic = List(Some("x"), None)  // Look, mah, no handlebars!
The language is like 20% more awesome without any safety nags whatsover, compiler time or runtime.
- Josh
Note: I'm a huge fan of erasure.  It forces me to carry around specific types in my programs, catching more errors at compile time and limiting the "dangerous" areas of my program (i.e instanceOf checks).  Languages like Koitlin are unnerving, and the .NET CLR is stifling in its rigidity of sticking to C#'s type assumptions (variance/covariance/etc.).  In C++ we used to have to *make our own erasure* template<class T>
class Vector<T*> extends Vector<void*> {.... /*reinterpret_cast<FTW>*/...};
PLEASE don't send us back to that....

Josh, leave reinterpret_cast to the pro's.
LIKE A BAWS 

On Thu, Jan 12, 2012 at 3:16 PM, Rex Kerr <ichoran@gmail.com> wrote:

On Thu, Jan 12, 2012 at 3:01 PM, HamsterofDeath <h-star@gmx.de> wrote:

Am 12.01.2012 16:39, schrieb Lars Hupel:
>> for any container, let the compiler transform instanceof List<Int> to
>> List.head instanceof Int. false if the list is empty. never store
>> null in list. problem solved.
> I sincerely hope that this was intended to be a joke.
>
50/50. it would work in many cases, but it would be a hack.

It would fail painfully and horribly in many cases.  So many that you may as well define instanceof to always return true.

val xs = List(Some(5), None)
xs instanceof List<Some<Int>>   // True

Argh!

  --Rex

--
Viktor Klang

Akka Tech LeadTypesafe - The software stack for applications that scale

Twitter: @viktorklang

Am 12.01.2012 21:16, schrieb Rex Kerr:

g [at] mail [dot] gmail [dot] com" type="cite"> On Thu, Jan 12, 2012 at 3:01 PM, HamsterofDeath <h-star [at] gmx [dot] de" rel="nofollow">h-star@gmx.de> wrote:

Am 12.01.2012 16:39, schrieb Lars Hupel:
>> for any container, let the compiler transform instanceof List<Int> to
>> List.head instanceof Int. false if the list is empty. never store
>> null in list. problem solved.
> I sincerely hope that this was intended to be a joke.
>
50/50. it would work in many cases, but it would be a hack.

It would fail painfully and horribly in many cases.  So many that you may as well define instanceof to always return true.

val xs = List(Some(5), None)
xs instanceof List<Some<Int>>   // True

Argh!

  --Rex

actually, i don't see a problem in your example. but here's one:
List(None, Some(...)) instanceof List[...]

note that i said "never store null in a list" because i already had the none-case in mind. it also works only for lists that contain only the same type (without subtypes)
yes, the idea is crappy for non trivial cases. you would need to check the type of every element of the list. but it was never a serious suggestion.
here's a better one: rename "asInstanceOf" to "letsGetDangerous"

HamsterofDeath,

> val xs = List(Some(5), None)
> xs instanceof List> // True

this is evil, because xs is a List[Option[Int]], but the instanceof
says its a List[Some[Int]].

Regards,
Rüdiger

2012/1/12 HamsterofDeath :
> Am 12.01.2012 21:16, schrieb Rex Kerr:
>
> On Thu, Jan 12, 2012 at 3:01 PM, HamsterofDeath wrote:
>>
>> Am 12.01.2012 16:39, schrieb Lars Hupel:
>> >> for any container, let the compiler transform instanceof List to
>> >> List.head instanceof Int. false if the list is empty. never store
>> >> null in list. problem solved.
>> > I sincerely hope that this was intended to be a joke.
>> >
>> 50/50. it would work in many cases, but it would be a hack.
>>
>
> It would fail painfully and horribly in many cases.  So many that you may as
> well define instanceof to always return true.
>
> val xs = List(Some(5), None)
> xs instanceof List>   // True
>
> Argh!
>
>   --Rex
>
> actually, i don't see a problem in your example. but here's one:
> List(None, Some(...)) instanceof List[...]
>
> note that i said "never store null in a list" because i already had the
> none-case in mind. it also works only for lists that contain only the same
> type (without subtypes)
> yes, the idea is crappy for non trivial cases. you would need to check the
> type of every element of the list. but it was never a serious suggestion.
> here's a better one: rename "asInstanceOf" to "letsGetDangerous"
>
>

> 50/50. it would work in many cases, but it would be a hack.

I'm speaking out of experience. Back in my Java days, I wrote a
value-checking wrapper for method calls (basically precondition
checking). In the first version, we annotated the method parameters with
some sort of expression language, which worked reasonably well, but was
quite slow, as everything had to be called via reflection. Then we
switched to declaring "parameters" via a map where we would specify the
types as Strings. Now facing an additional type-checking problem, I
wrote a small set of classes which would examine objects of different
classes for their contents to determine whether the class (≠ type) is
correct. (It looked a bit like Miles' `Typeable`, although far less
extensive.) It worked, but it was wrong to do so --

note that the Java runtime doesn't care about generic parameters. An
`isInstanceOf` test however is precisely a runtime test. At runtime,
there is no `List[Int]` or `List[Float]`, that's why it doesn't make any
sense (to me) to check for it at runtime. Once you are aware of that,
try to reformulate. Runtime class-checking often indicates some wrong
design choices; if it requires generic tests, even more so.

If you totally need that, you should think about "super type tokens"
[1]. They might provide what one would expect. It is somehow similar to
`Manifest`s, but keeps the type information in the object (or rather in
its class). The downside is that it requires one class per type
constructor application.

[1]

if you never store None, there's no difference between option and some

-------- Original-Nachricht --------
> Datum: Fri, 13 Jan 2012 09:01:16 +0100
> Von: Ruediger Keller
> An: HamsterofDeath
> CC: scala-user@googlegroups.com
> Betreff: Re: [scala-user] Re: public kotlin demo

> HamsterofDeath,
>
> > val xs = List(Some(5), None)
> > xs instanceof List> // True
>
> this is evil, because xs is a List[Option[Int]], but the instanceof
> says its a List[Some[Int]].
>
> Regards,
> Rüdiger
>
>
> 2012/1/12 HamsterofDeath :
> > Am 12.01.2012 21:16, schrieb Rex Kerr:
> >
> > On Thu, Jan 12, 2012 at 3:01 PM, HamsterofDeath wrote:
> >>
> >> Am 12.01.2012 16:39, schrieb Lars Hupel:
> >> >> for any container, let the compiler transform instanceof List
> to
> >> >> List.head instanceof Int. false if the list is empty. never store
> >> >> null in list. problem solved.
> >> > I sincerely hope that this was intended to be a joke.
> >> >
> >> 50/50. it would work in many cases, but it would be a hack.
> >>
> >
> > It would fail painfully and horribly in many cases.  So many that you
> may as
> > well define instanceof to always return true.
> >
> > val xs = List(Some(5), None)
> > xs instanceof List>   // True
> >
> > Argh!
> >
> >   --Rex
> >
> > actually, i don't see a problem in your example. but here's one:
> > List(None, Some(...)) instanceof List[...]
> >
> > note that i said "never store null in a list" because i already had the
> > none-case in mind. it also works only for lists that contain only the
> same
> > type (without subtypes)
> > yes, the idea is crappy for non trivial cases. you would need to check
> the
> > type of every element of the list. but it was never a serious
> suggestion.
> > here's a better one: rename "asInstanceOf" to "letsGetDangerous"
> >
> >

W dniu 12.01.2012 20:10, Simon Ochsenreither pisze:
> I have no idea what you mean with that. Care to explain? Maybe I'm
> missing something?
>

Every Java object on a 32-bit machine has 8B overhead.

W dniu 13.01.2012 09:09, Lars Hupel pisze:
> note that the Java runtime doesn't care about generic parameters. An
> `isInstanceOf` test however is precisely a runtime test. At runtime,
> there is no `List[Int]` or `List[Float]`, that's why it doesn't make any
> sense (to me) to check for it at runtime

Going further in this direction, it doesn't make sense to explicitly
check *any* type at runtime. Oh, everything should statically
type-check, and all your programs do, don't they?

But my experience tells me sometimes there are places where one or two
instanceof checks followed by casts solve a problem, that otherwise
you'd have to solve by a huge refactoring. And sometimes you simply
don't have time to do it.

If the language supports instanceof[PutAnyTypeHere] or { case x:
PutAnyTypeHere => }, the best would be to make it work for all the
types. I know it is hard, and I know it probably can't be done
perfectly, given erasure, but e.g. making it work for some builtin
generic types like collections or at least some user-defined types (if
the user wishes to explicitly put the Manifest into the object) is a
good idea *IMHO*.

Anyway, do we really wish to debunk a new myth that "Ceylon has
reification while Scala doesn't" for the next 10 years? :D

On 2012-01-12 21:01, HamsterofDeath wrote:
> Am 12.01.2012 16:39, schrieb Lars Hupel:
>>> for any container, let the compiler transform instanceof List to
>>> List.head instanceof Int. false if the list is empty. never store
>>> null in list. problem solved.
>> I sincerely hope that this was intended to be a joke.
>>
> 50/50. it would work in many cases, but it would be a hack.

If it returns false for an empty list, it doesn't even work for the base
case. If you think it should return false for an empty list, you need to
rethink your use case because that's not how a List[+T] works.

Cheers,
Stefan