On Mon, Feb 16, 2015 at 12:06 PM, Jonathan S. Shapiro <[email protected]> wrote: > 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.
I don't like the sound of first-class set type. You mean type-level sets? That's what I thought his parameterized effect monad calls for. > We have started a discussion in another thread about the merits of monads. > > > What have I failed to capture here? You got the most important stuff that I remember as of when you wrote your message. Someone should look at Virgil. We might want to remember that Keean's proposals don't seem to work because of shadow coercions that allocate. That problem was not obvious for me. _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
