[bitc-dev] Application of curry generates some heat
rick.richardson at gmail.com
Wed Mar 11 15:07:12 EDT 2009
I'm comfortable either way, but I tend to agree with Geoffrey.
IMO, the commas would hinder readability when compared with explicitly
bracketed applications. In Haskell, I would tend towards f a (g b) even when
it wasn't a requirement to be explicit. It being required only in the case
when f takes 3 or more arguments.
In addition, taking the statistical approach with hassle in general usage; I
would guess that one would have to bracket app_exprs less than they would
have to comma exprs.
But I guess that would depend on style.
On Wed, Mar 11, 2009 at 2:56 PM, Geoffrey Irving <irving at naml.us> wrote:
> On Wed, Mar 11, 2009 at 2:48 PM, Jonathan S. Shapiro <shap at eros-os.com>
> > 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.
> bitc-dev mailing list
> bitc-dev at coyotos.org
We can't solve problems by using the same kind of thinking we used when we
- A. Einstein
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the bitc-dev