{"action":"created","issue":{"url":"https://api.github.com/repos/keean/zenscript/issues/13","repository_url":"https://api.github.com/repos/keean/zenscript","labels_url":"https://api.github.com/repos/keean/zenscript/issues/13/labels{/name}","comments_url":"https://api.github.com/repos/keean/zenscript/issues/13/comments","events_url":"https://api.github.com/repos/keean/zenscript/issues/13/events","html_url":"https://github.com/keean/zenscript/issues/13","id":179006916,"number":13,"title":"Fast track transpiling to TypeScript?","user":{"login":"shelby3","id":247731,"avatar_url":"https://avatars.githubusercontent.com/u/247731?v=3","gravatar_id":"","url":"https://api.github.com/users/shelby3","html_url":"https://github.com/shelby3","followers_url":"https://api.github.com/users/shelby3/followers","following_url":"https://api.github.com/users/shelby3/following{/other_user}","gists_url":"https://api.github.com/users/shelby3/gists{/gist_id}","starred_url":"https://api.github.com/users/shelby3/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/shelby3/subscriptions","organizations_url":"https://api.github.com/users/shelby3/orgs","repos_url":"https://api.github.com/users/shelby3/repos","events_url":"https://api.github.com/users/shelby3/events{/privacy}","received_events_url":"https://api.github.com/users/shelby3/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":13,"created_at":"2016-09-24T02:59:31Z","updated_at":"2016-09-24T21:22:24Z","closed_at":null,"body":"Building off the reasoning and justification in my rejected issue [Fast track transpiling to PureScript?](https://github.com/keean/zenscript/issues/12), I have a new idea of how we might be able to attain some of the main features proposed for ZenScript, without builiding a type checker by transpiling to TypeScript.\r\n\r\nIf we can for the time being while using this hack, presume that no modules will employ differing implementations of a specific data type for any specific typeclass, i.e. **that all implementations of each data type are the same globally for each typeclass implemented** (which we can check at run-time and `throw` an exception otherwise), then the module can **at load/import insure that all implementations it employs are set** on the `prototype` chain of all the respective classes' construction functions. In other words, [my original point](https://github.com/Microsoft/TypeScript/issues/10844) was that JavaScript has global interface injection (a form of monkey patching) via the `prototype` chain of the construction function, and @svieira [pointed out](https://github.com/Microsoft/TypeScript/issues/10844#issuecomment-247392138) the potential for global naming (implementation) conflicts.\r\n\r\nSo the rest of the hack I have in mind, is that in the emitted TypeScript we declare typeclasses as `interface`s and in each module we declare the implemented data types as `class`es with all the implemented `interface`s in the hierarchy. So these classes then have the proper type where ever they are stated nominally in the module. We compile the modules separately in TypeScript, thus each module can have differing declarations of the same `class` (because there is no type checking linker), so that every module will type check independently and the global prototype chain is assured to contain the `interface`s that the TypeScript type system checks.\r\n\r\nSo each function argument that has a typeclass bound in our syntax, will have the corresponding `interface` type in the emitted TypeScript code. Ditto typeclass objects will simply be an `interface` type.\r\n\r\nThis appears to be a clever way of hacking through the type system to get the type checking we want along with the ability to have modules add implementations to existing data types with our typeclass syntax. And this hack requires no type checking in ZenScript. We need only a simple transformation for emitting from the AST.\r\n\r\nAs for the first-class inferred structural unions, TypeScript already has them, so no type checking we need to do.\r\n\r\nIt can't support my complex solution to the Expression Problem, but that is okay for starting point hack.\r\n\r\nI think this is way we can have a working language in a matter of weeks, if we can agree?\r\n\r\nThat will give us valuable experimentation feedback, while we can work on our own type checker and fully functional compiler.\r\n\r\n[TypeScript's bivariance unsoundness](https://github.com/keean/zenscript/issues/8#issuecomment-249082419) should be avoided, since ZenScript semantics is to not allow implicit subsumption of typeclass bounds, but this won't be checked so it is possible that bivariance unsoundness could creep in if we allow typeclasses to extend other typeclasses. Seems those [bivariance cases don't impact my hack negatively](https://www.typescriptlang.org/docs/handbook/type-compatibility.html#function-parameter-bivariance) though:\r\n\r\n> When comparing the types of function parameters, assignment succeeds if either the source parameter is assignable to the target parameter, or vice versa.\r\n\r\nNot a problem because of course an `interface` argument type can never to be assigned to any subclass.\r\n\r\n> When comparing functions for compatibility, optional and required parameters are interchangeable. Extra optional parameters of the source type are not an error, and optional parameters of the target type without corresponding parameters in the target type are not an error.\r\n>\r\n> When a function has a rest parameter, it is treated as if it were an infinite series of optional parameters.\r\n\r\nWe should be able to design around this.\r\n\r\nAlso [a compile flag can turn off](https://groups.google.com/forum/embed/#!msg/strengthen-js/611mdeOu2qw/wDDfqQUtAgAJ) TypeScript's unsound treatment of the `any` type.\r\n\r\nTypeScript is structural but there is a hack to force it to emulate nominal typing. We [could consider instead transpiling to N4JS](https://github.com/NumberFour/n4js/issues/266) which has nominal typing and soundness, but it is not as mature in other areas."},"comment":{"url":"https://api.github.com/repos/keean/zenscript/issues/comments/249388393","html_url":"https://github.com/keean/zenscript/issues/13#issuecomment-249388393","issue_url":"https://api.github.com/repos/keean/zenscript/issues/13","id":249388393,"user":{"login":"shelby3","id":247731,"avatar_url":"https://avatars.githubusercontent.com/u/247731?v=3","gravatar_id":"","url":"https://api.github.com/users/shelby3","html_url":"https://github.com/shelby3","followers_url":"https://api.github.com/users/shelby3/followers","following_url":"https://api.github.com/users/shelby3/following{/other_user}","gists_url":"https://api.github.com/users/shelby3/gists{/gist_id}","starred_url":"https://api.github.com/users/shelby3/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/shelby3/subscriptions","organizations_url":"https://api.github.com/users/shelby3/orgs","repos_url":"https://api.github.com/users/shelby3/repos","events_url":"https://api.github.com/users/shelby3/events{/privacy}","received_events_url":"https://api.github.com/users/shelby3/received_events","type":"User","site_admin":false},"created_at":"2016-09-24T21:22:24Z","updated_at":"2016-09-24T21:22:24Z","body":"This is hopeless. You can stop thinking in terms of Haskell's lack of subtyping and subsumption."}}
{"actor":{"display_login":"shelby3"}}