Re: [scala] 2.8, type parameters, manifests and traits

I was hopeful you could do something clever with Predef.=:=, however
the type system doesn't know that Manifest[TT] is the same as
Manifest[T] and the type inferencer can't infer TT, which renders this
approach useless.

> Howdy,
>
> In 2.8, is it possible to have the manifest for a type parameter defined on
> a trait reified someplace that's accessible to the trait. The following
> works with classes:
>
> class Foo[T: Manifest] {
> def myType(implicit man: Manifest[T]): Manifest[T] = man
> }
>
> But it seems that because traits don't take parameters, you can't do trait
> Foo[T: Manifest] ....
>
> It would be very, very helpful to have a reification of trait type
> parameters. Any ideas on how this could be done?
>
> Thanks,
>
> David
>
> --
> Lift, the simply functional web framework http://liftweb.net> Beginning Scala http://www.apress.com/book/view/1430219890> Follow me: http://twitter.com/dpp> Surf the harmonics
>

Re: [scala] 2.8, type parameters, manifests and traits

I'm pretty sure you can just do:

trait Foo[T] {
def func(...)(implicit mt : Manifest[T]) = ...
}

You would have to include the manifest parameter in every function that needs the manifest and it would have to be available in every scope that called one of those functions but it should work. I have used it.

So... the net-net is that traits don't take constructor parameters for a bunch of well know and documented reasons. Traits do take type parameters. It seems to me that in the case of traits with type parameters marked as Manifest could only be mixed into classes that have the corresponding type parameter marked as Manifest... just like abstract methods on a trait must be implemented on implementing classes. In the case of an anonymous class that's being instantiated (new Trait[DefinedType] {}), the type is known and the anonymous class could contain the Manifest. I guess the third case is "class Foo extends Trait[Int]" but in that case, the compiler knows the type and can generate a manifest for it.

This would be *very helpful*.

You would have to include the manifest parameter in every function that needs the manifest and it would have to be available in every scope that called one of those functions but it should work. I have used it.

Re: [scala] 2.8, type parameters, manifests and traits

> On Fri, Feb 5, 2010 at 6:58 AM, Arthur Peters <[hidden email]> wrote:
>>
>> I'm pretty sure you can just do:
>>
>> trait Foo[T] {
>> def func(...)(implicit mt : Manifest[T]) = ...
>> }
>
> You actually can't do this because T is not know in every context.
>
>
> For example:
>
> object Bar {
> def calcFooManifest[T](foo: Foo[T]): Manifest[T] = foo.myType // we don't
> know what T is here
> }
>
> So... the net-net is that traits don't take constructor parameters for a
> bunch of well know and documented reasons. Traits do take type parameters.
> It seems to me that in the case of traits with type parameters marked as
> Manifest could only be mixed into classes that have the corresponding type
> parameter marked as Manifest... just like abstract methods on a trait must
> be implemented on implementing classes.

So you mean

trait Test[X: Manifest[X]]

would be desugared as

trait Test[X] {
implicit val mfX: Manifest[X]
}

and

class Impl[X: Manifest[X]] extends Test[X]

would desugar as

class Impl[X](implicit val mfX: Manifest[X]) extends Test[X]

?

That seems reasonable to me.

> In the case of an anonymous class
> that's being instantiated (new Trait[DefinedType] {}), the type is known and
> the anonymous class could contain the Manifest. I guess the third case is
> "class Foo extends Trait[Int]" but in that case, the compiler knows the type
> and can generate a manifest for it.

So, it boils down to this: Exactly as the compiler can find implicit
*parameter* values for method calls, it should find implicits for a
class' abstract member values. Is that possible?

Re: [scala] 2.8, type parameters, manifests and traits

The possibility of having traits take constructor parameters has been mentioned before. I don't know how far work on this front has gone, but I suspect that more general feature would solve this particular problem.

Re: [scala] 2.8, type parameters, manifests and traits

I can't corroborate this personally, but I've been told (by someone in the field of type theory) that traits would be generally unsound if they could take constructor parameters. I don't know if this holds for implicit params (I would imagine so). As I said, I can't personally confirm this information, but I thought it was worth throwing out there.

