View source for Reducing dependencies in ec

You do not have permission to edit this page, for the following reasons:
The action you have requested is limited to users in one of the groups: Autoconfirmed users, emailconfirmed, editors.
You must confirm your email address before editing pages. Please set and validate your email address through your user preferences.
You can view and copy the source of this page:
[[Category:EiffelStudio]]
[[Category:Compiler]]

= Overview =
Actually the compiler and compiler_api cluster (Src/Eiffel/eiffel and Src/Eiffel/api) are full of unwanted dependencies on other component. What could be really useful is to break those dependencies to be able to have a compiler library (compiler.ecf for instance).
Since this is a long task, we'll go step by step, listing the current issue and bad dependencies on other component (for instance compiler depends on graphical classes, or debugger classes  which are fake in batch ec .. and this is no good).

So please when changing some code in the compiler or in any component, please try to reduce dependencies, when we'll have a compiler.ecf this will be much easier to make sure no bad dependencies are introduced.

= Goal =
move out and break bad dependencies from cluster compiler and compiler_api
= Current issues =
* '''profiler''', '''queries''' and '''query_language''' folders should be moved out of Eiffel/api
 we should create Eiffel/utilities for instance to welcome those 3 folders.

= Compiler library (Work in progress, not ready for review) =


== Defining the Eiffel Compiler's Job ==
The compiler library, as its name suggests, should only contain the compiler. This question is not deep enough. First we must ask '''What is a compiler'''? The question does not refer to to global notion of what is a compiler, as this has many representation by a number of disparate bodies, but must retain most of its logic. That is to say the answer cannot be - '''a mechanism for instilling an inert object with a form of kinetic energy to aid locomotion''' - this is not a compiler. At better question; '''What should an Eiffel compiler do'''?

This page is dedicate to the separation of peripheral tools that used compiled data to produce an output or tools that hook into the compiler to modify the compilation process, from the compiler. Given that, the question '''What should an Eiffel compiler do'''? is discussed in another page [[page]]. The following content will be based on this information.

== What should be included in compiler lib ==
The compiler library should, of course, contain the compiler. This should be in it's most rudimentary form without any attachment to any tool or API that does not perform the job of translating the Eiffel source text (code) into a binary representation, where the binary representation be a final executable on a target system or the generate byte code pending machine code dependent translation.

Although the final executable stage seems logical, by modern definition of the term Compiler this does not have to be the case. Instead of remarking the compiler library as a ''"library"'' it's possible that we should create a framework instead. The framework leaves holes (hooks) for translating the intermediate byte code to a final platform dependent binary.

== Library vs Framework ==
At first creating a library for the compiler seems logical. By convention, in most cases, a compiler takes a collection of encoded files to product, as an end result, a platform dependent binary. Such a concept can be wrapped and delivered in a library. However the Eiffel compiler supports multiple code generation choices. For now, on a Windows platform, there is '''classic''' and '''.NET''' code generation. Although a complete solution, this is not a compact or elegant solution. 

* Non-.NET platforms include dummy class implementation that have to be updated to synchronize changes made for the .NET-applicable platforms class implementation. This is a source of broken builds, bulks the finalize compiler binary size and leads to confusion in the OS community regarding their placement.
* There are tools, such as EiffelEnvision and Eiffel for ASP.NET that do not have a shred of interest in classic code generation, yet are forced to use compiler that support it. In reverse there may be OS tools that compile classic code yet are burdened with .NET code generation classes.

It is therefore considerable to establish the compiler library, instead, as a compiler framework.

The work has already been accomplished to take the Eiffel source text and product an intermediate bytecode representation, subsequently used by both code generators. Such work would lend itself to the possibility of providing a hook to generate code for the respective code-spec (classic or .NET) and/or platform. Such a hook could permit the attachment of an applicable code generator(s) at compile time, without the need to compile in all code generators into the compiler. Such a mechanism can be perform though the use of a simple factory function.

 deferred class COMPILER
 
 feature {NONE} -- Factory
 
     code_generator (a_cfg: SOME_CFG_CLASS): CODE_GENERATOR is
             -- Retrieve code generator for `a_cfg'.
             -- `a_cfg' contains details about compilation and project configuration so the correct
             -- generator can be instantiate.
         require
             a_cfg_attached: a_cfg /= Void
         deferred
         ensure
             result_attached: Result /= Void
         end
 
 end -- class {MY_COMPILER}

With such an approach it could be entirely possible to compile an alternative platform binary on any given platform, permitting the existing of a platform specific code generator and compatible C compiler.

This is not where the argument ends. There needs to be a discussion on the existing compiler and its specific implementation to support multiple platforms. An example if CLASS_I and CLASS_C. They contain attributes that pertain specifically to .NET. Although unavoidable in the currently implementation, there are ways around removing this implementation an proffering it via an extension attribute. Extension attributes are a basic attribute accessible to clients and provider an abstract mean of retrieving extension data. The attribute may be specifically types for clarity or abstractly typed for genericity.

 class CLASS_I
 
 feature -- Access
 
     extension: ANY is
             -- Extension object
         do
             --| Implementation
         end
 
     --| Members elided for clarity
 
 end -- class {CLASS_I}

Alternatively there is the choice of factories for creating abstract objects, which have advantages and disadvantages.

== A Packaged Compiler Framework ==
If the compiler is to be packaged as a framework it should be as simple as possible to get start. The introduction of a deferred '''COMPILER''' class could be the primary extension point for the framework. Any implementation of COMPILER should only reference the rudimentary internals of the Eiffel compiler and not as to compile as little code as possible. As an example, from the example above, if ''code_generator'' was to return a default object which happens to be the code generator for classic and .NET the value of what is trying to be achieved is lost.

All compiler projects should derive COMPILER, implemented all deferred features and redefine any appliable features. The specialized COMPILER implementation should then be used as the root class, or at least a facade for execution of the compiler functions.

== what should be excluded from compiler lib ==
* documentation generation
* debugger manager: in E_PROJECT.melt the debugger_manager is used to refresh breakpoints data : done

= to be continued =

= Using a Service Base Architecture =
One very elegant solution to revoking hardwired dependencies is switching to a service-base architecture. To review details on a proposed service-based framewor implemenation for Eiffel, see [[Implementation of a Service-Base Architecture in Eiffel]].
Return to Reducing dependencies in ec.
Retrieved from "https://dev.eiffel.com/Reducing_dependencies_in_ec"
View source for Reducing dependencies in ec

Navigation

Development

Wiki

Search

Tools
