Abstract Types vs. Type Parameters

On 27/05/2009, at 10:01 AM, Randall R Schulz wrote:

> Can someone either explain to me or recommend something to read that
> will explain the distinction between abstract types and type
> parameters? In particular, what things are possible with one but not
> the other. More generally, why do both exist? (Presumably there are
> things one can express or capture that the other cannot.)

There's a bit of a discussion of this in the Appendix of [1],
particularly
in section "Modeling generics with abstract types".

[1] Odersky, M., and Zenger, M. Scalable component abstractions. In
Proceedings
of ACM Conference on Object-Oriented Programming, Systems, Languages and
Applications (2005).

cheers,
Tony

On Tuesday May 26 2009, Tony Sloane wrote:
> On 27/05/2009, at 10:01 AM, Randall R Schulz wrote:
> > Can someone either explain to me or recommend something to read
> > that will explain the distinction between abstract types and type
> > parameters? In particular, what things are possible with one but
> > not the other. More generally, why do both exist? (Presumably there
> > are things one can express or capture that the other cannot.)
>
> There's a bit of a discussion of this in the Appendix of [1],
> particularly in section "Modeling generics with abstract types".
>
> [1] Odersky, M., and Zenger, M. Scalable component abstractions. In
> Proceedings of ACM Conference on Object-Oriented Programming, Systems,
> Languages and Applications (2005).

Thanks. That paper is in my library, though I'd barely glanced at it
before now. If I read that section correctly, type parameters are
technically strictly syntactic sugar for (admittedly less succinct)
abstract type declarations and definitions, though to dismiss them as
mere notational convenience is at least somewhat overstating the case.

Since higher-kinded types appeared subsequent to that paper, I wonder
if, and if so how, that section must now be modified.

I am (potentially) somewhat concerned because a large proportion of the
papers I can find that explicitly use Scala to develop their ideas and
they often use constructs from the language that are no longer
supported (in the form used in the publication). E.g., the "requires T"
clause that is now encoded with "this: T =>" appears even in the this
very paper. I see now-archaic constructs in many papers at least as
late as 2006.

> cheers,
> Tony

Randall Schulz

I got a vague feeling that the fundamental answer to this is the lambda-cube, and the rest kind of follows.

2009/5/26 Randall R Schulz <rschulz@sonic.net>

Hi,

Can someone either explain to me or recommend something to read that
will explain the distinction between abstract types and type
parameters? In particular, what things are possible with one but not
the other. More generally, why do both exist? (Presumably there are
things one can express or capture that the other cannot.)


Randall Schulz

--
Thanks,
-Vlad

Abstract type members

Bill Venners: In Scala, a type can be a member of another type, just as methods and fields can be members of a type. And in Scala those type members can be abstract, like methods can be abstract in Java. Is there not some overlap between abstract type members and generic type parameters? Why does Scala have both? And what do abstract types give you beyond what the generics give you?

Martin Odersky: ...

http://www.artima.com/scalazine/articles/scalas_type_system.html

2009/5/27 Randall R Schulz <rschulz@sonic.net>

Hi,

Can someone either explain to me or recommend something to read that
will explain the distinction between abstract types and type
parameters? In particular, what things are possible with one but not
the other. More generally, why do both exist? (Presumably there are
things one can express or capture that the other cannot.)


Randall Schulz

--
Rob, Lafros.com

On Tuesday May 26 2009, Vlad Patryshev wrote:
> 2009/5/26 Randall R Schulz
> > Hi,
> >
> > Can someone either explain to me or recommend something to read
> > that will explain the distinction between abstract types and type
> > parameters? In particular, what things are possible with one but
> > not the other. More generally, why do both exist? (Presumably there
> > are things one can express or capture that the other cannot.)
> >
> >
> > Randall Schulz
>
> I got a vague feeling that the fundamental answer to this is the
> lambda-cube, and the rest kind of follows.

OK, I'll bite. What is "the lambda-cube?"

RRS