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" <[email protected]> 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 >[email protected] >http://erlang.org/mailman/listinfo/eeps
_______________________________________________ eeps mailing list [email protected] http://erlang.org/mailman/listinfo/eeps
