Type system question

On Mon, Sep 20, 2010 at 12:53:50PM -0700, Niels Hoogeveen wrote:
> Suppose I have trait A and B, where B extends A.
>
> I would like to state that every trait C that (indirectly) extends A,
> either extends B, or when it doesn't extend B, that there is a trait D
> that extends both C and B.

You lose me when you start talking about D. Is it some other trait
somewhere else? If "there is a trait" means "has D as a supertype" then
it doesn't make sense because if D extends C and B and A extends D, then
A extends B and it doesn't need D.

Anyway, just making up a different interpretation for the purposes of
trying out weird stuff, here's some code and a demo transcript.

trait Universe {
trait A {
self: Conforms =>

}
trait B extends A {
self: Conforms =>
}

sealed trait Conforms
trait ConformsByExtendingB extends Conforms {
self: B =>

}
trait ConformsByTellingUsAboutD extends Conforms {
type D <: B

def hereIsD: D
}
}

scala> val x = new Universe { }
x: java.lang.Object with Universe = $anon$1@663d0426

scala> import x._
import x._

scala> trait Q extends B { }
:9: error: illegal inheritance;
self-type Q does not conform to x.B's selftype x.B with x.Conforms
trait Q extends B { }
^

scala> trait Q extends B with Conforms { }
:9: error: illegal inheritance from sealed trait Conforms
trait Q extends B with Conforms { }
^

scala> trait Q extends B with ConformsByExtendingB { }
defined trait Q

scala> trait Q2 extends B with ConformsByTellingUsAboutD { }
defined trait Q2

scala> new Q2 { }
:11: error: object creation impossible, since method hereIsD in trait ConformsByTellingUsAboutD of type => this.D is not defined
new Q2 { }
^

scala> trait Q2 extends B with ConformsByTellingUsAboutD { type D = Q ; def hereIsD: Q = new Q {} }
defined trait Q2

scala> new Q2 { }
res4: java.lang.Object with Q2 = $anon$1@76f8d6a6

Paul Phillips-3 wrote:
>
> You lose me when you start talking about D. Is it some other trait
> somewhere else? If "there is a trait" means "has D as a supertype" then
> it doesn't make sense because if D extends C and B and A extends D, then
> A extends B and it doesn't need D.
>

I guess my phrasing was confusing.

Whenever introducing a trait C that (directly or indirectly) extends A, I'd
like to see either of the two situations:

1) C extends B (directly or by extending a trait that extends B)

In its simplest form B extends A and C extends B

or

C extends A (either directly or by extending a trait that extends A but not
B), while at the same time guaranteeing there is a trait D that extends both
C and B.

In its simplest form B extends A, C extends A, and D extends C and B.

I'd like there to be some way to check that when a trait C gets introduced
it either conforms to the first or the second situation. I doubt such a
guarantee can be achieved in Scala, if not I am looking for a type theory
that can.

On Mon, Sep 20, 2010 at 02:45:14PM -0700, Niels Hoogeveen wrote:
> C extends A (either directly or by extending a trait that extends A
> but not B), while at the same time guaranteeing there is a trait D
> that extends both C and B.

You would have to tell me how that guarantee is expressed. It sounds
like the code I posted wasn't too far from what you're going for, not
that I was suggesting you use it. I don't see how you can enforce
something like "either I have some property or somewhere else there's a
thing with this other property" without either 1) a closed world or 2)
requiring those Cs which aren't Bs to give up D or something which can
produce a D before they are created.

In other words, other than tweaks to how D is represented, either my
first answer was good, or I don't know what you want, or you can't do it
in this type system but might have better luck in some hindley milner
diamond-like jewel offering spooky type action at a distance.

On Mon, Sep 20, 2010 at 10:45 PM, Niels Hoogeveen
wrote:
> I'd like there to be some way to check that when a trait C gets introduced
> it either conforms to the first or the second situation. I doubt such a
> guarantee can be achieved in Scala, if not I am looking for a type theory
> that can.

