On Mon, Feb 16, 2015 at 8:28 AM, Jonathan S. Shapiro <[email protected]>
wrote:
> I'm still not sure if [pairs instead of tuples] was a good decision or a
> bad one.
>
Actually, I have two thoughts on this.
>From an implementation standpoint, it was a good choice, because it allowed
us to move *all* of the expression processing into the mixfix engine. It is
relatively easy to implement mixfix by having the [static] grammar gather a
sequence of candidate tokens as a list and then invoke the [dynamic] mixfix
parser in a semantic action. Things get one hell of a lot messier if the
[static] parser has to handle some type constructions and not others.
Handing ASTs rather than tokens to the mixfix engine isn't a big deal, but
*parsing* the sub-sequences is a huge problem, because the [static] parser
has essentially no left context to work with. It's cleaner, in the end, to
recognize those cases as special cases in the mixfix parser and do *all* of
the expression parsing in the [dynamic] mixfix parser. In the BitC dynamic
parser, for example, there are "built in" rules that are not expressible
from the source language in order to handle things like parsing application.
There *is* one unfortunate consequence of not having tuples: it becomes
impossible to compatibly express certain kinds of external function
signatures. Because pair('a, pair('b, 'c)) can turn into pair('a, pair('b,
pair('d, 'e))), it is impossible in BitC v0 to specify an external function
that accepts a generic pair pattern as it's final argument. So far, this is
only a minor hypothetical annoyance; it has never come up in practice.
My gut says that we should clean this up, and introduce a proper tuple type
this time around.
shap
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
