On Wed, Feb 25, 2015 at 6:29 AM, Jonathan S. Shapiro <[email protected]> wrote: > On Wed, Feb 25, 2015 at 3:51 AM, Keean Schupke <[email protected]> wrote: >> >> What is wrong with: >> >> def g = f 1 >> >> Yes, it allocates, but surely you would not partially apply f unless you >> had good reason? > > Or you could have simply written the wrong thing. Later, when you try to > hunt down where the hell you made this mistake, that code will not leap out > at you as a possible source of allocation. > > Allocation isn't merely an error where a program potentially crashes. In > some systems codes it may be an error whose consequence is that real people > die. It doesn't get a lot more "semantic" than that. > > The rule in BitC is NEVER to allocate unless the programmer has explicitly > written something that allocates. I don't care if it's semantically valid > from the type theory and pure programming languages point of view. It's > still an operation that can kill people if done unintentionally. > >> Providing we have access to the definition of 'f' > > When we do, fine. But from the standpoint of BitC requirements we would need > to guarantee that was **always** true. In light of which this is an argument > of the form "if false then...." > > Unless your proposal is that we prohibit function types as values or > parameters, so that the definitions are always statically resolvable?
Or at least different types for a function as a statically resolvable symbol and a function that can be bound to some value/parameter e.g. def g = |f| 1 *shrug* _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
