{"action":"created","issue":{"url":"https://api.github.com/repos/j14159/mlfe/issues/7","repository_url":"https://api.github.com/repos/j14159/mlfe","labels_url":"https://api.github.com/repos/j14159/mlfe/issues/7/labels{/name}","comments_url":"https://api.github.com/repos/j14159/mlfe/issues/7/comments","events_url":"https://api.github.com/repos/j14159/mlfe/issues/7/events","html_url":"https://github.com/j14159/mlfe/issues/7","id":163570246,"number":7,"title":"FFI Bridge Proposal","user":{"login":"j14159","id":323681,"avatar_url":"https://avatars.githubusercontent.com/u/323681?v=3","gravatar_id":"","url":"https://api.github.com/users/j14159","html_url":"https://github.com/j14159","followers_url":"https://api.github.com/users/j14159/followers","following_url":"https://api.github.com/users/j14159/following{/other_user}","gists_url":"https://api.github.com/users/j14159/gists{/gist_id}","starred_url":"https://api.github.com/users/j14159/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/j14159/subscriptions","organizations_url":"https://api.github.com/users/j14159/orgs","repos_url":"https://api.github.com/users/j14159/repos","events_url":"https://api.github.com/users/j14159/events{/privacy}","received_events_url":"https://api.github.com/users/j14159/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":5,"created_at":"2016-07-03T16:52:58Z","updated_at":"2016-07-06T15:12:45Z","closed_at":null,"body":"Bridges are to MLFE as ports are to Elm, without the send/receive and subscription semantics.\r\n\r\nThis is motivated by questions from @imetallica, discussion and feedback from @omarkj, and naming concerns from @lpil.\r\n\r\nExample:\r\n\r\n    bridge append_ints = :erlang :\"++\" [list int, list int] list_int\r\n\r\nGiven the above in a module, the compiler will synthesize the function `append_ints`, typed to take to integer lists and return one that is a combination of both:\r\n\r\n    {t_arrow, [{t_list, t_int}, {t_list, t_int}], {t_list, t_int}}\r\n\r\nThe typer will trust that the author has considered the types involved and will expose this function for type checking.  The code generator  will create this function in the output Core Erlang AST and programmatically create the necessary checks for the return value.  If we follow what Elm has done, this will create some substantial overhead on any recursive type like lists, maps, and recursive ADTs as each element must be checked before returning the result to MLFE code. A more problematic example:\r\n\r\n    type maybe_io_device = Ok pid unit | Error atom\r\n\r\n    bridge open_file = :file :open [string, list atom] io_device\r\n\r\nIf you refer to the [erldocs for file:open/2](http://erldocs.com/current/kernel/file.html?i=0&search=file:open#open/2), you'll notice the types I've given above to the bridge are incomplete, for example I'm not accounting for the `fd()` type which in the given docs doesn't appear to devolve to a pid.  A larger issue is that currently the compiler would render the `maybe_io_device` ADT as either `{'Ok', Pid}` or `{'Error', ErrorAtom}` in any pattern match checking the validity of the return.  This is relatively trivial to change and may make sense for simpler handling of common Erlang patterns directly as ADTs with no intermediary translation layer at all.\r\n\r\nMore specifically, given the changes to how ADTs are rendered, the code above would be synthesized to the following in the code generator:\r\n\r\n    open_file(Filename, Modes) ->\r\n        case file:open(Filename, Modes) of\r\n            {ok, IO}=Ok when is_pid(IO) -> Ok;\r\n            {error, Reason}=Err when is_atom(Reason) -> Err\r\n        end.\r\n\r\nThis has rather large safety implications:\r\n\r\n1. do we let this explode on the Erlang side unchecked, somewhat similarly to Elm?\r\n2. do we generate code that is already wrapped in a try/catch to account for errors, utilizing some sort of built-in type like `type try 'x = Success 'x | Error erlang_exception`?  I use this type in Scala but does this remove Erlang-ness from the language?\r\n3. should we have a default safe mode as in the previous point and a keyword to _remove_ the try/catch, e.g. `unsafe bridge open_file = ...` that doesn't wrap the result?\r\n4. should bridges always be unsafe but any that occur without a surrounding try/catch raise a compiler warning?\r\n\r\nI'm leaning towards point 3 at the moment but curious about other opinions and would like to know if I've missed anything (beyond the complexity checking recursive structures entails)."},"comment":{"url":"https://api.github.com/repos/j14159/mlfe/issues/comments/230803279","html_url":"https://github.com/j14159/mlfe/issues/7#issuecomment-230803279","issue_url":"https://api.github.com/repos/j14159/mlfe/issues/7","id":230803279,"user":{"login":"ericbmerritt","id":4828,"avatar_url":"https://avatars.githubusercontent.com/u/4828?v=3","gravatar_id":"","url":"https://api.github.com/users/ericbmerritt","html_url":"https://github.com/ericbmerritt","followers_url":"https://api.github.com/users/ericbmerritt/followers","following_url":"https://api.github.com/users/ericbmerritt/following{/other_user}","gists_url":"https://api.github.com/users/ericbmerritt/gists{/gist_id}","starred_url":"https://api.github.com/users/ericbmerritt/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/ericbmerritt/subscriptions","organizations_url":"https://api.github.com/users/ericbmerritt/orgs","repos_url":"https://api.github.com/users/ericbmerritt/repos","events_url":"https://api.github.com/users/ericbmerritt/events{/privacy}","received_events_url":"https://api.github.com/users/ericbmerritt/received_events","type":"User","site_admin":false},"created_at":"2016-07-06T15:12:45Z","updated_at":"2016-07-06T15:12:45Z","body":"Scala is, unfortunately, a really poor example of good infix names. Haskell/ocaml are better sources with much better rules. I would take those as examples more then scala. Scala is a great `bridge` language. That is, it does a good job of dragging Java into a semi functional space, but its not a very good functional language in its own right. "}}
{"actor":{"display_login":"ericbmerritt"}}