I want to try to summarize where we are in the current discussion. We appear to be coming down to two proposals:
Option 1: Functions take N>0 argument patterns and return 1 result. We may or may not adopt curried application syntax (i.e. not decorate with parenthesis), but the number of actual parameters must match the number of formal parameters. Partial application is not permitted in the absence of some syntactic construct expressing that the partial application was intentionally, and incidentally signaling the programmer's acceptance of a lambda injection that may cause allocation if the optimizer cannot eliminate it. Option 2: Functions take exactly one argument, which may be a pattern such as a tuple pattern that has sub-constituents. Implementation-level arity is inferred based on the type of the singleton parameter. The present proposal is that tuple patterns be used to express functions taking more than one argument, but we could presumably infer arity from other sorts of patterns as well if we choose to do so. Concerns of lambda injection resulting from partial allocation do not arise, because all functions have arity 1 by virtue of the language definition. Offhand, it seems to me that these are entirely equivalent from the standpoint of computational expressiveness. The first option admits the second as a subset, and has the syntactic advantage that a syntax for partial application seems straightforward to achieve. There does not seem to be a correspondingly clean syntactic construct for partial application in the second option. Barring some unforeseen parsing problem, I am inclined to adopt the first option. My intuition is that the ability to express intentional partial application is useful from "clarity of programming" point of view. It will arise mainly in the context of composition, where the lambda syntax is sometimes invasive. Other: The topic of nullary functions has come up a couple of times. They create a serious mess. BitC will handle nullary functions by passing unit. Keean has proposed a way of annotating effects on the return construction that I do not yet understand. It's clear that we need to annotate effects as part of type. It seems likely that this motivates us to incorporate a first-class set type. We have started a discussion in another thread about the merits of monads. What have I failed to capture here? shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
