{"action":"created","issue":{"url":"https://api.github.com/repos/keean/zenscript/issues/18","repository_url":"https://api.github.com/repos/keean/zenscript","labels_url":"https://api.github.com/repos/keean/zenscript/issues/18/labels{/name}","comments_url":"https://api.github.com/repos/keean/zenscript/issues/18/comments","events_url":"https://api.github.com/repos/keean/zenscript/issues/18/events","html_url":"https://github.com/keean/zenscript/issues/18","id":179470231,"number":18,"title":"Compiler Implementation","user":{"login":"keean","id":508384,"avatar_url":"https://avatars.githubusercontent.com/u/508384?v=3","gravatar_id":"","url":"https://api.github.com/users/keean","html_url":"https://github.com/keean","followers_url":"https://api.github.com/users/keean/followers","following_url":"https://api.github.com/users/keean/following{/other_user}","gists_url":"https://api.github.com/users/keean/gists{/gist_id}","starred_url":"https://api.github.com/users/keean/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/keean/subscriptions","organizations_url":"https://api.github.com/users/keean/orgs","repos_url":"https://api.github.com/users/keean/repos","events_url":"https://api.github.com/users/keean/events{/privacy}","received_events_url":"https://api.github.com/users/keean/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":328,"created_at":"2016-09-27T11:43:37Z","updated_at":"2016-10-21T21:57:36Z","closed_at":null,"body":"Discussion about the ongoing implementation of the compiler."},"comment":{"url":"https://api.github.com/repos/keean/zenscript/issues/comments/255475282","html_url":"https://github.com/keean/zenscript/issues/18#issuecomment-255475282","issue_url":"https://api.github.com/repos/keean/zenscript/issues/18","id":255475282,"user":{"login":"keean","id":508384,"avatar_url":"https://avatars.githubusercontent.com/u/508384?v=3","gravatar_id":"","url":"https://api.github.com/users/keean","html_url":"https://github.com/keean","followers_url":"https://api.github.com/users/keean/followers","following_url":"https://api.github.com/users/keean/following{/other_user}","gists_url":"https://api.github.com/users/keean/gists{/gist_id}","starred_url":"https://api.github.com/users/keean/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/keean/subscriptions","organizations_url":"https://api.github.com/users/keean/orgs","repos_url":"https://api.github.com/users/keean/repos","events_url":"https://api.github.com/users/keean/events{/privacy}","received_events_url":"https://api.github.com/users/keean/received_events","type":"User","site_admin":false},"created_at":"2016-10-21T21:57:36Z","updated_at":"2016-10-21T21:57:36Z","body":"> But the constraints you are advocating (to model subsumption and supersumption) don't exist until a transformation algorithm is applied to the AST, i.e. they aren't native to the AST.\r\n\r\nNo types are native to the AST. The compiler consists of a series of `passes` each applying a transformation to the AST. Adding type annotations to the AST is just one such compiler pass.\r\n\r\n> And in my estimation, the effort you must apply to keep this non-unified appendage in sync with the core language as expressed in the AST, is a corner case proliferating opportunity-cost.\r\n\r\nI don't understand what you are saying here? What do you think needs to be kept \"in-sync\"?\r\n\r\n> I would prefer the unification algorithm understand subsumption and supersumption w.r.t. to the untransformed AST, so that we have a unified model for our language.\r\n\r\nThis makes the unification algorithm more complex, harder to get right, and with no real way to check it is correct. It also makes this algorithm depend on subtyping judgements. Once you pollute the pure equality of unification with the mess of subtyping there is no way to recover pure equality in the type system any more. This is like redefining mathematical equality to round numbers up or down, and then wondering why you cannot test floating points for equality any more.\r\n\r\n> When the relationship between types is understood natively by the unification algorithm, then we won't have this resonance mismatch of trying to make the appendage robust enough to handle all cases.\r\n\r\nI dont understand what you are saying? what resonance mismatch? What problem with robustness. What I am proposing is far more robust as we have a universal definition of equality that can be relied upon to be correct, and then we can extend this with a subtyping judgement as appropriate. This separation of concerns is a better architecture.\r\n\r\n> I think there will be a lot of infrastructure necessary to make this orthogonal declaration language robust enough to declare all the necessary relationships (rules).\r\n\r\nThe infrastructure is required to implement a type system anyway. I have explained this before, you need unification to propagate the types, and you need backtracking to implement type-class matching. These two things are all you need to implement a declarative logic language. As I said before most type systems are a bad re-implementation of Prolog, because their authors do not realise that they are in fact implementing a logic interpreter. It is much better to implement a nice clean logic interpreter understanding what you are doing, and then adding the rules for your specific type system on top.\r\n\r\n> I think all that infrastructure will obfuscate what is really going on in the algorithm.\r\n\r\nWhat additional infrastructure are you referring to? I have already explained that a type system like this will need unification and backtracking anyway, so I don't see what extra infrastructure you could possibly mean?"}}
{"actor":{"display_login":"keean"}}