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