Like Paul I'm a bit puzzled by the fact that D appears to be dangling
freely, but I'm going to assume that when you say "there is a trait D"
you mean "there is a trait D which is mixed in to any ultimate
concrete class" rather than it just existing in general.

If that's the case, then I think you can achieve what you're after by
self-typing A as a B,

scala> trait A { self : B => } ; trait B extends A
defined trait A
defined trait B

scala> trait C1 extends A
:6: error: illegal inheritance;
self-type C1 does not conform to A's selftype B
trait C1 extends A
^

scala> trait C1 extends A with B // Case 1: C extends B
defined trait C1

scala> class CC1 extends C1
defined class CC1

scala> trait C2 extends A { self : B => } // Case 2: C doesn't extend B
defined trait C2

scala> class CC2 extends C2
:8: error: illegal inheritance;
self-type CC2 does not conform to C2's selftype C2 with B
class CC2 extends C2
^

scala> trait D extends B with C2 // There is a D which extends both B and C
defined trait D

scala> class CC2 extends D
defined class CC2

Cheers,

Miles

Miles Sabin wrote:
>
> Like Paul I'm a bit puzzled by the fact that D appears to be dangling
> freely, but I'm going to assume that when you say "there is a trait D"
> you mean "there is a trait D which is mixed in to any ultimate
> concrete class" rather than it just existing in general.
>

I agree my question was didn't properly reflect my intentions. Let try to
write down my intentions more clearly.

There a trait A.
There is a trait B which extends A.
There may be several traits C' that extend A (either directly or through
other traits that extend A), but that do not extend B.

When defining a class C1 I want to guarantee the following:

If C1 extends a C' trait but does not extend B, there also needs to be a
class C2 that extends both the C' trait and the B trait.

On Tuesday September 21 2010, Niels Hoogeveen wrote:
> Miles Sabin wrote:
> > Like Paul I'm a bit puzzled by the fact that D appears to be
> > dangling freely, but I'm going to assume that when you say "there
> > is a trait D" you mean "there is a trait D which is mixed in to any
> > ultimate concrete class" rather than it just existing in general.
>
> I agree my question was didn't properly reflect my intentions. Let
> try to write down my intentions more clearly.
>
> There a trait A.
> There is a trait B which extends A.
> There may be several traits C' that extend A (either directly or
> through other traits that extend A), but that do not extend B.
>
> When defining a class C1 I want to guarantee the following:
>
> If C1 extends a C' trait but does not extend B, there also needs to
> be a class C2 that extends both the C' trait and the B trait.

We sometimes describe the operations of the Scala type checker as a
theorem prover, but it is not a prover for arbitrary FOL expressions
written over the domain of types, so I don't think the pattern of class
definition and derivation you require is possible.

Randall Schulz

I'd just add self: B => to A. This way, for every class (except B) that extends A, either B must be included, or it must inherit something that includes B.

However, that solution seems way too obvious to me, so I assume you considered it and discarded it. If so, what's the problem with it?

On Tue, Sep 21, 2010 at 10:45, Niels Hoogeveen <pd_aficionado@hotmail.com> wrote:

Miles Sabin wrote:
>
> Like Paul I'm a bit puzzled by the fact that D appears to be dangling
> freely, but I'm going to assume that when you say "there is a trait D"
> you mean "there is a trait D which is mixed in to any ultimate
> concrete class" rather than it just existing in general.
>

I agree my question was didn't properly reflect my intentions. Let try to
write down my intentions more clearly.

There a trait A.
There is a trait B which extends A.
There may be several traits C' that extend A (either directly or through
other traits that extend A), but that do not extend B.

When defining a class C1 I want to guarantee the following:

If C1 extends a C' trait but does not extend B, there also needs to be a
class C2 that extends both the C' trait and the B trait.

