On 12 February 2015 at 21:05, Matt Rice <[email protected]> wrote: > >> I haven't really caught up on this thread, but I find this statement > >> rather weird, in that sometimes we know the type of a value without > >> knowing the value itself until somewhere down the partial evaluation > >> process... in this cases we generate a dummy placeholder value where > >> the dummy and the actual value have the same type, and it appears > >> like there is a reading of this where the dummy, and the actual value > >> need not share a calling convention? >
Reading this again, it sounds like abstract interpretation. This is how rpython works: it interprets the program, recording which branches were taken and what instructions were executed. If it reaches a conditional that depends on a run-time value, it takes both paths and records both traces. It's a neat technique. > > Ok. So what calling convention does this dummy support? Or is it not > > directly callable? > > It depends really, for instance in the thing I linked in my previous email > http://cap-lore.com/Languages/Synergy/OCaml.html > > 'nullObj' can be considered the placeholder, the value of 'obj' is not > known until 'seal' is called, but that its type is equivalent to > 'nullObj' is known, > > so it depends entirely on the caller, in other cases a similar > function may call into 'obj' or dummy object or both, > > if obj needs to be directly callable so should the dummy, but there is > no need for it to produce anything worthwhile, it may just be there to > tie the type inference together. > In this case, we don't know what the native arity should be beforehand. We have an arity, and we could wrangle the value to accept one argument at a time or all of them, but the values we will get - the functions that are passed to us - want to have different /native arity/. Unfortunately, if we don't want to add a layer of indirection we need to pick one. The simplest layer of indirection would be passing the number of arguments on the stack as the first argument to the call, and tail calling the result if need be. Another alternative is a mechanism more like that of STG, although it becomes more work to order effects. The point is, if we pick a native arity, which do we pick? Keean's uncurrying pass picks 1 in the face of ambiguity. It has some nice properties, one that I like is that the curried form of functions can easily be emitted as a prelude to the native implementation in the machine code, which reduces allocation in some cases. The concern is that in practice, partial application may turn out to be rare. So CALLing function variables once for each argument will be busy-work. -- William Leslie Notice: Likely much of this email is, by the nature of copyright, covered under copyright law. You absolutely MAY reproduce any part of it in accordance with the copyright law of the nation you are reading this in. Any attempt to DENY YOU THOSE RIGHTS would be illegal without prior contractual agreement.
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
