exp/types revival

[axw...@gmail.com]

Hi folks,

As you may be aware, I'm working on a Go compiler. I commented in a thread

on golang-nuts earlier that I intend to flesh out exp/types, with the goal of having

it added back into the standard library when it's complete. It has been suggested

that I announce my intentions here to avoid duplicated effort.

I don't have much to show yet, but my work in progress lives here:

https://github.com/axw/llgo/tree/master/types 

A few things off the top of my head / out of the commit logs:

- Added basic type kinds, which reference type kinds from reflect.

- Fleshed out Const operators, modified Const type so it's usable externally.

- Modified Name to store methods.

- Added struct field indices for fast lookup.

I'm currently moving some typechecking out of llgo proper into this types

package. Right now I'm working through a few apparent problems with

go/parser.

Cheers,

Andrew

[Andrew Wilkins]

Hi folks,

I'd like to get some feedback before I go ahead and start submitting CL's.

I keep putting this off, so apologies for the slight brain dump.

I want to get some of the basic stuff out of the way so I can focus on the

more significant issues of type checking. So below are the changes I'm proposing.

types.go

======

Complete functionality for the Type structs, and make them all Stringers for debugging.

- Basic: add a Kind field of a new type BasicTypeKind with underlying type reflect.Kind.

- Struct: add a FieldIndices field which maps field names to indices, including anonymous fields.

- Name: add a Methods field which contains an ObjList of methods.

const.go

======

I haven't done a lot here, but here's what I'd like to change:

- Expose Const.val as Const.Val, so external packages can access the values. I'd just

  change it to "type Const interface{}" but I think we may want to revisit the type, so I'd

  rather not spend too much time on it right now.

- Implement unary operators for all types, and binary shift operators for big.Int.

- Add a case for "nil" in the Const.String method.

universe.go

========

Nothing much to see here.

- Fill in the Type field for builtin types (defType will take a BasicTypeKind),

  and fill in Data where it makes sense (e.g. true/false).

gcimporter.go

==========

- Record method signature (Func) as the object's Type.

- Sort and record methods against receiver types.

check.go

=======

This one is obviously the most lacking, and will take several CL's. Here's my plan:

1. Fixes for issues in existing code:

- address the TODO in *ast.SelectorExpr case of makeType.

- compute array length in *ast.ArrayType of makeType. 

- obtain isVariadic from params rather than results in *ast.FuncType of makeType.

- change last parameter type in variadic functions to a Slice of the declared type.

  Presumably this won't cause anyone grief since functions were never properly

  identified as being variadic anyway (see above point).

2. Add in more code for checking objects:

- Address TODO's in checkObj.

- Record struct field indices.

- Record type methods, and associate receivers with corresponding Type.

3. Implement expression and statement checking. I've just begun this, so it's a ways off.

Regards,

Andrew

[Evan Shaw]

On Thu, Jun 28, 2012 at 5:45 AM, Andrew Wilkins <axw...@gmail.com> wrote:
> const.go
> ======
>
> I haven't done a lot here, but here's what I'd like to change:
> - Expose Const.val as Const.Val, so external packages can access the values.
> I'd just
>   change it to "type Const interface{}" but I think we may want to revisit
> the type, so I'd
>   rather not spend too much time on it right now.
> - Implement unary operators for all types, and binary shift operators for
> big.Int.
> - Add a case for "nil" in the Const.String method.

I did some work on this a while back, so depending on how much you've
done I might be able to help. I got far enough that most (maybe all?)
constant declarations could be correctly type checked. I changed Const
to an interface that looks like this:

// A Const implements a constant Value.
type Const interface {
// Match attempts to match the internal constant representations of
the receiver and y.
// If the attempt is successful, the result is the values of the
receiver and y,
// if necessary converted to have the same internal representation; otherwise
// the results are nil.
Match(y Const) (u, v Const)

// Convert attempts to convert the receiver to a given type.
// The explicit parameter indicates whether the conversion is explicit.
// If the attempt is successful, the result is the new constant;
// otherwise the result is nil.
Convert(typ Type, explicit bool) Const

String() string

// UnaryOp applies a unary operator to the receiver and
returns the result.
// If op is an invalid unary operator, the result is nil.
UnaryOp(op token.Token) Const

// BinaryOp applies a binary operator to the receiver and y
and returns the result.
// If op is an invalid binary operator, the result is nil.
BinaryOp(op token.Token, y Const) Const
}

The only thing that might not be obvious is Convert's explicit
parameter. It's necessary to distinguish these cases:

const s1 string = 1 // not explicit, illegal
const s2 = string(1) // explicit, legal

In any case, I'd be very happy to see this package finished.

- Evan

[Andrew Wilkins]

On Thu, Jun 28, 2012 at 11:53 PM, Evan Shaw <eds...@gmail.com> wrote:

I did some work on this a while back, so depending on how much you've
done I might be able to help. I got far enough that most (maybe all?)
constant declarations could be correctly type checked. I changed Const
to an interface that looks like this:

 

Thanks, Evan, your interface looks pretty sensible to me so I'll keep this in

mind as I get further into type checking. So far I've been focused more on

generating types from the AST and associating them with objects, rather

than checking their validity.

Regards,

Andrew 

[Robert Griesemer]

Apologies for the late reply.

I think this sounds reasonable, looking forward to the individual CLs. Please keep them small for a reasonably quick turn-around.

One thing I would like to suggest if you are actively working on this: It would be nice to have a write-up of your basic mental model as you make changes as it will make it possible for others to understand the architecture of the data structures (I'm guilty as charged). It will make it easier to reason about the design and show redundancies and inconsistencies. It could be a drawing of the connections between the various internal data structures.

- gri

On Thu, Jun 28, 2012 at 5:45 AM, Andrew Wilkins <axw...@gmail.com> wrote:

[Andrew Wilkins]

On Tue, Jul 3, 2012 at 6:57 AM, Robert Griesemer <g...@golang.org> wrote:

Apologies for the late reply.

No worries, I assumed you were all having fun at I/O ;)

 

I think this sounds reasonable, looking forward to the individual CLs. Please keep them small for a reasonably quick turn-around.

Thanks, will do. I need to write some tests, then I'll start sending them in.

One thing I would like to suggest if you are actively working on this: It would be nice to have a write-up of your basic mental model as you make changes as it will make it possible for others to understand the architecture of the data structures (I'm guilty as charged). It will make it easier to reason about the design and show redundancies and inconsistencies. It could be a drawing of the connections between the various internal data structures.

Sounds like a plan. I'll start a Google doc and report back when I have something of substance.

Andrew