Polymorphism is an umbrella term to denote number of techniques across different programing paradigms. They all share the same intention to provide ability easily recombine software components in a different way with as little as possible manual work on developer's side. It serves two major goals: specialization, when software, initially designed to support wide range of use cases, is configured for concrete particular case and extension - adapting software to an environment and conditions it was not specifically designed for. In course of software engineering evolution, number of polymorphism techniques was proposed and experimented with, all suited for different use-cases. Xreate presents generalized and elegant approach that exhaustively covers wide landscape of polymorphism variations. Polymorphism in Xreate can be applied on two levels: Functions level. Function in Xreate can have a multiple specializations and polymorphism is compiler's ability to decide which exactly specialization to use depending on various factors Modules level. Multiple modules can provide the same service for users. Modules Resolution is a process to decide which exactly module to use

Basic idea is to allow developer to define several functions with the same name or, in other words, several specializations. Caller code then invokes necessary function by its shared name but can't directly specify particular specialization. Exact specialization to be invoked is decided later by decision process called polymorphism resolution carried out by Transcend. This indirect invocation approach gives enough flexibility to use or replace different specializations depending on various conditions during compile time as well as at runtime. Please refer to syntax for details about function specializations. Each specialization must have unique guard(among all specializations with the same name) to be discernible from others. To summarize, function invocation is a two layered process, in which client code specifies callee function's shared name, and polymorphism resolution specifies specialization guard if needed. For an example, assume that we develop program to operate under specified time constraints. To model implementation suitable for real time environment, one specialization of crucialOperation is defined with env(realtime) guard i.e. satisfies some fixed execution time constraints. Caller main specifies only function name crucialOperation thus delegating decision on guard to a polymorphism resolution done elsewhere, based on environment's constraints the code is executed in. guard:: env(realtime) { crucialOperation = function:: int { 0 } } main = function:: int; entry { crucialOperation() }

SYNTAX: **dfa_callguard**(//call-site-ref//, //guard//) call-site-ref reference to a call site in AST guard resolved function specialization guard When compiler encounters function invocation that has several specialization it refers to the table dfa_callguard to find out which specialization to call. It must have entry with appropriate guard for every invocation site call-site-ref of a polymorphic function. Polymorphism resolution is a process of filling out dfa_callguard for a compiler based on custom Transcend rules reflecting one or another polymorphism strategy.

Late Polymorphism is an extension to allow polymorphism resolution to be based on data known only at runtime, i.e. resolve function specializations dynamically. The Idea is to use Late Transcend to access runtime data. See Late Transcend for details. Example below demonstrates test invoking polymorphic function compute: Strategy = type variant {fast, precise}. guard:: fast { compute = function:: int {0} } guard:: precise { compute = function:: int {1} } test = function(s:: Strategy; alias(strategy)):: int; entry { switch late (s):: int { compute():: int; guardalias(strategy) } } Function compute has two specializations, fast and precise. We see that test gets parameter s that dictates exact strategy to use. Clearly, resolution should work dynamically to cope with cases like this, for value of parameter s not only is unknown at compile time, but it can change with each test execution. Operation Switch Late is compiled into several branches, two in this case, each branch executing appropriate compute specialization. Correct branch executed depending on current s value. Custom annotations alias(Alias) and guardalias(Alias) used to assign an alias in order to specify which parameter to use for as basis for resolution

In previous example, switch late operation was used to facilitate calling of polymorphic function with late polymorphism resolution. It's not that convenient to wrap each invocation by switch late whenever there is need to call late polymorphic function. Specifically to handle cases like this, compiler uses late parameter auto expansion technique. If compiler discovers that late(dfa_callguard()) entry exists for current invocation and it does not have enclosing switch late already, compiler automatically generates different branches that invoke relevant specializations and transfers control to a branch depending on late parameter value. In other words invocation implicitly wrapped into switch late instruction if needed.