{"action":"created","issue":{"url":"https://api.github.com/repos/keean/zenscript/issues/14","repository_url":"https://api.github.com/repos/keean/zenscript","labels_url":"https://api.github.com/repos/keean/zenscript/issues/14/labels{/name}","comments_url":"https://api.github.com/repos/keean/zenscript/issues/14/comments","events_url":"https://api.github.com/repos/keean/zenscript/issues/14/events","html_url":"https://github.com/keean/zenscript/issues/14","id":179109775,"number":14,"title":"Orthogonal concepts","user":{"login":"shelby3","id":247731,"avatar_url":"https://avatars3.githubusercontent.com/u/247731?v=4","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":159,"created_at":"2016-09-25T21:22:09Z","updated_at":"2018-04-20T17:01:16Z","closed_at":null,"author_association":"NONE","body":"I am trying to nail down in my mind, the fundamental _orthogonal_ semantic concepts of our proposed programming language.\r\n\r\n| Concept | Description |\r\n| --- | --- |\r\n| `data` | [Unified sum, product, recursive, and record](https://github.com/keean/zenscript/issues/11) data types. No early bound operations other than construction and access. Record types may optionally be mutable. |\r\n| `typeclass` | Delayed binding of operations to types at the use-site. Contrast to OOP (subclassing) which binds operations at construction of objects. For polymorphic types, [typeclass objects](https://github.com/keean/zenscript/issues/27) delays binding operations until construction of the typeclass object (instead of prematurely binding operations at the construction of an instance of the implementing type); whereas, [my posited and proposed solution to the Expression Problem](https://github.com/keean/zenscript/issues/15) employing unions, in theory further delays binding to the use-site for polymorphic types. Note that delaying is a positive attribute in this context, because it increases degrees-of-freedom. |\r\n| `module` | Encapsulating `data` with compile-time (statically) bound operations and access control, enabling more sophisticated types. |\r\n| monadic effect system | https://github.com/keean/zenscript/issues/4#issuecomment-248569044 |\r\n\r\nThus I am wondering if `module` is the most apt name for the concept? I think of a module as a unit of code that is imported separately. We still need to import `data` and `typeclass`, so is this done by files? Isn't each file then a module? If so, what is the apt name for the concept of `module` above? I am thinking the above concept for `module` is really a `class` (without the subclassing inheritance anti-pattern). Can't `modules` extend other modules?\r\n\r\nEdit: note also [OCaml functors and modules](https://github.com/keean/zenscript/issues/13#issuecomment-249446270).\r\n\r\nEdit#2: on typeclasses, I [replied](https://github.com/keean/zenscript/issues/1#issuecomment-284888252) to @keean:\r\n\r\n> > Optional implicit parameters (which Scala has) provide a way of unifying runtime interfaces (passed by value) and monomorphisable interfaces (passed implicitly by type).\r\n> \r\n> I like that summary (in the context of what I had written). We should make sure we frame that and use it in our documentation.\r\n\r\nEdit#3: @shelby3 [wrote](https://github.com/keean/zenscript/issues/1#issuecomment-286957043):\r\n\r\n> I think it is important to remember that we want to keep implementation of interface (i.e. typeclass) orthogonal to instantiation of data, otherwise we end up with the [early binding of subclassing](https://github.com/keean/zenscript/issues/14). For example, in subclassing both a rectangle and a square would be subclasses of an interface which provides width and height. Yet a square only has one dimension, not two. Any interfaces which need to operate on the dimensions of rectange and square need to be customized for each, which is what typeclasses do. We will still have subtyping such as when an interface extends another interface then we can subsume to the supertype (which is why we need read-only references and for supersuming then write-only references). Yet references will not have the type of an interface if we don't provide [typeclass objects](https://github.com/keean/zenscript/issues/27), so then the only case of subtyping will be the subset relationships created by conjunctions and disjunctions of data types."},"comment":{"url":"https://api.github.com/repos/keean/zenscript/issues/comments/383159407","html_url":"https://github.com/keean/zenscript/issues/14#issuecomment-383159407","issue_url":"https://api.github.com/repos/keean/zenscript/issues/14","id":383159407,"user":{"login":"sighoya","id":9272972,"avatar_url":"https://avatars0.githubusercontent.com/u/9272972?v=4","gravatar_id":"","url":"https://api.github.com/users/sighoya","html_url":"https://github.com/sighoya","followers_url":"https://api.github.com/users/sighoya/followers","following_url":"https://api.github.com/users/sighoya/following{/other_user}","gists_url":"https://api.github.com/users/sighoya/gists{/gist_id}","starred_url":"https://api.github.com/users/sighoya/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/sighoya/subscriptions","organizations_url":"https://api.github.com/users/sighoya/orgs","repos_url":"https://api.github.com/users/sighoya/repos","events_url":"https://api.github.com/users/sighoya/events{/privacy}","received_events_url":"https://api.github.com/users/sighoya/received_events","type":"User","site_admin":false},"created_at":"2018-04-20T17:01:16Z","updated_at":"2018-04-20T17:01:16Z","author_association":"NONE","body":"@keean wrote\r\n>Every recent language has been statically typed, Scala, Erlang, Clojure, Haskell, C#, Go, Rust, Swift, you have to look back to the last generation of languages (JavaScript, Python) to find dynamically typed languages, and people keep finding problems with JavaScript and wanting to make it statically typed (TypeScript, PureScript etc).\r\n\r\nEvery \"dynamically type\" language is statically typed. You can asert every variable x in a \"dynamically typed language\" to Any and Any is a type.\r\n\r\nIf you type a variable x with Union would you call your language dynamically typed?\r\n\r\nBoth \"dynamically\" -and \"statically\" typed languages have a type tag where the \"type tag \" of \"statically typed languages\" is only available at compile time (except runtime polymorphism) and for dynamically type languages only at runtime (except some static typing extensions).\r\n\r\nThe question is whether our world is uni typed as types are (subjective) concepts about how our data is composed of and how it can be interpreted.\r\n\r\n@keean wrote\r\n>I also think reflection is a bad idea.\r\n\r\nWhy? \r\nRuntime reflection (RR) can be quite powerfull and simultaneously unsafe.\r\nRR is needed to decide what type is behind your union type.\r\n\r\nYou can see RR as a the missing piece from a statically typed language to a dynamically typed language, i.e. type instantiation/modification/introspection at runtime.\r\n\r\nTo be safe, the generated types should not be included in the type set aka Type as the type system become mutable and therefore possibly inconsistent and all types should be immutable.\r\nInstead you could use a \"fake type\" containing your instantiated types at runtime as values."}}
{"actor":{"display_login":"sighoya"}}