Introduction - Metals - Meta Programming Language System

Metals: A Meta Programming Language for Composable Systems

Metals is a library that provides the meta programming language foundation for domain modeling and schema management.

The powerful meta modeling capabilities provided by this library will power the next generation of distributed, compositional cloud computing environment.

Domains and Modeling in Computation

A domain is a field or an area under investigation. In a computational context, we are interested in developing computational models of domains in the real world and use these models to build solutions to a set of identified problems.

Modeling or model development is the first step in any project. They are essential to communication among stakeholders and used throughout the development process. They may be formal or informal, documented or not, explicit or implicit. In a way, they are like spoken language! We use it pretty much during the course of all our activities, without conscious awareness of their existence or use most of the time.

The power of models essentially decides the type of problems we can address and the quality of our solutions.

Key ideas

The domain modeling capabilities and the required meta programming support within metals are based on the following key ideas.

Simple models, complex domains: Models based on simple rules can exhibit complex behavior. Ability to model domains of arbitrary complexity does not necessarily mean that the models have to be unreasonably complex as well. We strive to promote simple models throughout.
Compositional models: Complex models are compositionally built from simpler ones. It is our fundamental belief that the compositionality of our mental models underlie the extraordinary human cognitive capabilities.
Context Aware Computing: Next to compositionality, context awareness or mode dependent computation is the most important aspect of the computational models supported by metals. This is especially important in the context of distributed, heterogeneous computing environments. The models are not used by a single system or environment as we traditionally assume when we build computational models.
Combinatorial generalization: the ability to learn increasingly complex concepts by synthesizing simple ideas, enabling both rapid learning and adaptation of knowledge

Our goals

The modeling capabilities provided by metals shall meet the following goals.

Enable Communication: The models should serve as the communication medium between different teams, especially with domain experts. We shall not expect any programming expertize from the domain experts or other teams outside of the development or engineering teams, nor shall we want the developers to leave their tools of choice and familiarity to build communication models.
Modeling Data and Behaviors: The models should be able to represent both data and their associated behaviors. The compositionality and combinatorial generalization shall apply to both data and behaviors.
Executable models: The models should be executable. It should be possible to convert the models developed through collaborative modeling process to executable artifacts with minimal effort.
Make Illegal States Unrepresentable: The models should be able to capture the domain constraints explicitly and make all illegal states unrepresentable. The models should fully and faithfully represent the domain constraints so that they can serve as a single source of truth about accuracy our requirements and the subsequent implementation.
Uniform Structured representations: The modeling language shall support structured representations that can be used across heterogeneous environments. The models should be able to provide uniform view of the domain across many boundaries that exists in the development and runtime environments such as programming languages, frameworks, platforms, networks, etc.
Lazy Evaluation and Transparency: A state represented in the model shall be evaluated lazily in a location transparent way. When one models a domain, the domain objects represent data that eventually resolve to appropriate values, not necessarily eagerly computed. For example, when one refers to a User in the model, it could be an object that is returned by a network call or a database query. The models should be able hide such details. The transparency also means that the model builders are not burdened by idiosyncrasies such as different query semantics, implementation details and access protocols of the underlying systems or environment.
Distributed and Independently Evolving Models: Building a uniform model for a given application does not necessarily mean a single global model. Global models are complex to build and a nightmare to maintain. Our goal is to support smaller, distributed models that can evolve independently. An application (or solution) context will be able import the relevant models and create a unified view of the domain as it pertains to that application.

We will look into some of the modeling challenges, prevailing techniques, and how we approach them in metals.