--
View this message in context: http://scala-programming-language.1934581.n4.nabble.com/Type-system-question-tp2547592p2548648.html
Sent from the Scala mailing list archive at Nabble.com.

--
Daniel C. Sobral

I travel to the future all the time.

On Tue, Sep 21, 2010 at 2:45 PM, Niels Hoogeveen
wrote:
> Miles Sabin wrote:
>>
>> Like Paul I'm a bit puzzled by the fact that D appears to be dangling
>> freely, but I'm going to assume that when you say "there is a trait D"
>> you mean "there is a trait D which is mixed in to any ultimate
>> concrete class" rather than it just existing in general.
>>
>
> I agree my question was didn't properly reflect my intentions. Let try to
> write down my intentions more clearly.
>
> There a trait A.
> There is a trait B which extends A.
> There may be several traits C' that extend A (either directly or through
> other traits that extend A), but that do not extend B.
>
> When defining a class C1 I want to guarantee the following:
>
> If C1 extends a C' trait but does not extend B, there also needs to be a
> class C2 that extends both the C' trait and the B trait.

Unless I'm misunderstanding, that's exactly what my solution guarantees.

Cheers,

Miles

Miles Sabin wrote:
>
> Unless I'm misunderstanding, that's exactly what my solution guarantees.
>

I think your solution is more restrictive than what I am looking for, since
it doesn't allow for a class CC2 that extends only trait A and trait C. I
want this class to be accepted, if and only if there is a class CC3 that
extends both trait C and trait B.

So in the situation where class CC1 extends trait C1 (that extends trait B),
having one class will suffice, while in the situation where class CC2
extends trait C2 (that extends trait A), two classes are needed for proper
typing: Class CC2 that extends trait C and class CC3 that extends trait C
and trait B.

If this is not possible in Scala, is there anyone who knows a type theory
which can express such type constraints. I am more interested in the general
pattern behind these sort of constraints than a specific solution to this
problem.

Why do you want a type system instead of a computer algebra or logic system?

Is there a reason why your particular constraints are uniquely useful to types?

For example, when worrying about types, why would I care if a trait was created and never used, aside from that giving me a warm fuzzy feeling?

  --Rex

Dear Niels,
Your puzzle is interesting; but, i'm a little confused about your requirements. Do you really need the only if part of your existential condition? Taking away the only if we arrive at a form of confluence -- but for types! That's an interesting idea. 
There's another aspect of the existential condition that isn't clear to me. When you say that 'there is such and such a class' do you mean that such and such a class is definable or that it is already defined? Surely the former is true using Miles' solution. You can always synthesize the type you require. Does it need to have already been synthesized? If so, why? What other requirements are forcing defined over definable?
Best wishes,
--greg

On Tue, Sep 21, 2010 at 12:49 PM, Niels Hoogeveen <pd_aficionado@hotmail.com> wrote:

Miles Sabin wrote:
>
> Unless I'm misunderstanding, that's exactly what my solution guarantees.
>

I think your solution is more restrictive than what I am looking for, since
it doesn't allow for a class CC2 that extends only trait A and trait C. I
want this class to be accepted, if and only if there is a class CC3 that
extends both trait C and trait B.

So in the situation where class CC1 extends trait C1 (that extends trait B),
having one class will suffice, while in the situation where class CC2
extends trait C2 (that extends trait A), two classes are needed for proper
typing: Class CC2 that extends trait C and class CC3 that extends trait C
and trait B.

If this is not possible in Scala, is there anyone who knows a type theory
which can express such type constraints. I am more interested in the general
pattern behind these sort of constraints than a specific solution to this
problem.


--
View this message in context: http://scala-programming-language.1934581.n4.nabble.com/Type-system-question-tp2547592p2549295.html
Sent from the Scala mailing list archive at Nabble.com.

--
L.G. Meredith
Managing Partner
Biosimilarity LLC
7329 39th Ave SWSeattle, WA 98136

