- About Scala
- Documentation
- Code Examples
- Software
- Scala Developers
Type aliases in arbitrary blocks.
Sun, 2012-01-15, 01:44
Hi, all,
As my types become more sophisticated, I find myself really wishing that type aliases could be defined in arbitrary blocks, not just as members of traits, classes, or objects.
As a workaround for this lack, I find myself often writing something like this:
trait Value[A] { def value: A}
def foo: A = new Value[A] { type ER[R] = Either[String, R] type F[A] = SomeOtherTypeThatTakesATypeConstructorAsItsFirstArg[ER, A] val value = { /* use F as a type constructor somewhere in here */ } }.value
Why is it that local type aliases are not supported, and is there any possibility of adding this feature to the language? I know about the inline type lambda trick, of course, but when you start encountering nested lambdas things get a bit hairy to read. Of course, a better syntax for writing type lambdas would also be desirable, but even in the presence of such a syntax enhancement nested type lambdas would still be less readable than if type aliases could be defined in method bodies (or arbitrary blocks):
def foo: A = { type ER[R] = Either[String, R] type F[A] = SomeOtherTypeThatTakesATypeConstructorAsItsFirstArg[ER, A]
// use F as a type constructor }
As my types become more sophisticated, I find myself really wishing that type aliases could be defined in arbitrary blocks, not just as members of traits, classes, or objects.
As a workaround for this lack, I find myself often writing something like this:
trait Value[A] { def value: A}
def foo: A = new Value[A] { type ER[R] = Either[String, R] type F[A] = SomeOtherTypeThatTakesATypeConstructorAsItsFirstArg[ER, A] val value = { /* use F as a type constructor somewhere in here */ } }.value
Why is it that local type aliases are not supported, and is there any possibility of adding this feature to the language? I know about the inline type lambda trick, of course, but when you start encountering nested lambdas things get a bit hairy to read. Of course, a better syntax for writing type lambdas would also be desirable, but even in the presence of such a syntax enhancement nested type lambdas would still be less readable than if type aliases could be defined in method bodies (or arbitrary blocks):
def foo: A = { type ER[R] = Either[String, R] type F[A] = SomeOtherTypeThatTakesATypeConstructorAsItsFirstArg[ER, A]
// use F as a type constructor }
Sun, 2012-01-15, 15:41
#2
Re: Type aliases in arbitrary blocks.
How odd. I was sure that I'd tried that. Thanks.
On Sat, Jan 14, 2012 at 6:23 PM, Aleksey Nikiforov <lexn82@gmail.com> wrote:
On Sat, Jan 14, 2012 at 6:23 PM, Aleksey Nikiforov <lexn82@gmail.com> wrote:
Local type aliases are supported. Double check your signatures.
On Sat, Jan 14, 2012 at 6:44 PM, Kris Nuttycombe <kris.nuttycombe@gmail.com> wrote:
Hi, all,
As my types become more sophisticated, I find myself really wishing that type aliases could be defined in arbitrary blocks, not just as members of traits, classes, or objects.
As a workaround for this lack, I find myself often writing something like this:
trait Value[A] { def value: A}
def foo: A = new Value[A] { type ER[R] = Either[String, R] type F[A] = SomeOtherTypeThatTakesATypeConstructorAsItsFirstArg[ER, A] val value = { /* use F as a type constructor somewhere in here */ } }.value
Why is it that local type aliases are not supported, and is there any possibility of adding this feature to the language? I know about the inline type lambda trick, of course, but when you start encountering nested lambdas things get a bit hairy to read. Of course, a better syntax for writing type lambdas would also be desirable, but even in the presence of such a syntax enhancement nested type lambdas would still be less readable than if type aliases could be defined in method bodies (or arbitrary blocks):
def foo: A = { type ER[R] = Either[String, R] type F[A] = SomeOtherTypeThatTakesATypeConstructorAsItsFirstArg[ER, A]
// use F as a type constructor }
Mon, 2012-01-16, 03:51
#3
Re: Type aliases in arbitrary blocks.
p.p1 {margin: 0.0px 0.0px 0.0px 0.0px; line-height: 15.0px; font: 14.0px Helvetica}
p.p2 {margin: 0.0px 0.0px 0.0px 0.0px; line-height: 15.0px; font: 14.0px Helvetica; min-height: 17.0px}
p.p3 {margin: 0.0px 0.0px 0.0px 12.0px; font: 16.0px Times; color: #161616}
p.p4 {margin: 0.0px 0.0px 0.0px 0.0px; line-height: 17.0px; font: 14.0px Helvetica; min-height: 17.0px}
p.p5 {margin: 0.0px 0.0px 0.0px 0.0px; line-height: 17.0px; font: 14.0px Helvetica}
p.p6 {margin: 0.0px 0.0px 0.0px 12.0px; font: 16.0px Times; color: #161616; min-height: 19.0px}
span.s1 {direction: ltr; unicode-bidi: embed}
span.s2 {text-decoration: underline ; direction: ltr; unicode-bidi: embed}
On 2012-01-14 19:23:24 -0600, Aleksey Nikiforov said:
Local type aliases are supported. Double check your signatures.
Any idea why they are not supported at the top level of a package (i.e. without a package object)?
On Sat, Jan 14, 2012 at 6:44 PM, Kris Nuttycombe <kris.nuttycombe@gmail.com> wrote:
Hi, all,
As my types become more sophisticated, I find myself really wishing that type aliases could be defined in arbitrary blocks, not just as members of traits, classes, or objects.
As a workaround for this lack, I find myself often writing something like this:
trait Value[A] {
def value: A
}
def foo: A = new Value[A] {
type ER[R] = Either[String, R]
type F[A] = SomeOtherTypeThatTakesATypeConstructorAsItsFirstArg[ER, A]
val value = { /* use F as a type constructor somewhere in here */ }
}.value
Why is it that local type aliases are not supported, and is there any possibility of adding this feature to the language? I know about the inline type lambda trick, of course, but when you start encountering nested lambdas things get a bit hairy to read. Of course, a better syntax for writing type lambdas would also be desirable, but even in the presence of such a syntax enhancement nested type lambdas would still be less readable than if type aliases could be defined in method bodies (or arbitrary blocks):
def foo: A = {
type ER[R] = Either[String, R]
type F[A] = SomeOtherTypeThatTakesATypeConstructorAsItsFirstArg[ER, A]
// use F as a type constructor
}
Mon, 2012-01-16, 06:01
#4
Re: Re: Type aliases in arbitrary blocks.
Probably due to JVM compatibility baggage.
On Sun, Jan 15, 2012 at 8:44 PM, Sophie <itsme213@hotmail.com> wrote:
On Sun, Jan 15, 2012 at 8:44 PM, Sophie <itsme213@hotmail.com> wrote:
Any idea why they are not supported at the top level of a package (i.e. without a package object)?
Mon, 2012-01-16, 06:51
#5
Re: Re: Type aliases in arbitrary blocks.
On 16 January 2012 15:57, Aleksey Nikiforov <lexn82@gmail.com> wrote:
I had always assumed this, but I've always wondered why the package object couldn't just be generated in that case. IMO it seems inelegant having three separate concepts, with slightly different rules -- packages, objects and package objects -- for essentially the same thing, barring JVM representational issues.
Ken
Probably due to JVM compatibility baggage.
I had always assumed this, but I've always wondered why the package object couldn't just be generated in that case. IMO it seems inelegant having three separate concepts, with slightly different rules -- packages, objects and package objects -- for essentially the same thing, barring JVM representational issues.
Ken
On Sat, Jan 14, 2012 at 6:44 PM, Kris Nuttycombe <kris.nuttycombe@gmail.com> wrote: