Le 08/06/2018 à 19:43, Nicolas Cellier a écrit :
...
Yes, I don't know these languages enough, but it's indeed an extensible
specification of types (as expectations).
And this have values both for tools (compiling/browsing/static checks)
and humans.
Oh, and if it helps browser, then it helps humans, because browser is
for humans.
Yes. And the browser is a very limited view of what is currently underway...
Our Smalltalk way would be to use many small Traits specifying the API
and have optional type hints using those Traits
(wasn't it a Strongtalk experiment?)
Not sure. My view at the moment is that we have three ways to reach that
point: expressing intent, or guessing it (or learning it). I think most
code already contain enough information for the last two to work
reasonably well, and approaches that forces you to add optional type
hints (another level of information, that is) are rooted in the past.
But note that such static analysis imposes more limits on code than
necessary:
If I have some method like this:
myMethod
myInstVar doSomething
Then a naive static inferencer will deduce that myInstVar can't be an
instance of MyPartlyPolymorphicClass
because it does not responds to doSomething .
Yes. This is a first concern with types: they rejects incomplete
programs (this is a point discussed in the paper Ben linked).
However, it's a lot more involved to analyze whether myMethod is ever
reached...
For example, if myMethod send was protected with a guard clause or
exception handling...
mainMethod
myInstVar likesToDoSomething ifFalse: [^self].
myInstVar doSomething
anotherMethodSendingDoSomething
[myInstVar doSomething] onError: [IncorrectInput raise]
IOW, since myMethod is not private, I can't guaranty that the library is
correct.
But a more clever analyzer could guaranty that a certain usage of that
library is.
Even in OCaml or Haskell, I'm not sure whether the type inference would
be powerful enough...
Well, using it shows you it is rather impressive...
Looking at 'myInstVar doSomething' it nicely express it as any class
which answer to doSomething
...
And that was the point where I restarted using Smalltalk instead ;)
If a static thing with all its complexity (composite types, inheritence,
modules, etc...) is just giving you the same duck typing as Smalltalk
does, why do I have to put up with all the additional complexity for a
so small gain?
In the time of a short introductory course to OCaml, you understand that
you are spending a lot of time dealing with types, unnecessary dealing
with them, fighting with them, fighting with the type inference
limitations, fighting with the confusing error messages, and that just
to write smalltalk-like code in a smalltalk-like vm (in a less elegant
syntax, to boot).
OK, maybe such liberality is not a good feature in the long term
i.e. necessitates implicit knowledge of crooked implicit pre-conditions
that message arguments must meet,
or render the understanding of code difficult, thus the testing, the
review and the modification worse, etc...
I think a good system would probably learn from source code analysis and
code traces (unit tests execution) to build a complete type model.
I think machine learning is nowadays good enough to do that.
Remember that you don't need it to be "proven sound", just good enough
to help you.
Remember that static type checking catches about 5% of the bugs, and
probably just easy ones. And that an approximate type checker would
probably catch them as well...
But it might be very useful for short term experiments.
Allowing partially correct programs/libraries is an important feature
for the exploring phase.
Essential. Thats the power of dynamic langages and environment
I'd even state that as a rule:
- If you evolve a static type to a language, someone will create a
dynamic typed equivalent of that langage (and a community will use it).
With a corollary:
- since the PL community is only doing static typing, the dynamic typed
equivalent will be badly implemented by applying none of the PL research
that could help.
> I have differently tainted colleagues still thinking that the type help
them
> reading code...
> So, IMO, this assertion reflects the dominant culture rather than
intrinsic
> merits.
I still think that whatever name you use for your variables, you often
convey an idea of a type with your naming choices (i.e. felix is
probably a cat, probably not a dialog box....)
Agree, type and semantics have some coverage, but as I wrote in answer
to Thomas, such inference requires prior knowledge.
Yes. Or better inference.
I once had a colleague choosing completely arbitrary names for
temporaries (like the first name of his children).
Whatever the presence of type declaration (C++), this was really disturbing!
Bad names are bad names, and the type declaration does not help that
much in such case.
Agreed. I'm sure someone or a tool can correctly type-guess out of my
usual set of variable names... i is allways an int in my code :)
Thierry
Nicolas
Thierry
> Nicolas
>
