Wot is mixfix? You mean more than infix? Something permitting
constructs like
with <variable> open <othervariable> cleanup <stuffhere>
FWIW I've never done more than play with a syntax like your f 1 + f 2
uses, and FTR I'm not bothered in the main, I can adjust to syntax
easily -- with perhaps one or two major quibbles. One is excessive
reliance on precedence to avoid the onerous labour of adding a few (
and ) and thus making intended precedence clear.
I won't go into this much yet as it may not be time, but I *don't* like
parsing complex expressions in my head and I *have* seen dire bugs due
to incorrect understanding of precedence. By dire I mean *huge* sums
of money could have got lost (but not lives, thankfully).
Therefore a syntax which requires a more explicit delimiting (or has
very shallow precedence hierarchy) wins my vote. What form that takes
I don't much care.
In general I prefer that syntax disambiguates instead of semantic rules.
There is a significant social question implicit in this; the people on
this list will be typically very good & very experienced & widely
read. Is BitC syntax & other features designed for them or must it sit
well with the bulk of grunt programmers for which programming is
merely a job, and not as careful/knowledgeable as we might get here?
jan
>On Fri, Mar 6, 2009 at 1:48 PM, Geoffrey Irving <[email protected]> wrote:
>> I'm definitely in favor of Option 2, and don't understand why (f 1 + f
>> 2) would require parentheses. Can you explain the problem in more
>> detail? Most (all?) languages with curry style notation for function
>> calls give application higher precedence than addition (including
>> math, for example), so (f 1 + f 2) should be fine.
>
>The problem is that in things like
>
> f a b + f c d
>
>we do not know how many arguments to "consume" for f until f is typed,
>and we don't have that information at parse time. This works in ML
>*because* of curried forms. The parser builds:
>
> ((f a) b) # apply left-associative
> (+ ((f a) b) f c d ) # apply higher precedence
> (+ ((f a) b) (f c) d ) # apply higher precedence
> (+ ((f a) b) ((f c) d) ) # apply higher precedence
>
>Basically, the whole strategy relies on the fact that the parser never
>considers more than one non-terminal immediately to the left of the
>current position.
>
>shap
>_______________________________________________
>bitc-dev mailing list
>[email protected]
>http://www.coyotos.org/mailman/listinfo/bitc-dev
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