+1 206.650.3740

http://biosimilarity.blogspot.com

Meredith Gregory wrote:
>
> Your puzzle is interesting; but, i'm a little confused about your
> requirements. Do you really need the only if part of your existential
> condition? Taking away the only if we arrive at a form of confluence --
> but
> for types! That's an interesting idea.
>
> There's another aspect of the existential condition that isn't clear to
> me.
> When you say that 'there is such and such a class' do you mean that such
> and
> such a class is definable or that it is already defined? Surely the former
> is true using Miles' solution. You can always synthesize the type you
> require. Does it need to have already been synthesized? If so, why? What
> other requirements are forcing defined over definable?
>
Dear Meredith,

I think the "only if" part is a requirements in what I am looking for.

A class CC2 that extends trait C2 (extends A but not B), while there is no
class CC3 that extends both trait C2 and trait B, should not type check.

When I say "there is such and such a class", I mean it is already defined.

So first we define trait A, B and C2. Then we define class CC3. Class CC3
should type check, because it extends trait B. Then we define CC2, which
should type check because CC3 already exists.

I want to achieve this, because I want a guarantee that on runtime there
exists:

1) either a class CC1 that extends trait C1 (extending B)
2) or there is both a class CC2 that extends trait C2 (extending A but not
B) and a class CC3 that extends trait C2 and trait B.

Ideally the compiler would generate class CC3 when class CC2 is defined, but
I think that is even more unlikely to be attainable in Scala than what I am
asking for.

Niels

On Tuesday September 21 2010, Niels Hoogeveen wrote:
> Meredith Gregory wrote:
> > Your puzzle is interesting; but, i'm a little confused about your
> > requirements. Do you really need the only if part of your
> > existential condition? Taking away the only if we arrive at a form
> > of confluence -- but for types! That's an interesting idea.
> >
> > There's another aspect of the existential condition that isn't
> > clear to me. When you say that 'there is such and such a class' do
> > you mean that such and such a class is definable or that it is
> > already defined? Surely the former is true using Miles' solution.
> > You can always synthesize the type you require. Does it need to have
> > already been synthesized? If so, why? What other requirements are
> > forcing defined over definable?
>
> Dear Meredith,
>
> I think the "only if" part is a requirements in what I am looking
> for.
>
> A class CC2 that extends trait C2 (extends A but not B), while there
> is no class CC3 that extends both trait C2 and trait B, should not
> type check.
>
> When I say "there is such and such a class", I mean it is already
> defined.

Now that we're clear on the requirement, could you make this concrete?
What are you writing that spawns such an unusual type definition?

> ...
>
> Niels

Randall Schulz

Randall R Schulz wrote:
>
> Now that we're clear on the requirement, could you make this concrete?
> What are you writing that spawns such an unusual type definition?
>
Hi Randall,

I am building a piece of website software that closely resembles a Content
Management System, using a graph database and a partially home-grown meta
model.

The issue I have is the following:

For some classes of "entries" (eg. Countries), I want to state that each
instance will be a "topic" (meaning they appear in a drop down box when
selecting tags for a certain post, and their interface provides a unique
name to be used in the drop down box).

For some classes of entries (eg Blog posts), I want to state that some of
them are "topics" (users select certain blog posts to become topics) but
others are not. A blog post that is also a "topic", should implement the
topic-interface (extend the topic trait), while the blog post that is not a
"topic" should not implement the topic-interface.

When defining a "country" class it will extend the topic trait, so all
instances will automatically be "topics" too.

When defining a "blog post" class it will extend the "blog posts" trait, but
not the "topic" trait. Yet since there are some blog posts that will become
topics, I need another class that extends the "blog post" trait and the
"topic" trait. All those classes need to be available at runtime.

Hello,

at the moment I analyze the possibilities to work with scala and spring together. There is one point, which is a bit strange for me:

