This page is no longer maintained — Please continue to the home page at www.scala-lang.org

Re: planned type system enhancements

3 replies
H-star Development
Joined: 2010-04-14,
User offline. Last seen 2 years 26 weeks ago.

-------- Original-Nachricht --------
> Datum: Wed, 16 Nov 2011 15:21:41 +0100
> Von: "√iktor Ҡlang"
> An: Dennis Haupt
> CC: scala-debate [at] googlegroups [dot] com
> Betreff: Re: [scala-debate] planned type system enhancements

> On Wed, Nov 16, 2011 at 3:16 PM, Dennis Haupt wrote:
>
> >
> > -------- Original-Nachricht --------
> > > Datum: Wed, 16 Nov 2011 13:40:47 +0100
> > > Von: "√iktor Ҡlang"
> > > An: Dennis Haupt
> > > CC: scala-debate [at] googlegroups [dot] com
> > > Betreff: Re: [scala-debate] planned type system enhancements
> >
> > > On Wed, Nov 16, 2011 at 12:47 PM, Dennis Haupt wrote:
> > >
> > > > hi there,
> > > >
> > > > after 10+ years of using statically typed languages and not having a
> > > clue
> > > > why anyone would use dynamic types because all you get is code you
> > can't
> > > > maintain, i finally understood one big advantage of dynamic typing
> > > (thanks
> > > > to clojure which was an eye opener).
> > > >
> > > > in java, you force the caller of a method to use an instance of type
> X
> > -
> > > > even if you only need a small fraction of X's methods or fields. if
> you
> > > > have a big class that can do a lot or provides a lot of information,
> > > that
> > > > class will appear virtually anywhere even though only parts of it
> are
> > > > accessed.
> > > >
> > > > in clojure, instead of "i need type x" you say "i need something
> that
> > is
> > > > compatible to type x" where type x might never be explicily declared
> > and
> > > > only exists in the programmers mind and at runtime.
> > > >
> > > > scala has structural types for that, but clojure's destructuring is
> > more
> > > > powerful. it works on maps, arrays and classes and i won't have to
> > worry
> > > > about what is given to my function.
> > > >
> > > > the absense of a type system also makes things like
> > > > createmap(key, value, key2, value2... keyN, valueN) possible. no
> > > > typesystem i know of can be told to make sure the number of
> parameters
> > > is _
> > > > % 2 == 0. of course you can always cheat by using tuples
> > >
> > >
> > > You start out by saying that it cannot be done, and then you say that
> > it's
> > > cheating to do it?
> > > That's a nice one!
> > >
> > >
> > > > or method overloading for every possible parameter count up to 2*n
> but
> > > the
> > > > most simple solution in this case is to just skip the static types.
> > > >
> > >
> > > def createmap[K,V](kvs: (K,V)*) //Now that wasn't hard?
> >
> > no of course not, but you don't say "even number of parameters" to the
> > type system, you're saying "variable number of tuples having 2
> attributes"
> >
>
> No, I was even more specific: "a sequence of key-value pairs, where the
> keys hae type K and the values type V"
>
>
> >
> > you can express this easily in scala, but only with the help of other
> > constructs like a tuple, implicit conversions and other helpers.
> >
>
> To express something you must be able to express it, not expressing it
> doesn't express it.
>
>
> >
> > what if i make up the following rule:
> > the first parameter is an instance of type x. the next n parameters are
> > optional parameters and the next one is mandatory and of type z.
> >
>
> Works just fine:
>
> scala> def magic[A,B,C](a: A)(bs: B*)(c: C) = ()
> magic: [A, B, C](a: A)(bs: B*)(c: C)Unit
>
> scala> magic("foo")(1,2,3)("bar")

it's not the same. the scala call *would*, if possible, be:

magic("foo",1,2,3,4,"bar","foo2",5,6,"bar2")

and it would be the job of the compiler to figure out that the numbers belong together.

>
>
> >
> > the call would look like this in clojure
> > (magic first op1 op2 op3 last
> > first2 op1b op2b last2
> > ....)
> >
> > in scala, the call would look like:
> >
> > magic((first,List(op1,op2,op3), last), ...)
> >
> > i need to put the parameters into a structure before making the call. in
> > clojure or a magic static type system more powerful than that of scala,
> i
> > can just apply them without preparing a structure at every call site.
> the
> > called function would take care of that, or the magic compiler that i
> have
> > not seen yet.
> >
>
> See above.
>
>
> >
> > >
> > >
> > > >
> > > > so i wonder, what are the improvements planned for the next scala
> > > releases?
> > > >
> > > >
> > >
> > >
> > > --
> > > Viktor Klang
> > >
> > > Akka Tech Lead
> > > Typesafe - Enterprise-Grade Scala from the
> > > Experts
> > >
> > > Twitter: @viktorklang
> >
>
>
>

