Regularizing FFI syntax

[tedinski]

type IO foreign;

function print
IO ::= s::String i::IO
{
  return error("Not Yet Implemented: print");
} foreign {
  "java" : return "common.Util.io(%i%, common.Util.print(%s%.toString()))";
}

These are bizarre choices of syntax, in retrospect. We should do something like

foreign type IO;

foreign function print
IO ::= s::String i::IO
{
  return "common.Util.io(%i%, common.Util.print(%s%.toString()))";
}

This is not a backwards compatible change, however. There would be shift/reduce conflicts between the new and old syntax. We'd need a "flag day" to change everything over. I think that's feasible because foreign functions shouldn't appear just anywhere out there in grammars... mostly standard library stuff, I hope.

[krame505]

I do like the idea of writing foreign type ... and foreign function ... instead of the weird syntax we have now. But still being able to write a Silver implementation for a function alongside a foreign implementation is still kind of nice to have. Also this does kind of rule out adding other translation backends in the future, but maybe that's not a big deal.
Also I'm not sure I like return "<some string that is actually code>"; as it looks too much like just writing a normal function that returns a string. Is there a reason we can't write Java statements in this block (including a return statement) instead of an expression? This would also be nice and let us avoid writing some of the tiny Java helper functions we need now.

[tedinski]

Is there a reason we can't write Java statements in this block (including a return statement) instead of an expression? This would also be nice and let us avoid writing some of the tiny Java helper functions we need now.

This is a good idea, but it'd require a bit of work, I think. The main issue is that basic syntax highlighters wouldn't cope with this change very easily. Dunno if there are any other big problems.

[tedinski]

Oh, and RE: other translations, I think that's a non-issue.

The way other languages cope with such things is that other translations have a different standard library entirely! This is essential as, for instance, Javascript in the browser isn't going to offer us a lot of file-writing capabilities, so those functions just wouldn't exist in that stdlib.