I define a scala class with one parameter with a default-value in its constructor. In the next step I write the xml-configuration without this parameter. the result is, that spring is missing the default constructor.
My expectation was, that scala generates a constructor with one parameter and a contructor without any parameters. That is obviously wrong.

Please, can anyone explain this behaviour?

Thanks,
Barbara

Default parameters don't become part of the signature as seen from Java, Java Reflection, or Spring!When you use such a method/constructor within Scala, the compiler will automatically insert the default for you, but that mechanism isn't available from outside of the language.

This is a known problem, and there are currently efforts underway to create a fully featured Scala reflection library that could help out here.  I'm also working on a spring-scala interop library* that will (ultimately) be able to use Scala reflection for dealing with things like default parameters.

In the meantime, you have a range of options open to you, these mostly being the same approaches that you would use in Java:
- use multiple overloaded constructors - use overloaded factory methods or a "builder" object- provide the default via a constant that you can explicitly supply with Spring- avoid Spring altogether, in favour of dependency injection via traits/implicits in pure Scala
Also bear in mind that you're going to have to deal with converting between Java/Scala collection types if using e.g. the <list/> element.
*http://github.com/scalaj/scalaj-spring

On 23 September 2010 13:14, <barbara.von-kalm@basf-it-services.com> wrote:

Hello,

at the moment I analyze the possibilities to work with scala and spring together. There is one point, which is a bit strange for me:

I define a scala class with one parameter with a default-value in its constructor. In the next step I write the xml-configuration without this parameter. the result is, that spring is missing the default constructor.
My expectation was, that scala generates a constructor with one parameter and a contructor without any parameters. That is obviously wrong.

Please, can anyone explain this behaviour?

Thanks,
Barbara

--
Kevin Wright

mail / gtalk / msn : kev.lee.wright@gmail.com
pulse / skype: kev.lee.wright
twitter: @thecoda

Scala's default arguments are not translated into the well-known
scheme using overloading based on arity like it is done in Java, but
instead, the translation is more sophisticated to allow overriding of
defaults when inheriting (among other causes).

You can read more about the implementation details in the SID and in
Lukas' presentation from the Scala days:

http://www.scala-lang.org/sid/1
http://days2010.scala-lang.org/node/138/147

On Thu, Sep 23, 2010 at 2:14 PM, wrote:
>
> Hello,
>
> at the moment I analyze the possibilities to work with scala and spring
> together. There is one point, which is a bit strange for me:
>
> I define a scala class with one parameter with a default-value in its
> constructor. In the next step I write the xml-configuration without this
> parameter. the result is, that spring is missing the default constructor.
> My expectation was, that scala generates a constructor with one parameter
> and a contructor without any parameters. That is obviously wrong.
>
> Please, can anyone explain this behaviour?
>
> Thanks,
> Barbara
>

Scala's default parameters are implemented in a different way than you are guessing.

If Scala sees

class C(i: Int = 4) { ... }

then the compiler rewrites this as (effectively):

class C(i: Int) { ... }
object C {
  def init$default$1: Int = 4
}

and when it sees a call to the constructor with too few parameters, it first calls the method from the companion object to get the correct default value.

(For methods within C, the default is provided within class C using the same sort of name mangling.)

If you want to have a default constructor, I'm afraid you'll have to write it yourself:

class C(i: Int) {
  def this() = this(4)
}

  --Rex

On Thu, Sep 23, 2010 at 8:14 AM, <barbara.von-kalm@basf-it-services.com> wrote:

Hello,

at the moment I analyze the possibilities to work with scala and spring together. There is one point, which is a bit strange for me:

I define a scala class with one parameter with a default-value in its constructor. In the next step I write the xml-configuration without this parameter. the result is, that spring is missing the default constructor.
My expectation was, that scala generates a constructor with one parameter and a contructor without any parameters. That is obviously wrong.

Please, can anyone explain this behaviour?

Thanks,
Barbara