Viktor Klang
Joined: 2008-12-17,
User offline. Last seen 1 year 27 weeks ago.
Re: planned type system enhancements


On Wed, Nov 16, 2011 at 3:26 PM, Dennis Haupt <h-star [at] gmx [dot] de> wrote:


-------- Original-Nachricht --------
> Datum: Wed, 16 Nov 2011 15:21:41 +0100
> Von: "√iktor Ҡlang" <viktor [dot] klang [at] gmail [dot] com>
> An: Dennis Haupt <h-star [at] gmx [dot] de>
> CC: scala-debate [at] googlegroups [dot] com
> Betreff: Re: [scala-debate] planned type system enhancements

> On Wed, Nov 16, 2011 at 3:16 PM, Dennis Haupt <h-star [at] gmx [dot] de> wrote:
>
> >
> > -------- Original-Nachricht --------
> > > Datum: Wed, 16 Nov 2011 13:40:47 +0100
> > > Von: "√iktor Ҡlang" <viktor [dot] klang [at] gmail [dot] com>
> > > An: Dennis Haupt <h-star [at] gmx [dot] de>
> > > CC: scala-debate [at] googlegroups [dot] com
> > > Betreff: Re: [scala-debate] planned type system enhancements
> >
> > > On Wed, Nov 16, 2011 at 12:47 PM, Dennis Haupt <h-star [at] gmx [dot] de> wrote:
> > >
> > > > hi there,
> > > >
> > > > after 10+ years of using statically typed languages and not having a
> > > clue
> > > > why anyone would use dynamic types because all you get is code you
> > can't
> > > > maintain, i finally understood one big advantage of dynamic typing
> > > (thanks
> > > > to clojure which was an eye opener).
> > > >
> > > > in java, you force the caller of a method to use an instance of type
> X
> > -
> > > > even if you only need a small fraction of X's methods or fields. if
> you
> > > > have a big class that can do a lot or provides a lot of information,
> > > that
> > > > class will appear virtually anywhere even though only parts of it
> are
> > > > accessed.
> > > >
> > > > in clojure, instead of "i need type x" you say "i need something
> that
> > is
> > > > compatible to type x" where type x might never be explicily declared
> > and
> > > > only exists in the programmers mind and at runtime.
> > > >
> > > > scala has structural types for that, but clojure's destructuring is
> > more
> > > > powerful. it works on maps, arrays and classes and i won't have to
> > worry
> > > > about what is given to my function.
> > > >
> > > > the absense of a type system also makes things like
> > > > createmap(key, value, key2, value2... keyN, valueN) possible. no
> > > > typesystem i know of can be told to make sure the number of
> parameters
> > > is _
> > > > % 2 == 0. of course you can always cheat by using tuples
> > >
> > >
> > > You start out by saying that it cannot be done, and then you say that
> > it's
> > > cheating to do it?
> > > That's a nice one!
> > >
> > >
> > > > or method overloading for every possible parameter count up to 2*n
> but
> > > the
> > > > most simple solution in this case is to just skip the static types.
> > > >
> > >
> > > def createmap[K,V](kvs: (K,V)*) //Now that wasn't hard?
> >
> > no of course not, but you don't say "even number of parameters" to the
> > type system, you're saying "variable number of tuples having 2
> attributes"
> >
>
> No, I was even more specific: "a sequence of key-value pairs, where the
> keys hae type K and the values type V"
>
>
> >
> > you can express this easily in scala, but only with the help of other
> > constructs like a tuple, implicit conversions and other helpers.
> >
>
> To express something you must be able to express it, not expressing it
> doesn't express it.
>
>
> >
> > what if i make up the following rule:
> > the first parameter is an instance of type x. the next n parameters are
> > optional parameters and the next one is mandatory and of type z.
> >
>
> Works just fine:
>
> scala> def magic[A,B,C](a: A)(bs: B*)(c: C) = ()
> magic: [A, B, C](a: A)(bs: B*)(c: C)Unit
>
> scala> magic("foo")(1,2,3)("bar")

it's not the same.

I beg to differ, the difference is that mine is typesafe and yours is not.
 
the scala call *would*, if possible, be:

magic("foo",1,2,3,4,"bar","foo2",5,6,"bar2")

and it would be the job of the compiler to figure out that the numbers belong together.

