Closed HeuristicLab-Trac-Bot closed 14 years ago
I take the chance to describe some of my views in this ticket. I believe there are strong symmetries in the current evaluation model of HL and the evaluation model of Scheme. So the ideas I pursued the last few days are mainly about adapting the way name-binding is handled in Scheme for HL. This is in line with the idea of what we called 'Call'-objects in our previous discussion leading to ticket #57. The main concept being to move the functionality of scopes into two separate entities. My view is that scopes mix two separate concepts:
- Grouping simple values to an collection of values (which are moved and destroyed together)
a. Binding of names to values a. Binding of formal and actual names (over multiple steps)
The rough idea is to move bindings to 'environments' or 'frames' which are created by the engine for each application of an operator to a scope. The engine stores the mapping of actual to formal names for the current operator in the environment. Environments can be hierarchically linked (for instance when using
CombinedOperators
). In the new model the scopes would only store variables in a structured and easily navigable data-structure same as now. Bindings in environments point to the data in the scope-tree. We could probably implement this almost in the same way as it is implemented in the scopes now.However the environment-model is probably bad in our situation. We have to remember that the scope-tree was designed especially in this way to make parallelization easy. The scheme environment-model is definitely not adequate for this and would have to be stripped down severely to prevent problems. There are also other minor issues that I won't discuss in this ticket. It should suffice to say that it gets messy quickly.
Anyway my conclusion for now is that while we might copy some smaller ideas from scheme it's probably not possible fully adapt the evaluation model of HL to it. Further discussions are needed.
Removed branch "Operator Architecture Refactoring" in r878 (not migrated) and created it again in r879.
Milestone 3.2 deleted
Removed branch "Operator Architecture Refactoring" in r1991 (not migrated).
Created branch "Operator Architecture Refactoring" again in r1992. Finally, the time has come to get this done!!!
Replying to [comment:20 swagner]:
Continued refactoring in r2033. When you are using the GC memory handles, they might actually change while you use them. Why not simply use plain old references to all already objects? They are safer and more transparent and will get rid of the need for GUIDs or ids alltogether.
Replying to [comment:21 epitzer]:
Replying to [comment:20 swagner]:
Continued refactoring in r2033. When you are using the GC memory handles, they might actually change while you use them. Why not simply use plain old references to all already objects? They are safer and more transparent and will get rid of the need for GUIDs or ids alltogether.
OK, I will change this according to your suggestion.
Starting to commit first results from the refactoring of HeuristicLab.Core and related plugins. Multiple commits will follow now. Please note that the HeuristicLab 3.3 solution might not build until all commits are done.
Finished committing first results from the refactoring of HeuristicLab.Core and related plugins.
NOTE: Not all plugins in the HeuristicLab 3.3 solution have already been adapted to these changes. Therefore they will NOT build at the moment and have to be unloaded in the solution.
Started to adapt HeuristicLab.Data and HeuristicLab.Operators in r2663.
Abandoned policy that the names of all abstract base classes have to end with "Base" in r2664. Renaming of all base classes has to be carried out in some other plugins such as HeuristicLab.PluginInfrastructure or HeuristicLab.MainForm as well.
Unified visual appearance of views and continued work on HeuristicLab.Data in r2676.
Continued work on HeuristicLab.Data and HeuristicLab.Operators in r2684.
Started to implement ideas which came up during today's presentation of HeuristicLab.Core and related plugins in r2687.
Finished to implement ideas which came up during yesterday's presentation of HeuristicLab.Core and related plugins in r2694.
Added two new plugins for parameters and parameter views in r2714.
Adapted on parameters to be able to use generic content types of views in r2715.
Worked on content definitions of views and corrected a bug when cloning a CombinedOperator in r2727.
Fixed hint path for external libraries used in HeuristicLab.Persistence in r2731.
Added extension method to pretty print type names in r2739.
Issue migrated from trac ticket # 95
milestone: HeuristicLab 3.3.0 | component: Core | priority: highest | resolution: done
2008-03-30 23:54:55: @s-wagner created the issue