The Artima Developer Community
Sponsored Link

Weblogs Forum
A-Posteriori Subtyping and Case Classes

23 replies on 2 pages. Most recent reply: Jan 30, 2006 11:14 AM by James Watson

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 23 replies on 2 pages [ « | 1 2 ]
Martin Odersky

Posts: 84
Nickname: modersky
Registered: Sep, 2003

Re: A-Posteriori Subtyping and Case Classes Posted: Jan 29, 2006 2:37 PM
Reply to this message Reply
Advertisement
> The following is lifted from <a
&gt; href="http://scala.epfl.ch/intro/caseclasses.html">http://s
> cala.epfl.ch/intro/caseclasses.html</a>:
>
> <blockquote>
> Scala supports the notion of case classes. Case classes
> are regular classes which export their constructor
> parameters and which provide a recursive decomposition
> mechanism via pattern matching.
>
> Here is an example for a class hierarchy which consists of
> an abstract super class Term and three concrete case
> classes Var, Fun, and App.
>
> <pre>
> abstract class Term;
> case class Var(name: String) extends Term;
> case class Fun(arg: String, body: Term) extends Term;
> case class App(f: Term, v: Term) extends Term;
> </pre>
> </blockquote>
>
> Okay, that is fine, but why not have something like the
> following :
>
> <pre>
> class Var { ... }
> class Fun { ... }
> class App { ... }
>
> casetype Term {
> Var;
> Fun;
> App;
> }
> </pre>
>
How are you proposing to handle constructor parameters?
The `case' in a case class essentially tells two things to a Scala compiler:

(1) Define a tag method for instances of the class, so that case selection can be done more quickly.

(2) Keep the constructor parameters around, so that they can be recovered by a pattern match.

Aspect (1) is just an optimization; it can probably be handled by other means. But (2) is different, since it changes the interface of a program. For instance, you might not want to publish the way objects of some class are constructed. In Scala, that's no problem; just don't add a `case' modifier to your class.

In summary, I think case classes are the right abstraction
if you want to retrieve constructor parameters in a pattern match. If you do not care about that, then a simple typecase would do just as well.

Cheers

-- Martin

Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

Re: A-Posteriori Subtyping and Case Classes Posted: Jan 29, 2006 3:41 PM
Reply to this message Reply
> How are you proposing to handle constructor parameters?

My proposed case type can not be constructed. Just like a pure abstract base class. You use it as a reference to one of the supertypes in its list.

So:


class Fu {
public {
def _init(int n) { }
}
}

class Bar {
public {
def _init(string s) { }
}
}

casetype FuBar {
Fu;
Bar;
}

FuBar* fb1 = new Fu(42);
FuBar* fb2 = new Bar("fourty-two");


> The `case' in a case class essentially tells two things to
> a Scala compiler:
>
> (1) Define a tag method for instances of the class, so
> that case selection can be done more quickly.
>
> (2) Keep the constructor parameters around, so that they
> can be recovered by a pattern match.
>
> Aspect (1) is just an optimization; it can probably be
> handled by other means. But (2) is different, since it
> changes the interface of a program. For instance, you
> might not want to publish the way objects of some class
> are constructed. In Scala, that's no problem; just don't
> add a `case' modifier to your class.

Yes, I am sorry I wasn't clear about that. The Scala abstraction is actually quite sophisticated. The pattern matching of constructor parameters is very sophisticated.

> In summary, I think case classes are the right
> abstraction
> if you want to retrieve constructor parameters in a
> pattern match. If you do not care about that, then a
> simple typecase would do just as well.

Pardon my ignorance but what is a typecase?

On a slightly different topic how do you define a new subtype in Scala without modifying the supertype's declaration?

PS

Martin, I hope you will consider putting up a blog at Artima, I would love to read it, and I know many other people would be interested as well.

Kannan Goundan

Posts: 18
Nickname: cakoose
Registered: Nov, 2005

Re: A-Posteriori Subtyping and Case Classes Posted: Jan 30, 2006 2:59 AM
Reply to this message Reply
Since the "Term" type identifier doesn't have any properties, it's not really subtyping. It's just syntactic sugar over the standard tagged union. The Haskell syntax is something like:


type Var = ...
type Fun = ...
type App = ...

data Term = VarT Var | FunT Fun | AppT App


The sytactic sugar: the tag names are automatically derived from the type names and the values automatically get tagged when passed as "Term" parameters.

Martin Odersky

Posts: 84
Nickname: modersky
Registered: Sep, 2003

Re: A-Posteriori Subtyping and Case Classes Posted: Jan 30, 2006 4:14 AM
Reply to this message Reply
> Pardon my ignorance but what is a typecase?
>
It's just a switch statement but with types as tags. Something like the following Scala code:

