On Wed, Mar 11, 2009 at 2:48 PM, Jonathan S. Shapiro <[email protected]> wrote:
> Sorry. Couldn't resist that subject line.
>
> Okay. It's emerging that n-ary functions and curried-style application
> syntax do not get along. It impacts both type declarations and
> function application. The issue is that given:
>
> f1 a f2 . b
>
> the parser can't figure out whether this is (f1 a (f2 b)) or (f1 a f2
> b). This cannot be resolved with associativity rules in most parsers,
> because most parser generators only have a notion of associativity for
> tokens. It's easy in C because the commas in the function call syntax
> have the effect of "bracketing" the nested expressions, and I think we
> are going to need to do something here.
>
> While we could adopt C-style syntax, another option to consider is
> that function applications should only be permitted in bracketed
> contexts. That is: we have separate nonterminals for expr and
> app_expr, and only use app_expr in contexts that are surrounded by
> tokens.
>
> The effect of this is that:
>
> f1 a f2 b
>
> is unambiguously passing f2 as a value, because the inner application
> syntactically requires parentheses or some such:
>
> f1 a (f2 b)
>
> For the most part, the only place that this will crop up in the face
> of the programmer is applications nested within applications. It
> should't show up for infix/outfix operators (we can handle those with
> precedence rules). But it *will* show up in nested type specification.
>
> I tentatively prefer this to introducing a comma syntax here. It feels
> more readable to me.
>
> Reactions/opinions?
I'm in favor of the separate app_expr nonterminal. I believe I had to
do that when parsing ocaml as well, since even in a fully curried
language "a b c" can be parsed as either "(a b) c" or "a (b c)" if
there's only one expr nonterminal.
I also think that app_expr can be used *everywhere* except as for the
arguments of a function. E.g.,
f a + f b
should work as well.
Geoffrey
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
