[eeps] Fwd: FW: Proposal for -type_assert

[Andreas Schumacher]

Hi Michael,

We will discuss your proposal in the OTP team once the appropriate people
are back from summer vacation.

Thank you for your patience.

Andreas

---

Andreas Schumacher, Erlang/OTP, Ericsson AB


On 15/07/14 20:06, "Michael Truog" <mjtruog@REDACTED> wrote:

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