"type" is both declaration and literal

[kjx]

the type keyword is used for two different things: marking out type constructor expressions

 type { 
   foo -> Done 
   bar -> Done
 }

and declaring types:

 type FooBar = { 
   foo -> Done 
   bar -> Done
 }

Should we steal Go's design, and change the type constructor keyword to interface https://golang.org/ref/spec#Interface_types . This would give us

 interface { 
   foo -> Done 
   bar -> Done
 }

and declaring types:

 type FooBar = interface { 
   foo -> Done 
   bar -> Done
 }

[kjx]

If interface is to long, we could use struct or functor :-)

[apblack]

I don't see any problem with using the same keyword to mean multiple things in different contexts. In general, the fewer keywords the better, since a word reserved to be a keyword can't be used for any other purpose.

interface is too long. We also want to get students to understand that in OO languages, types are interfaces, not structures. Right now I can stand in front of a class and say "types are interfaces". If we use the word interface to mean something else, then I can't say that any more without being guilty of moral turpitude. (See Reynolds' "Types, Abstraction and Parametric Polymorphism")

[KimBruce]

I was sad when we were forced to introduce type on the right side of type declarations, e.g.,

type A = B & type { … }

because of parsing issues (ambiguity) and wish we could go back to leaving it off. I agree with Andrew that it’s OK in this situation to use the same keyword twice. Let’s leave it as it is.

On Feb 14, 2016, at 10:48 AM, Andrew Black notifications@github.com wrote:

I don't see any problem with using the same keyword to mean multiple things in different contexts. In general, the fewer keywords the better, since a word reserved to be a keyword can't be used for any other purpose.

interface is too long. We also want to get students to understand that in OO languages, types are interfaces, not structures. Right now I can stand in front of a class and say "types are interfaces". If we use the word interface to mean something else, then I can't say that any more without being guilty of moral turpitude. (See Reynolds' "Types, Abstraction and Parametric Polymorphism" http://www.cse.chalmers.se/edu/year/2010/course/DAT140_Types/Reynolds_typesabpara.pdf)

— Reply to this email directly or view it on GitHub https://github.com/gracelang/language/issues/42#issuecomment-183949086.

[kjx]

interface is too long.

It's longer than I'd like, but Go has picked it.

Right now I can stand in front of a class and say "types are interfaces"

type T = interface { 
   blah 
}

reads to me like type T is the following interface!

We also want to get students to understand that in OO languages, types are interfaces, not structures.

But in Grace, unless we change something, type are not just interfaces. In one of the last remaining algebraic features, our retained union type T = A | B retains memory that T is either an A and B, in a way that type T = A + B does not. You can't explain A | B as just an interface.

[apblack]

But in Grace, unless we change something, type are not just interfaces. In one of the last remaining algebraic features, our retained union type T = A | B retains memory that T is either an A and B, in a way that type T = A + B does not. You can't explain A | B as just an interface.

You are right. I hate that too. Do you want to open another issue to get rid of it (the | combinator on types)?

[kjx]

Andrew - not when Kim has just commented on #14 that here prefers using | to any kind of Maybe.

[kjx]

Kim - I recall it's not just a parsing issue, it's also about language design.

{ } brackets without a directly preceding keyword mean blocks inside methods. Outside methods, they're also used to group method bodies etc technically after the method keyword.

[apblack]

Ok, I guess that I'll have to learn to say that a type literal describes an interfere, whereas a type is, technically, a disjunction of interfaces. See issue #48.

But I still think that we can keep the type keyword for both.

[kjx]

We can keep the type keyword for both: the question is whether we should or not?

[apblack]

I don't see an overpowering reason to change it.

[apblack]

I've changed my mind about this. Why? Because I'm thinking about teaching interfaces and types.

I've had my head in the sand about this because I kept hoping that the distinction would go away. In my ideal Gra language it would go away, but I'm now convinced that the distinction between a type and an interfaces is here to stay in Grace.

What we have been calling type literals actually describe interfaces, and in Grace, while interfaces are types, types are not interfaces but disjunctions of interfaces. This would be easier to teach if we used different names for the different concepts.

[KimBruce]

Types are essentially disjunctions of interfaces. That is how we defined them. 90% of the time it is a single interface, but sometimes it is more. I don't see that as a problem.

[kjx]

I wonder if Interface seems like a long word, as in:

type Foo = interface { 
    blah
}

other options are signature, which nicely abbreviates to sig.

type Foo = sig {
   d
   c
   b 
}

[apblack]

I like using "signature" to describe the type of a single method, and interface to describe a set of signatures. Type would be a disjunction of interfaces, as Kim said, or maybe a disjunction of interfaces or "singles" (based on our most recent conversation).

I think that it would help to be consistent in our terminology, and for the keywords to correspond to the terminology.

[kjx]

I like using "signature" to describe the type of a single method, and interface to describe a set of signatures.

me too.

[KimBruce]

I think we're in violent agreement! (Though I don't know how to signal it aside from closing this stream.)

[kjx]

just to check: violent agreement about changing to "interface" as the keyword for a type literal, and "type" as the keyword for a type declaration

[KimBruce]

Yes

[kjx]

OK!! hurrah!