User:Thepigdog
Contents |
[edit] Main Pages
- Intelligence and Reasoning
- Symbolic Logic:Programming
- Analysis
- Constraint Logic Programming Theory
- Localisation of functionality
- User:Thepigdog/book
- User:Thepigdog/Church-Rosser Theorem
[edit] Progress
These are the problem areas.
[edit] Symbolic Logic - Learning
How to create a simple learning system that does common sense learning. Not really complicated learning. Association of coincidences. Need a representation of knowledge. Once you have a rich general representation of knowledge learning may be applied to it.
How to give learning universal access so that it may apply to everything.
How to learn syntax. I dont think syntax may be learned alone in isolation. Need a semantic context, and then build up syntax from simple examples.
What is a semantic context. It is the representation of all knowledge made available to the learning system.
[edit] OO
Is there a need for a vertical slicing of classes. For example for any business object such as a Trade there is
- Business Logic
- GUI (controller logic)
- GUI (presentation logic)
- Web based
- Event based
- GUI design
- Messaging logic
- XML
- Algebraic data types
- Persistence
- Searching and Selection
- Meta data
- Logging
- Learning
Using fine grained renaming inheritance each of these areas of functionality are inherited from attributes. So an attribute and every other class business object needs to be sliced up in many ways. Perhaps the word "section" is appropriate to describe each slice.
The idea is that you can declare the sections that any class has. Then add functions to that section. Each section is compiled separately and does not depend on classes related to other sections. For example GUI software would use GUI classes which other sections dont need to know about.
However there should be core (outside any section) attributes and functions which all sections may access.
You shouldnt pay for a section unless you ask for it. The attributes in a section should only be allocated memory if the section functionality is required.
Separate page to discuss sections? Include renaming inheritance?
[edit] Problems with Sections
Are sections like classes with separate object instances? Can a section instance be attached to multiple class instances? This implies assignment and imperative programming which is bad.
For example with a GUI, there is normally a single instance representing the presentation (the form). In the form a frame will be dedicated to displaying the details of an instance.
It is conventient that the controls on that frame be attached to a single controller. THat controller is then dynamically connected to a model object, selected from a list of model objects.
But this is not a mathematical or logic programming approach.
The closest is that the combination of controller and business object forms a tuple. Methods are then called on the tuple.
I dont have a good answer to this problem. This then undermines the idea of the section.
[edit] Sections as Type Overriding
If functions can be overridden in inherited classes, why cant types. Type overriding could give us sections. A base class called Framework could define the type names (Controller, XMLCreator, Persistence, etc). Each type name would define a section within the framework class. Inheriting classes would implement the types for each section. A class may inherit multiple definitions of sections, and combine the section type defintions to form a single definition of a section class. (I am not sure if this works logically).
For example the controller class for a trade would inherit from the controller class for each attribute, to produce a class inheritance structure for the controller class.
But this still doesnt solve the problem of a single controller being dynamically linked to model instances over time.
[edit] Controller has a timelist of model instances
The GUI is naturally dynamic and time dependent, as it models the active flow of the world. So it makes sense for the controller to include a time list of model classes, that are attached to the model at that time. This is feasable but not terribly elligant.
[edit] Meta Programming
Meta programming should be as unobtrusive as possible. My page on meta programming is really weak and doesnt say what I mean. Perhaps the meta-programming page should come before OO. Ideally OO is just logic features added using meta-programming. But there are specific implementation strategies associated with OO. How to resolve this tension.
Meta logic should be just like other logic, but applied in a particular meta-phase.
[edit] Diagrams
What is the role of diagrams.
[edit] Set operations
Count, sum, list, sort. Need to wait until set is complete before they can be applied. Need to document this.
[edit] User
Drafts
- GUI Theory
- Continuously Variable Transmission
- Pattern Matching
- vsoom
- Value Set Logic Programming
- Logical Branching
- Constraint Logic Programming Theory
- Value Set
- Inheritance
- BusinessAnalysis:Test Topic
- Morality Axioms
- User:Thepigdog/Programming Language Styles
[edit] Tasks
- Standard Programming Language Definition
- So many languages already.
- Dont really want to create another.
- Really want a non language. Collection of features.
- Need standardisation.
- More diagrams (but they are so hard to draw and look bad).
- Better diagram drawing technology?
- Object Oriented Constraint Logic Programming Theory
- Does OO lead to tight coupling?
- Does OO hide and obscure the execution flow?
- Implementation of Inheritance
- Interface for implementation class
- Precondition inside implementation functions.
- Dynamic inheritance.
- Meta Programming for CLP
- More detailed description of the phases.
- Re-organisation.
- 2.1 Meta Phase 1 - Inheritence resolution
- Messaging Systems
- Converting constructors to text formats.
- Logical meaning of sending a message.
- Integration of constructors into the language somehow.
- Recording Tests
- Introduce "function as class with inheritance" implementation of aspects.
- Do I need aspects? Messaging approach instead.
- Vertical classification of class functionality.
- Intelligence and Reasoning
- Sensory Perception -> Pattern Matching.
- Higher level description
- Pattern matching as part of learning.
- Developement Environment
- GUI for Programs Objects
- Program Object Learning
- Diagrams