foo match {
  case v: Var => ...
  case f: Fun => ...
  ...
}


Here, Var and Fun need not be case classes. An alternative will be taken if foo has the type given in the label. In the literature, one often uses `typecase' instead of `switch' or `match' for this.

> On a slightly different topic how do you define a new
> subtype in Scala without modifying the supertype's
> declaration?
>
You mean "define a supertype without modifying the subtype's declaration"? It cannot be done directly, but you can define an implicit conversion:

  implicit def a2b(x: a): b = ...

The conversion will be applied in the scope where it is visible whenever you have a value of type `a' but require an value of type `b'.

> PS
>
> Martin, I hope you will consider putting up a blog at
> Artima, I would love to read it, and I know many other
> people would be interested as well.

Thanks for the encouragement! I'll consider it; its just a matter of finding the time to do it.

-- Martin

Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

Re: A-Posteriori Subtyping and Case Classes Posted: Jan 30, 2006 8:45 AM
Reply to this message Reply
> Here, Var and Fun need not be case classes. An alternative
> will be taken if foo has the type given in the label. In
> the literature, one often uses `typecase' instead of
> `switch' or `match' for this.

Okay, I see like Modula 3.

> > On a slightly different topic how do you define a new
> > subtype in Scala without modifying the supertype's
> > declaration?
> >
> You mean "define a supertype without modifying the
> subtype's declaration"?

Yes, sorry about that mistake.

> It cannot be done directly, but
> you can define an implicit conversion:
>
>
>   implicit def a2b(x: a): b = ...
> 

> The conversion will be applied in the scope where it is
> visible whenever you have a value of type `a' but require
> an value of type `b'.

Implicit conversions aren't quite a mechanism for subtyping though, because you don't get the additional methods do you?

a.methodBelongingToB(); // compile error.
implicit def a2b(x: a): b = ...
a.methodBelongingToB(); // compile error?

Do any languages you know support the kind of a-posteriori subtyping I am describing? Is it interesting enough to publish about? Are there other names for it? Sorry for the barrage of questions, but thanks for your help.

Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

Re: A-Posteriori Subtyping and Case Classes Posted: Jan 30, 2006 8:50 AM
Reply to this message Reply
> Since the "Term" type identifier doesn't have any
> properties, it's not really subtyping. It's just
> syntactic sugar over the standard tagged union.

But if I allow methods, then it would be subtyping, wouldn't it?

> The
> Haskell syntax is something like:
>
>
> type Var = ...
> type Fun = ...
> type App = ...
>
> data Term = VarT Var | FunT Fun | AppT App
>

>
> The sytactic sugar: the tag names are automatically
> derived from the type names and the values automatically
> get tagged when passed as "Term" parameters.

Thanks for pointing out the Haskell syntax.

Martin Odersky

Posts: 84
Nickname: modersky
Registered: Sep, 2003

Re: A-Posteriori Subtyping and Case Classes Posted: Jan 30, 2006 9:34 AM
Reply to this message Reply
> a.methodBelongingToB(); // compile error.
> implicit def a2b(x: a): b = ...
> a.methodBelongingToB(); // compile error?
>
This works in fact. An implicit conversion is also applied when a selector name is not defined in some expression. This can handle your example. On the other hand, we cannot deal with overriding that way; that's where implicit conversions hit a limit.

> Do any languages you know support the kind of a-posteriori
> subtyping I am describing? Is it interesting enough to
> publish about? Are there other names for it? Sorry for the
> barrage of questions, but thanks for your help.

AFAIK you could do this in Sather.

Cheers

-- Martin

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: A-Posteriori Subtyping and Case Classes Posted: Jan 30, 2006 9:45 AM
Reply to this message Reply
> > One moe thing, would the case (type) syntax be
> statically
> > bound?
>
> I don't understand precisely what you mean. If you are
> asking as to whether the type relationships are determined
> at compile-time the answer is no.

Then, in a way, this kind of acts like a form of double-dispatch.

I like the idea, but I don't care for implicitly casting inside the case blocks. It's unecessary.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: A-Posteriori Subtyping and Case Classes Posted: Jan 30, 2006 11:14 AM
Reply to this message Reply
> I like the idea, but I don't care for implicitly casting
> inside the case blocks. It's unecessary.

I mean 'explicitly casting'.

Flat View: This topic has 23 replies on 2 pages [ « | 1  2 ]
Topic: If You're Not Going to Upgrade It, Don't Use It Previous Topic   Next Topic Topic: JavaScript Reference


Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us