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?

shap
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev

Reply via email to