{"action":"created","issue":{"url":"https://api.github.com/repos/keean/traitscript/issues/1","repository_url":"https://api.github.com/repos/keean/traitscript","labels_url":"https://api.github.com/repos/keean/traitscript/issues/1/labels{/name}","comments_url":"https://api.github.com/repos/keean/traitscript/issues/1/comments","events_url":"https://api.github.com/repos/keean/traitscript/issues/1/events","html_url":"https://github.com/keean/traitscript/issues/1","id":177572293,"number":1,"title":"Language Discussion","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":33,"created_at":"2016-09-17T12:07:23Z","updated_at":"2016-09-18T22:16:41Z","closed_at":null,"body":"The idea is to create a simple, compact, symmetrical, typed language for generic programming that compiles to JavaScript. The initial reference is \"Elements of Programming\" by Alexander Stepanov and Paul McJones.\r\n\r\nThe core concept is to have parametric types, type-classes and type-families, along with maybe higher-ranked-types, higher-kinded-types, to enable type-directed generic programming.\r\n\r\nInspiration is from C, C++ Concepts (type safe templates), Haskell, Rust, Eff, and others.\r\n\r\nThis is different from TypeScript, because it is based on type-classes, not classical inheritance, different from PureScript because it allows imperitivity and state.\r\n\r\nThis issue is for the initial design of the language, with other issues being forked as necessary for specific topics like syntax, semantics, type system etc.\r\n\r\n"},"comment":{"url":"https://api.github.com/repos/keean/traitscript/issues/comments/247884540","html_url":"https://github.com/keean/traitscript/issues/1#issuecomment-247884540","issue_url":"https://api.github.com/repos/keean/traitscript/issues/1","id":247884540,"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-18T22:16:41Z","updated_at":"2016-09-18T22:16:41Z","body":"@keean wrote:\r\n> In the append case both arguments are lists.\r\n\r\nThe cognitive load is too high. Now I see it (below), because `x` is result of `append` so `x` is inferred to be a list. But it wasn't declared. Sorry most programmers don't think this way (yet). It will be a massive cognitive dissonance.\r\n\r\n```\r\nappend x Nil = x\r\nappend x (Cons h t) = Cons h (append x t)\r\n```\r\n\r\nI will quote from the author of _Learn You A Haskell_:\r\n\r\n> I failed to learn Haskell approximately 2 times before finally grasping it because it all just seemed too weird to me and I didn't get it.\r\n\r\n------------\r\n\r\n@keean wrote:\r\n> It's not just the reduction in verbosity, but the lack of indenting, keeping everything lined up to the left makes for more readable code.\r\n\r\nThe examples I provided are also left-justified. I don't understand.\r\n\r\n> However I do think you have a point about people not used to the style.\r\n\r\nThanks. If anyone can convince me that is not a priority, then please do.\r\n\r\n> I am not concerned about keeping close to JS, especially if native compilation or web-assembly are future targets.\r\n\r\nI am! It will be our main target for a long time probably. Other targets need time to mature. JS target is free, batteries included. [I quote](http://esr.ibiblio.org/?p=7111) ESR and his 166 IQ:\r\n\r\n> Too clever by half lands you in incident pits.\r\n>\r\n> How do you avoid these? By designing to avoid failure modes. This why “KISS” – Keep It Simple, Stupid” is an engineering maxim. Buy the RTC to foreclose the failure modes of not having one. Choose a small-form-factor system your buddy Phil the expert hardware troubleshooter is already using rather than novel hardware neither of you knows the ins and outs of.\r\n>\r\n> Don’t get cute. Well, not unless your actual objective is to get cute – if I didn’t know that playfulness and deliberately pushing the envelope has its place I’d be a piss-poor hacker. But if you’re trying to bring up a production mailserver, or a production anything, cute is not the goal and you shouldn’t let your ego suck you into trying for the cleverest possible maneuver.\r\n\r\n------\r\n\r\n@keean wrote:\r\n> If you don't have pattern match in arguments, then you can only have one function declaration for each function, no ad-hoc overloading, because you need to use a type-class to overload different argument types.\r\n\r\nOkay I see your point. You are assuming we will never allow functions that input concrete data types, only trait bounded type parameters (per that idea you mentioned upthread). Then a data type might be implemented for traits declared by two or more of the overloaded variants, so at the use-site it would require a cast in order to select which overloaded function in that case of ambiguity. But this doesn't mean we couldn't have function overloads, rather that ambiguities create verbosity of casts. And I don't see how patterns and guards changes that since they share the same function name.\r\n\r\nAlso functions can be overloaded by arity of arguments, not just type.\r\n\r\n> I think `let` for immutable assignment, and I wonder is mutable assignment is necessary, as objects are a reference you can mutate the object referenced, even if the reference itself is immutable. Perhaps we could start with only single immutable assignment and see how it goes?\r\n\r\nHow do I implement a `for` loop if `i` is not mutable?"}}
{"actor":{"display_login":"shelby3"}}