2016-11-16 22:11:58 +01:00
|
|
|
// Copyright 2016 Marapongo, Inc. All rights reserved.
|
|
|
|
|
|
|
|
package compiler
|
|
|
|
|
|
|
|
import (
|
|
|
|
"github.com/marapongo/mu/pkg/ast"
|
|
|
|
)
|
|
|
|
|
|
|
|
// Symbol is a named entity that can be referenced and bound to.
|
|
|
|
type Symbol struct {
|
2016-11-17 03:55:20 +01:00
|
|
|
Kind SymbolKind // the kind of symbol.
|
|
|
|
Name ast.Name // the symbol's unique name.
|
|
|
|
Node *ast.Node // the Node part of the payload data structure.
|
|
|
|
Real interface{} // the real part of the payload (i.e., the whole structure).
|
2016-11-16 22:11:58 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
// SymbolKind indicates the kind of symbol being registered (e.g., Stack, Service, etc).
|
|
|
|
type SymbolKind int
|
|
|
|
|
|
|
|
const (
|
Bind properties that refer to types
A stack property can refer to other stack types. For example:
properties:
gateway:
type: aws/ec2/internetGateway
...
In such cases, we need to validate the property during binding,
in addition to binding it to an actual type so that we can later
validate callers who are constructing instances of this stack
and providing property values that we must typecheck.
Note that this binding is subtly different than existing stack
type binding. All the name validation, resolution, and so forth
are the same. However, notice that in this case we are not actually
supplying any property setters. That is, internetGateway is not
an "expanded" type, in that we have not processed any of its templates.
An analogy might help: this is sort of akin referring to an
uninstantiated generic type in a traditional programming language,
versus its instantiated form. In this case, certain properties aren't
available to us, however we can still use it for type identity, etc.
2016-12-03 20:14:06 +01:00
|
|
|
SymKindService SymbolKind = iota
|
|
|
|
SymKindStack
|
Custom types, round 1
This change overhauls the core of how types are used by the entire
compiler. In particular, we now have an ast.Type, and have begun
using its use where appropriate. An ast.Type is a union representing
precisely one of the possible sources of types in the system:
* Primitive type: any, bool, number, string, or service.
* Stack type: a resolved reference to an actual concrete stack.
* Schema type: a resolved reference to an actual concrete schema.
* Unresolved reference: a textual reference that hasn't yet been
resolved to a concrete artifact.
* Uninstantiated reference: a reference that has been resolved to
an uninstantiated stack, but hasn't been bound to a concrete
result yet. Right now, this can point to a stack, however
eventually we would imagine this supporting inter-stack schema
references also.
* Decorated type: either an array or a map; in the array case, there
is a single inner element type; in the map case, there are two,
the keys and values; in all cases, the type recurses to any of the
possibilities listed here.
All of the relevant AST nodes have been overhauled accordingly.
In addition to this, we now have an ast.Schema type. It is loosely
modeled on JSON Schema in its capabilities (http://json-schema.org/).
Although we parse and perform some visitation and binding of these,
there are mostly placeholders left in the code for the interesting
aspects, such as registering symbols, resolving dependencies, and
typechecking usage of schema types.
This is part of the ongoing work behind marapongo/mu#9.
2016-12-06 23:49:47 +01:00
|
|
|
SymKindUninstStack
|
|
|
|
SymKindSchema
|
2016-11-16 22:11:58 +01:00
|
|
|
)
|
|
|
|
|
|
|
|
func NewServiceSymbol(nm ast.Name, svc *ast.Service) *Symbol {
|
2016-11-17 03:55:20 +01:00
|
|
|
return &Symbol{SymKindService, nm, &svc.Node, svc}
|
2016-11-16 22:11:58 +01:00
|
|
|
}
|
2016-11-25 21:58:29 +01:00
|
|
|
|
Bind properties that refer to types
A stack property can refer to other stack types. For example:
properties:
gateway:
type: aws/ec2/internetGateway
...
In such cases, we need to validate the property during binding,
in addition to binding it to an actual type so that we can later
validate callers who are constructing instances of this stack
and providing property values that we must typecheck.
Note that this binding is subtly different than existing stack
type binding. All the name validation, resolution, and so forth
are the same. However, notice that in this case we are not actually
supplying any property setters. That is, internetGateway is not
an "expanded" type, in that we have not processed any of its templates.
An analogy might help: this is sort of akin referring to an
uninstantiated generic type in a traditional programming language,
versus its instantiated form. In this case, certain properties aren't
available to us, however we can still use it for type identity, etc.
2016-12-03 20:14:06 +01:00
|
|
|
func NewStackSymbol(nm ast.Name, stack *ast.Stack) *Symbol {
|
|
|
|
return &Symbol{SymKindStack, nm, &stack.Node, stack}
|
|
|
|
}
|
|
|
|
|
Custom types, round 1
This change overhauls the core of how types are used by the entire
compiler. In particular, we now have an ast.Type, and have begun
using its use where appropriate. An ast.Type is a union representing
precisely one of the possible sources of types in the system:
* Primitive type: any, bool, number, string, or service.
* Stack type: a resolved reference to an actual concrete stack.
* Schema type: a resolved reference to an actual concrete schema.
* Unresolved reference: a textual reference that hasn't yet been
resolved to a concrete artifact.
* Uninstantiated reference: a reference that has been resolved to
an uninstantiated stack, but hasn't been bound to a concrete
result yet. Right now, this can point to a stack, however
eventually we would imagine this supporting inter-stack schema
references also.
* Decorated type: either an array or a map; in the array case, there
is a single inner element type; in the map case, there are two,
the keys and values; in all cases, the type recurses to any of the
possibilities listed here.
All of the relevant AST nodes have been overhauled accordingly.
In addition to this, we now have an ast.Schema type. It is loosely
modeled on JSON Schema in its capabilities (http://json-schema.org/).
Although we parse and perform some visitation and binding of these,
there are mostly placeholders left in the code for the interesting
aspects, such as registering symbols, resolving dependencies, and
typechecking usage of schema types.
This is part of the ongoing work behind marapongo/mu#9.
2016-12-06 23:49:47 +01:00
|
|
|
func NewUninstStackSymbol(nm ast.Name, ref *ast.UninstStack) *Symbol {
|
|
|
|
return &Symbol{SymKindUninstStack, nm, &ref.Node, ref}
|
|
|
|
}
|
|
|
|
|
|
|
|
func NewSchemaSymbol(nm ast.Name, schema *ast.Schema) *Symbol {
|
|
|
|
return &Symbol{SymKindSchema, nm, &schema.Node, schema}
|
2016-11-25 21:58:29 +01:00
|
|
|
}
|