The possibility of having traits take constructor parameters has been mentioned before. I don't know how far work on this front has gone, but I suspect that more general feature would solve this particular problem.

I can't corroborate this personally, but I've been told (by someone in the field of type theory) that traits would be generally unsound if they could take constructor parameters. I don't know if this holds for implicit params (I would imagine so). As I said, I can't personally confirm this information, but I thought it was worth throwing out there.Daniel

The possibility of having traits take constructor parameters has been mentioned before. I don't know how far work on this front has gone, but I suspect that more general feature would solve this particular problem.

I can't corroborate this personally, but I've been told (by someone in the field of type theory) that traits would be generally unsound if they could take constructor parameters. I don't know if this holds for implicit params (I would imagine so). As I said, I can't personally confirm this information, but I thought it was worth throwing out there.Daniel

The possibility of having traits take constructor parameters has been mentioned before. I don't know how far work on this front has gone, but I suspect that more general feature would solve this particular problem.

I can't corroborate this personally, but I've been told (by someone in the field of type theory) that traits would be generally unsound if they could take constructor parameters. I don't know if this holds for implicit params (I would imagine so). As I said, I can't personally confirm this information, but I thought it was worth throwing out there.Daniel

The possibility of having traits take constructor parameters has been mentioned before. I don't know how far work on this front has gone, but I suspect that more general feature would solve this particular problem.

I can't corroborate this personally, but I've been told (by someone in the field of type theory) that traits would be generally unsound if they could take constructor parameters. I don't know if this holds for implicit params (I would imagine so). As I said, I can't personally confirm this information, but I thought it was worth throwing out there.Daniel

The possibility of having traits take constructor parameters has been mentioned before. I don't know how far work on this front has gone, but I suspect that more general feature would solve this particular problem.

Re: [scala] 2.8, type parameters, manifests and traits

Scala uses a kind of linearization here, so I think you could get away with it, as every class/object/trait had a defined path to the parent. It may be awkward to wield though, like virtual inheritance.

I can't corroborate this personally, but I've been told (by someone in the field of type theory) that traits would be generally unsound if they could take constructor parameters. I don't know if this holds for implicit params (I would imagine so). As I said, I can't personally confirm this information, but I thought it was worth throwing out there.Daniel

The possibility of having traits take constructor parameters has been mentioned before. I don't know how far work on this front has gone, but I suspect that more general feature would solve this particular problem.

I can't corroborate this personally, but I've been told (by someone in the field of type theory) that traits would be generally unsound if they could take constructor parameters. I don't know if this holds for implicit params (I would imagine so). As I said, I can't personally confirm this information, but I thought it was worth throwing out there.Daniel

The possibility of having traits take constructor parameters has been mentioned before. I don't know how far work on this front has gone, but I suspect that more general feature would solve this particular problem.

I can't corroborate this personally, but I've been told (by someone in the field of type theory) that traits would be generally unsound if they could take constructor parameters. I don't know if this holds for implicit params (I would imagine so). As I said, I can't personally confirm this information, but I thought it was worth throwing out there.Daniel

The possibility of having traits take constructor parameters has been mentioned before. I don't know how far work on this front has gone, but I suspect that more general feature would solve this particular problem.

Re: [scala] 2.8, type parameters, manifests and traits

On 2/22/10 10:15 AM, Adriaan Moors wrote:
> in principle, we don't want linearisation order to influence program
> behaviour (*), as it's supposed to stay behind the scenes

I am not sure. It already does influence program behavior:

trait A {
def f = 0
}

trait B extends A {
override def f = 2 * super.f
}

trait C extends A {
override def f = 1 + super.f
}

(new B with C).f == 1
(new C with B).f == 2

While I agree that an override modifier of some sort might be nice, in
our current proposal trait constructors will have different semantics
from class contructors. Trait constructor arguments would rather
designate a preference rather than a requirement for the value of a
parameter which might be changed in the final class composition. I find
the stream example would rather nicely fit into this line of thought, as
client code dealing with traits probably shouldn't depend on the actual
buffer size. In the end it would be a compromise between multiple
inheritance with traits and single inheritance with classes but a
guarantee for constructor arguments. I don't know in what sense Donna's
proposal is different and whether it allows a more fine-grained compromise.