it's a no brainer that you can catch most type errors with static type checking. assuming people won't actively try and circumvent the checks like you sometimes must with casts in the c languages. no surprise that it's much easier to create tools in a static type checked language when you nearly always know how to allocate. this usually translates to speed and compile time error checking.
another thing some functional languages do is identify functions as "pure", that is no side effects. no global changes, no I/O of any kind, screen, file etc. no use of impure functions. pure functions should be/are easier to test. given the same parameter values the returns will always be the same. in a static typed language like haskell the analysis is done. in python, you have to identify all callers to the function and infer which types are the parameters and what type the return values. part of the process of marking a function pure in a hypothetical dynamic type inference program would be to verify somehow that no plugins or settings could somehow change the function or one of the functions in the chain in a way that would change the purity. seems like a tall task done statically. I would also mention that pylint faced will similar hard to know types and most definitely epydoc will revert to active inference! which makes the whole idea of safety in a static analyzer suspect. never run a static analyzer on untrusted code with this loophole! this is my recollection, not having followed pylint for many years. it's possible they have since made active inference a default off option. you wouldn't want to check or re-factor a code snippet and rmv /* yet another reason not to run tests or edit as root admin. On May 25, 6:23 am, "Edward K. Ream" <edream...@gmail.com> wrote: > On Thu, May 24, 2012 at 3:17 AM, ne1uno <eltro...@gmail.com> wrote: > > python does obviously have type inference, isn't it good enough? > > Python's interpreter knows the type of objects at run time, that is, > just at the time the interpreter is about to execute an opcode. > > My goal is to deduce interesting things about programs statically. > That is, before the program runs. > > Edward -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to leo-editor@googlegroups.com. To unsubscribe from this group, send email to leo-editor+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