>
>
> >
> > the call would look like this in clojure
> > (magic first op1 op2 op3 last
> >       first2 op1b op2b last2
> >       ....)
> >
> > in scala, the call would look like:
> >
> > magic((first,List(op1,op2,op3), last), ...)
> >
> > i need to put the parameters into a structure before making the call. in
> > clojure or a magic static type system more powerful than that of scala,
> i
> > can just apply them without preparing a structure at every call site.
> the
> > called function would take care of that, or the magic compiler that i
> have
> > not seen yet.
> >
>
> See above.
>
>
> >
> > >
> > >
> > > >
> > > > so i wonder, what are the improvements planned for the next scala
> > > releases?
> > > >
> > > >
> > >
> > >
> > > --
> > > Viktor Klang
> > >
> > > Akka Tech Lead
> > > Typesafe <http://www.typesafe.com/> - Enterprise-Grade Scala from the
> > > Experts
> > >
> > > Twitter: @viktorklang
> >
>
>
>
> --
> Viktor Klang
>
> Akka Tech Lead
> Typesafe <http://www.typesafe.com/> - Enterprise-Grade Scala from the
> Experts
>
> Twitter: @viktorklang



--
Viktor Klang

Akka Tech LeadTypesafe - Enterprise-Grade Scala from the Experts

Twitter: @viktorklang
adriaanm
Joined: 2010-02-08,
User offline. Last seen 31 weeks 4 days ago.
Re: planned type system enhancements
http://scalamacros.org/

On Wed, Nov 16, 2011 at 3:37 PM, Dennis Haupt <h-star [at] gmx [dot] de> wrote:
imagine it would be possible to write code that runs at compile time which checks and restructures the parameters applied to a method.

-------- Original-Nachricht --------
> Datum: Wed, 16 Nov 2011 15:26:48 +0100
> Von: Adriaan Moors <adriaan [dot] moors [at] epfl [dot] ch>
> An: Dennis Haupt <h-star [at] gmx [dot] de>
> CC: scala-debate [at] googlegroups [dot] com
> Betreff: Re: [scala-debate] planned type system enhancements

> On Wed, Nov 16, 2011 at 3:22 PM, Dennis Haupt <h-star [at] gmx [dot] de> wrote:
>
> > as i said, there is no static type system which i know of that can make
> > everything typesafe what i can do with dynamic typing.
>
> yeah, you can keep saying that, and it's true (and i consider that a
> feature -- i wouldn't want the unsafe things you can do with dynamic
> typing
> to be considered typesafe, for one), but I don't see how your statement
> contributes to the debate

Paul Brauner
Joined: 2010-10-28,
User offline. Last seen 42 years 45 weeks ago.
Re: planned type system enhancements

Oops, sorry, missed that part.

Paul

On Wed, Nov 16, 2011 at 17:10, Dennis Haupt wrote:
> yes, that's what i said. scala has structural types for that.
>
> -------- Original-Nachricht --------
>> Datum: Wed, 16 Nov 2011 16:53:18 +0100
>> Von: Paul Brauner
>> An: Dennis Haupt
>> CC: scala-debate [at] googlegroups [dot] com
>> Betreff: Re: [scala-debate] planned type system enhancements
>
>> I think what you want is structural subtyping (or "static duck
>> typing") and scala (as well as ocaml) supports it:
>>
>> scala> def f(x:Any { def yell : String }) = x.yell + x.yell
>> f: (x: Any{def yell: String})java.lang.String
>>
>> scala> class Dog { def yell = "woof"; def size = 4 }
>> defined class Dog
>>
>> scala> f(new Dog())
>> res1: java.lang.String = woofwoof
>>
>> See, f accepts any type that has *at least* yell. It doesn't care that
>> Dog has also size or that it is a dog.
>>
>> Paul
>>
>> On Wed, Nov 16, 2011 at 12:47, Dennis Haupt wrote:
>> > hi there,
>> >
>> > after 10+ years of using statically typed languages and not having a
>> clue why anyone would use dynamic types because all you get is code you can't
>> maintain, i finally understood one big advantage of dynamic typing (thanks
>> to clojure which was an eye opener).
>> >
>> > in java, you force the caller of a method to use an instance of type X -
>> even if you only need a small fraction of X's methods or fields. if you
>> have a big class that can do a lot or provides a lot of information, that
>> class will appear virtually anywhere even though only parts of it are
>> accessed.
>> >
>> > in clojure, instead of "i need type x" you say "i need something that is
>> compatible to type x" where type x might never be explicily declared and
>> only exists in the programmers mind and at runtime.
>> >
>> > scala has structural types for that, but clojure's destructuring is more
>> powerful. it works on maps, arrays and classes and i won't have to worry
>> about what is given to my function.
>> >
>> > the absense of a type system also makes things like
>> > createmap(key, value, key2, value2... keyN, valueN) possible. no
>> typesystem i know of can be told to make sure the number of parameters is _ % 2 ==
>> 0. of course you can always cheat by using tuples or method overloading
>> for every possible parameter count up to 2*n but the most simple solution in
>> this case is to just skip the static types.
>> >
>> > so i wonder, what are the improvements planned for the next scala
>> releases?
>> >
>> >
>

Copyright © 2012 École Polytechnique Fédérale de Lausanne (EPFL), Lausanne, Switzerland