<div dir="ltr">Hi Michael,<div><br></div><div>We will discuss your proposal in the OTP team once the appropriate people are back from summer vacation.</div><div><br></div><div>Thank you for your patience.</div><div><br></div>
<div>Andreas</div><div><br></div><div>---</div><div><br></div><div>Andreas Schumacher, Erlang/OTP, Ericsson AB</div><div><br><br><div class="gmail_quote">
On 15/07/14 20:06, "Michael Truog" <<a href="mailto:mjtruog@gmail.com">mjtruog@gmail.com</a>> wrote:<br>
<br>
>On 07/14/2014 02:50 PM, Michael Truog wrote:<br>
>> On 07/14/2014 02:32 PM, Siraaj Khandkar wrote:<br>
>>> Correct me if I misunderstand you, but it sounds like you're pointing<br>
>>>to<br>
>>> the fact that success typing can only analyze the success of something<br>
>>> that has been called, so an interface of a library module would not be<br>
>>> analyzed on its own, but only as part of some other code that uses it<br>
>>> (and only the used functions at that). Yes?<br>
>> Not exactly, by a function that is private I mean functions that I<br>
>>would be forced to use "-compile({nowarn_unused_function, [...])" with<br>
>>so that only their -spec usage is significant and the lack of any real<br>
>>use of the function doesn't cause the compiler to create warnings.  That<br>
>>approach may work as a convoluted type assertion but the extra source<br>
>>code required while not being straight-forward for source code reading<br>
>>makes this dirty IMO.<br>
>><br>
>> Part of the reason I think this requires a "-type_assert" is because I<br>
>>see the problem as a preprocessing problem to be handled along with<br>
>>other type creation.<br>
>><br>
>>><br>
>>> Calling those library functions by some private functions is called<br>
>>> testing and there's nothing dirty about it :)<br>
>>><br>
>>><br>
>>> On 07/14/2014 04:49 PM, Michael Truog wrote:<br>
>>>> I am wondering if there is any support for adding a simple type<br>
>>>> assertion to the Erlang syntax.  The statement would be with<br>
>>>> "-type_assert" and it would have the same syntax as "-type" but would<br>
>>>>be<br>
>>>> asserting the developer's assumption of what the type should be.  I am<br>
>>>> finding this functionality necessary outside of normal -spec usage<br>
>>>> (which can help to provide some assertions when used with dialyzer)<br>
>>>> because of generic source code making assumptions that are only<br>
>>>> eventually required at lower layers, later in the execution during<br>
>>>> runtime, not during the initialization, which means that I can not<br>
>>>> easily put the assertion into a -spec unless I use functions that are<br>
>>>> private and not called (a dirty trick).  The "-type_assert" would be<br>
>>>> able to catch type errors at compile time which also helps to<br>
>>>>eliminate<br>
>>>> problems earlier on, avoiding the longer execution time required for<br>
>>>> dialyzer to process everything, so this also helps to speed up normal<br>
>>>> development tasks.  Any thoughts on th<br>
>>>> is?<br>
>>>><br>
>><br>
>Let me clarify this suggestion.  As mentioned by others on IRC (Anthony<br>
>Ramine), it can't be done at compile-time and must involve changes to<br>
>dialyzer.  A concrete example is:<br>
>-type_assert httpc:method() :: head | get | put | post | trace | options<br>
>| delete.<br>
>To make sure the source code breaks (in a dialyzer run) if httpc:method()<br>
>changes to be something like "head | get | put | post | trace | options |<br>
>delete | string()" to support custom methods (valid in HTTP).  This could<br>
>be done with a -spec but it would be nice to only focus on a single type<br>
>and not have extra noise with all the other arguments which would be a<br>
>concern with a -spec.<br>
><br>
>_______________________________________________<br>
>eeps mailing list<br>
><a href="mailto:eeps@erlang.org">eeps@erlang.org</a><br>
><a href="http://erlang.org/mailman/listinfo/eeps" target="_blank">http://erlang.org/mailman/listinfo/eeps</a><br>
<br>
</div><br></div></div>