{"action":"created","issue":{"url":"https://api.github.com/repos/SMLFamily/Successor-ML/issues/4","repository_url":"https://api.github.com/repos/SMLFamily/Successor-ML","labels_url":"https://api.github.com/repos/SMLFamily/Successor-ML/issues/4/labels{/name}","comments_url":"https://api.github.com/repos/SMLFamily/Successor-ML/issues/4/comments","events_url":"https://api.github.com/repos/SMLFamily/Successor-ML/issues/4/events","html_url":"https://github.com/SMLFamily/Successor-ML/issues/4","id":145747343,"number":4,"title":"clauses","user":{"login":"RobertHarper","id":1535093,"avatar_url":"https://avatars.githubusercontent.com/u/1535093?v=3","gravatar_id":"","url":"https://api.github.com/users/RobertHarper","html_url":"https://github.com/RobertHarper","followers_url":"https://api.github.com/users/RobertHarper/followers","following_url":"https://api.github.com/users/RobertHarper/following{/other_user}","gists_url":"https://api.github.com/users/RobertHarper/gists{/gist_id}","starred_url":"https://api.github.com/users/RobertHarper/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/RobertHarper/subscriptions","organizations_url":"https://api.github.com/users/RobertHarper/orgs","repos_url":"https://api.github.com/users/RobertHarper/repos","events_url":"https://api.github.com/users/RobertHarper/events{/privacy}","received_events_url":"https://api.github.com/users/RobertHarper/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":9,"created_at":"2016-04-04T17:16:09Z","updated_at":"2016-09-07T10:14:03Z","closed_at":null,"body":"I wonder whether anyone has a suggestion for how to fix the discrepancy in the syntax between fun bindings and case's.  As everyone knows, it is monumentally annoying that the former use equal sign, and the latter use double-arrow; switching a fun to a case or vice-versa is painful for no good reason.\r\n\r\nWithout knowing what has already been suggested or done, let me suggest some options:\r\n1. Denigrate fun entirely.  Except for super-small examples, I don't see a downside to this.\r\n2. Migrate fun to use double-arrow syntax so that the clauses look exactly like case branches.\r\n3. The same, but denigrate multiple clauses so that only fun f(x,y,z) => x+y+z would be permitted.\r\n\r\nBringing up this vexed question automatically brings up a few more.  The most annoying is the needless shift-reduce conflict between two cases and between a case and a fun.  Adding parens is very ugly imo, but ymmv.  If we disallow clausal fun's, then one of these conflicts goes away immediately.\r\n\r\nTo manage the remaining shift-reduce conflict, why not allow curly braces as a form of parentheses for clauses?  That way I could write case e of { p1 => e1 | ... | pn => en } if I'd like, but we needn't insist on it.  The braces could be used more generally for bracketing any subgroup of clauses in a match, but I would guess the main use is as illustrated.\r\n\r\nA related problem is the \"fn\" syntax, which also raises a problem with the scope of a match.  Perhaps we can limit fn to have only one clause, so that fn (x,y,z)=>x+y+z is ok, but not a more general match?  It would simply force the use of a case, which I find nicer anyway.\r\n\r\nThere is also the question of whether fn's should be name-able and self-referential, and whether one could or should admit mutually recursive fn's (which would define a labelled tuple, I suppose).\r\n\r\nIncidentally, denigrating fun declarations entirely would have the advantage that we can use fun for lambda's, which I find nicer than the cramped \"fn\" (and much nicer than \"function\").\r\n\r\nHas anything been done or suggested on these topics already?  They seem so simple to fix, and it would certainly make things nicer syntactically."},"comment":{"url":"https://api.github.com/repos/SMLFamily/Successor-ML/issues/comments/245236719","html_url":"https://github.com/SMLFamily/Successor-ML/issues/4#issuecomment-245236719","issue_url":"https://api.github.com/repos/SMLFamily/Successor-ML/issues/4","id":245236719,"user":{"login":"ratmice","id":5338,"avatar_url":"https://avatars.githubusercontent.com/u/5338?v=3","gravatar_id":"","url":"https://api.github.com/users/ratmice","html_url":"https://github.com/ratmice","followers_url":"https://api.github.com/users/ratmice/followers","following_url":"https://api.github.com/users/ratmice/following{/other_user}","gists_url":"https://api.github.com/users/ratmice/gists{/gist_id}","starred_url":"https://api.github.com/users/ratmice/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/ratmice/subscriptions","organizations_url":"https://api.github.com/users/ratmice/orgs","repos_url":"https://api.github.com/users/ratmice/repos","events_url":"https://api.github.com/users/ratmice/events{/privacy}","received_events_url":"https://api.github.com/users/ratmice/received_events","type":"User","site_admin":false},"created_at":"2016-09-07T10:14:03Z","updated_at":"2016-09-07T10:14:03Z","body":"I see, the thing that confused me was that I used 'x' in foo, you used 'x' in bar, shadowing the original x,\r\nI use this pattern when the function is recursive across currying e.g. the function can be recursive on both 'foo' and 'bar'\r\n\r\nthis was actually the impetus for using this, I don't want to give the x in \"bar x\" a name, its merely another variable in scope which I have to wonder if it really deserves a name, or did I have to assign it a name to apply the case expression to avoid repeating the function name.\r\n\r\nusing this I was able to have bindings at the top, and bindings in the leaves, and for things that really matter like recursion in the middle, and factor out anything which could be anonymous...\r\n\r\nperhaps only useful as an interim step while refactoring a mess, but it has been helpful."}}
{"actor":{"display_login":"ratmice"}}