[scala] Conformance to bounds in higher-order type parameters
|
View:
New views
9 Messages
—
Rating Filter:
Alert me
|
 |
[scala] Conformance to bounds in higher-order type parameters
by nikov
::
Rate this Message:
Hi,
Given the following definitions, /////////////////////////////////////////// trait A[B[X, Y <: X, Z <: Y]] trait C[X, Y <: X, Z <: X] trait D[X, Y, Z <: X] trait E[X >: Y, Y, Z] /////////////////////////////////////////// Scala 2.7.5 accepts the type application A[C], but rejects A[D] and A[E]. But they all seem equally type-safe. What part of SLS describes how these type-checks should proceed? Is the current behavior correct or desirable? Thanks, Vladimir |
|
|
|
|
|
Re: [scala] Conformance to bounds in higher-order type parameters
by Christos KK Loverdos
::
Rate this Message:
Hmm...I think the behaviour is beyond my knowledge and I have to read
the Spec. For example I am not sure how I can interpret the type definitions you give: are they aliases or constraints? On Jun 16, 2009, at 2:42 PM, Vladimir Reshetnikov wrote: > Hi Christos, > > Constraints on nested type parameters of a higher-order type parameter > work in backwards direction: it is OK to substitute a type constructor > with unconstrained nested type parameters instead of a higher-order > type parameter with constrained nested type parameters. > > In my example, it is possible to work around the current compiler > behavior with type aliases: > > //////////////////////////////////////////////////////// > trait A[B[X, Y <: X, Z <: Y]] > > trait C[X, Y <: X, Z <: X] > trait D[X, Y, Z <: X] > trait E[X >: Y, Y, Z] > > type D1[X, Y <: X, Z <: Y] = D[X, Y, Z] > type E1[X, Y <: X, Z <: Y] = E[X, Y, Z] > //////////////////////////////////////////////////////// > > Now, the type applications A[D1], A[E1] are accepted. But I would like > that it worked without aliases. > > Thanks, > Vladimir > > On 6/16/09, Christos KK Loverdos <loverdos@...> wrote: >> Hi, >> >> It is apparent that in the definitions of D, E, types Y & Z >> respectively are unconstrained. This is incompatible with how A is >> defined, where both Y & Z are constrained. So the errors you mention >> (I have not run the example) are expected. >> >> BR >> Christos >> >> On Jun 16, 2009, at 1:49 PM, Vladimir Reshetnikov wrote: >> >>> Hi, >>> >>> Given the following definitions, >>> >>> /////////////////////////////////////////// >>> trait A[B[X, Y <: X, Z <: Y]] >>> >>> trait C[X, Y <: X, Z <: X] >>> trait D[X, Y, Z <: X] >>> trait E[X >: Y, Y, Z] >>> /////////////////////////////////////////// >>> >>> Scala 2.7.5 accepts the type application A[C], but rejects A[D] and >>> A[E]. But they all seem equally type-safe. What part of SLS >>> describes >>> how these type-checks should proceed? Is the current behavior >>> correct >>> or desirable? >>> >>> Thanks, >>> Vladimir >> >> -- >> __~O >> -\ <, Christos KK Loverdos >> (*)/ (*) http://ckkloverdos.com >> >> >> >> >> >> -- __~O -\ <, Christos KK Loverdos (*)/ (*) http://ckkloverdos.com |
|
|
Re: [scala] Conformance to bounds in higher-order type parameters
by Adriaan Moors-2
::
Rate this Message:
Hi Vladimir,
Thanks for raising these interesting questions! Essentially, these type aliases are performing "kind casts". You're right that all these type applications are well-kinded; the kind conformance algorithm simply isn't sophisticated enough (yet) to insert these kind casts automatically.
Could you please file a ticket to request this enhancement and assign it to me? thanks! adriaan
On Tue, Jun 16, 2009 at 3:19 PM, Christos KK Loverdos <loverdos@...> wrote: Hmm...I think the behaviour is beyond my knowledge and I have to read the Spec. For example I am not sure how I can interpret the type definitions you give: are they aliases or constraints? |
|
|
Re: [scala] Conformance to bounds in higher-order type parameters
by nikov
::
Rate this Message:
Ticket #2068
Vladimir On 6/17/09, Adriaan Moors <adriaan.moors@...> wrote: > Hi Vladimir, > Thanks for raising these interesting questions! > > Essentially, these type aliases are performing "kind casts". You're right > that all these type applications are well-kinded; the kind conformance > algorithm simply isn't sophisticated enough (yet) to insert these kind > casts > automatically. > > Could you please file a ticket to request this enhancement and assign it to > me? > > thanks! > adriaan > > On Tue, Jun 16, 2009 at 3:19 PM, Christos KK Loverdos > <loverdos@...>wrote: > >> Hmm...I think the behaviour is beyond my knowledge and I have to read the >> Spec. For example I am not sure how I can interpret the type definitions >> you >> give: are they aliases or constraints? >> >> >> On Jun 16, 2009, at 2:42 PM, Vladimir Reshetnikov wrote: >> >> Hi Christos, >>> >>> Constraints on nested type parameters of a higher-order type parameter >>> work in backwards direction: it is OK to substitute a type constructor >>> with unconstrained nested type parameters instead of a higher-order >>> type parameter with constrained nested type parameters. >>> >>> In my example, it is possible to work around the current compiler >>> behavior with type aliases: >>> >>> //////////////////////////////////////////////////////// >>> trait A[B[X, Y <: X, Z <: Y]] >>> >>> trait C[X, Y <: X, Z <: X] >>> trait D[X, Y, Z <: X] >>> trait E[X >: Y, Y, Z] >>> >>> type D1[X, Y <: X, Z <: Y] = D[X, Y, Z] >>> type E1[X, Y <: X, Z <: Y] = E[X, Y, Z] >>> //////////////////////////////////////////////////////// >>> >>> Now, the type applications A[D1], A[E1] are accepted. But I would like >>> that it worked without aliases. >>> >>> Thanks, >>> Vladimir >>> >>> On 6/16/09, Christos KK Loverdos <loverdos@...> wrote: >>> >>>> Hi, >>>> >>>> It is apparent that in the definitions of D, E, types Y & Z >>>> respectively are unconstrained. This is incompatible with how A is >>>> defined, where both Y & Z are constrained. So the errors you mention >>>> (I have not run the example) are expected. >>>> >>>> BR >>>> Christos >>>> >>>> On Jun 16, 2009, at 1:49 PM, Vladimir Reshetnikov wrote: >>>> >>>> Hi, >>>>> >>>>> Given the following definitions, >>>>> >>>>> /////////////////////////////////////////// >>>>> trait A[B[X, Y <: X, Z <: Y]] >>>>> >>>>> trait C[X, Y <: X, Z <: X] >>>>> trait D[X, Y, Z <: X] >>>>> trait E[X >: Y, Y, Z] >>>>> /////////////////////////////////////////// >>>>> >>>>> Scala 2.7.5 accepts the type application A[C], but rejects A[D] and >>>>> A[E]. But they all seem equally type-safe. What part of SLS describes >>>>> how these type-checks should proceed? Is the current behavior correct >>>>> or desirable? >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>> >>>> -- >>>> __~O >>>> -\ <, Christos KK Loverdos >>>> (*)/ (*) http://ckkloverdos.com >>>> >>>> >>>> >>>> >>>> >>>> >>>> >> -- >> __~O >> -\ <, Christos KK Loverdos >> (*)/ (*) http://ckkloverdos.com >> >> >> >> >> >> >> Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm >> > |
|
|
Re: [scala] Conformance to bounds in higher-order type parameters
by andreas s.
::
Rate this Message:
Hi Vladimir,
I'm fairly new to functional programming and such concepts, I'm coming from a java background to scala. The higher Order type definitions look interesting! Could you give a small hint or direction where such would find their place in practice(IO, WEB, UI)? That would be nice. |
|
|
Re: [scala] Conformance to bounds in higher-order type parameters
by nikov
::
Rate this Message:
Hi Andreas.
In Haskell higher-order type parameters are ubiquitous and are a powerful way of abstraction. They were introduced at least 15 years ago. You might be interested to read about Functor, Applicative, Monad, MonadPlus, Foldable, Traversable. In OO world higher-order type parameters are quite new. You might be interested in reading Adriaan Moors' papers on them, for example "Safe Type-level Abstraction in Scala" (http://fool08.kuis.kyoto-u.ac.jp/moors.pdf). In a sense, they are even more powerful in Scala then in Haskell, because they can be bounded. Vladimir On 6/18/09, andreas s. <andreas_scheinert@...> wrote: > > Hi Vladimir, > I'm fairly new to functional programming and such concepts, I'm coming from > a java background to scala. The higher Order type definitions look > interesting! Could you give a small hint or direction where such would find > their place in practice(IO, WEB, UI)? That would be nice. > -- > View this message in context: > http://www.nabble.com/-scala--Conformance-to-bounds-in-higher-order-type-parameters-tp24051875p24079963.html > Sent from the Scala mailing list archive at Nabble.com. > > |
|
|
Re: [scala] Conformance to bounds in higher-order type parameters
by Adriaan Moors-2
::
Rate this Message:
Hi Andreas, Or in my dissertation: http://hdl.handle.net/1979/2642 (the relevant chapter is an extended version of the above paper).
cheers adriaan On Thu, Jun 18, 2009 at 8:02 AM, Vladimir Reshetnikov <v.reshetnikov@...> wrote: Hi Andreas. |
|
|
Re: [scala] Conformance to bounds in higher-order type parameters
by andreas s.
::
Rate this Message:
Wow interesting!
I think i remember that "type constructor polymorphism" reading somewhere, need to put it in context. Thanks for sharing! |
| Free embeddable forum powered by Nabble | Forum Help |
