Re: [Chicken-users] Question about procedure type annotations

[Felix]

>> The procedure can not expect to be always called with correctly typed
>> arguments, from any possible call-site. The flow-analysis is
>> intraprocedural and goes not beyond procedure boundaries. You can use
>> the "-strict-types" option to declare that "foo" will indeed be called
>> with correctly typed arguments - your example should work with that
>> option, but calling it with other argument types will result in
>> undefined behaviour at run-time.
> 
> Ah, of course.
>>
>> "assume" overrides whatever type-information is available from
>> flow-analysis (as does "the"). 
>>
>> One direction would be to generate type-checks at entry to a
>> procedure with declared argument types, and I'm currently
>> working on something related. This would have a run-time cost,
>> but the arguments would than be known to be correct. I'm
>> not sure yet what is best.
> 
> That's really interesting! Would this be in the core or some kind of an
> extension?

It would be in core, but there are still some things that have to
be done and a few open questions.

> 
> Am I correct that this would not cause much run-time overhead in simple
> cases, as the types of the arguments would be checked anyway at some
> point if they are used?

Yes, in most cases it would be quite cheap.

> 
> For example in: (define (foo a b) (+ a b)) the `+' would normally check
> the types. But if you check the types (e.g. float?) first and then
> assume them to be of correct type the `+' would be specialized to a call
> that does no type checks.

That's right.

> 
> You could currently do some kind of a procedure defining macro that
> defines two versions, one that just does the type-checks and calls the
> other. The second version contains the actual body and the arguments are
> `assumed' to be of correct type. And, if the types are known at the
> call-site it would be specialized to call the second one directly.

A very good idea. Having two entry-points would make it possible to
avoid the checking part in certain situations, at least for calls
in the same compilation unit.


cheers,
felix