{"action":"created","issue":{"url":"https://api.github.com/repos/m2ym/optima/issues/110","labels_url":"https://api.github.com/repos/m2ym/optima/issues/110/labels{/name}","comments_url":"https://api.github.com/repos/m2ym/optima/issues/110/comments","events_url":"https://api.github.com/repos/m2ym/optima/issues/110/events","html_url":"https://github.com/m2ym/optima/issues/110","id":59388838,"number":110,"title":"Suggestion for version 2","user":{"login":"guicho271828","id":1321968,"avatar_url":"https://avatars.githubusercontent.com/u/1321968?v=3","gravatar_id":"","url":"https://api.github.com/users/guicho271828","html_url":"https://github.com/guicho271828","followers_url":"https://api.github.com/users/guicho271828/followers","following_url":"https://api.github.com/users/guicho271828/following{/other_user}","gists_url":"https://api.github.com/users/guicho271828/gists{/gist_id}","starred_url":"https://api.github.com/users/guicho271828/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/guicho271828/subscriptions","organizations_url":"https://api.github.com/users/guicho271828/orgs","repos_url":"https://api.github.com/users/guicho271828/repos","events_url":"https://api.github.com/users/guicho271828/events{/privacy}","received_events_url":"https://api.github.com/users/guicho271828/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":8,"created_at":"2015-03-01T08:57:53Z","updated_at":"2015-03-04T16:32:00Z","closed_at":null,"body":"To avoid the dependency as much as possible, currently, optima is implemented in an imperative style. Given its goal is to ease functional programming, this is an irony. As a result, Core algorithm and optimization are intermixed into a large conglomerate, and how the optimization work is not visually intuitive (in a source-code basis). Extending optima also requires significant amount of effort.\r\n\r\nIn light of this, I am designing the next version of optima, which has the better source architecture satisfying the following qualifications.\r\n\r\n# multi-layered architechture.\r\n\r\nOne way to avoid this dependency vs utility problem is to *include* a primitive pattern matcher to bootstrap optima. In the past, I wrote https://github.com/guicho271828/optima-clone as \"self-compiling optima\", but that goal is not yet achieved because I wrote them in a monolithic manner -- failed to separate *optimization* part  from *bootstrapping* part.\r\n\r\nI'll divide the implementation of optima version 2 into 3 layers: *layer-0*, which supports `list, list*, constant` patterns only,  *layer-1*, which supports `or` and `guard` only, and *layer-2*, which supports all existing patterns in v1 using layer-1 and derived patterns. In detail, each layer handles the following functionality:\r\n\r\n+ layer 0 : list destructuring --- thin wrapper over destructuring-bind . This is used primarily for manipulating the input pattern.\r\n+ layer 1 : core patterns. It mainly handles variable scoping and conditional jumps.\r\n+ layer 2 : pattern transformers. It expands derived patterns, runs some optimizations etc.\r\n\r\n# minimal structure-based expression of patterns\r\n\r\nWe should avoid using `constructor-pattern` etc. in the current implementation. guard-pattern, which will support the extended syntax suggested in #109, would eliminate the needs for complex structure-based handling of structure-patterns, class-patterns etc.\r\n\r\n# Pattern transformer.\r\n\r\ncurrently, trivial patterns e.g. `(and)` , syntax sugar like `when`, guard pattern lifting, are hard coded into the expansion algorithm. `defpattern`s are also treated separately. Pattern transformer works in this level of abstraction.\r\n\r\n# optimizer API\r\n\r\nOptimizer should be separated from macro generation code. The matching tree can be seen as a decision tree, so a special external algorithm should handle this. This can be implemented as a postprocessing part of layer 2.\r\n\r\nDepending on the optimization context (`(declare (optimize ...))`) or via some form of explicit statement, user should be able to specify the quality of the resulting decision tree. Optimizer can run a local search in a decision-tree search space, or a static optimization algorithm described in Fabrice et. al.\r\n"},"comment":{"url":"https://api.github.com/repos/m2ym/optima/issues/comments/77191856","html_url":"https://github.com/m2ym/optima/issues/110#issuecomment-77191856","issue_url":"https://api.github.com/repos/m2ym/optima/issues/110","id":77191856,"user":{"login":"guicho271828","id":1321968,"avatar_url":"https://avatars.githubusercontent.com/u/1321968?v=3","gravatar_id":"","url":"https://api.github.com/users/guicho271828","html_url":"https://github.com/guicho271828","followers_url":"https://api.github.com/users/guicho271828/followers","following_url":"https://api.github.com/users/guicho271828/following{/other_user}","gists_url":"https://api.github.com/users/guicho271828/gists{/gist_id}","starred_url":"https://api.github.com/users/guicho271828/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/guicho271828/subscriptions","organizations_url":"https://api.github.com/users/guicho271828/orgs","repos_url":"https://api.github.com/users/guicho271828/repos","events_url":"https://api.github.com/users/guicho271828/events{/privacy}","received_events_url":"https://api.github.com/users/guicho271828/received_events","type":"User","site_admin":false},"created_at":"2015-03-04T16:32:00Z","updated_at":"2015-03-04T16:32:00Z","body":"separated \"optimizer\" from the core compilation system. using this notion is beneficial in that\r\n\r\n1. With the trivial default optimizer which doesnt do any optimization, WE HAVE A WORKING CODE AT ALL !\r\n2. Since we have a slow-but-working optima, the next optimizer can be written USING OPTIMA ITSELF!\r\n3. recompiling the optimizer with the new optimizer makes OPTIMIZER ITSELF faster.\r\n4. measuring the efficiency between several optimizer would be realistic.\r\n"}}