Re: type access Parent'Class

[Georg Bauhaus <rm.dash-bauhaus@futureapps.de>]

On 22.11.11 09:42, Dmitry A. Kazakov wrote:
> On Mon, 21 Nov 2011 15:45:24 -0800 (PST), Gene wrote:
>
>> However, there exist languages that are strongly typed that don't rely
>> (at least entirely) on name equivalence. Rather they use some
>> variation of structural equivalence. ML is in this category.
>
> Now, if the type behavior is indeterminable from the type's structure, then
> structured equivalence imply weak typing = the behavior varies with the
> interpretation. Otherwise (the behavior is exhaustively determined by
> type's structure) the type system is weak. I don't really know ML, so I can
> only suggest that it falls into the first category.
>
> P.S. Strong typing became a kind of fashion. In these days almost any
> language claims to be strongly typed.

Nice to see people discuss variations of type systems; the following
quote is from notes on reading Haskell programs, for Python programmers,
http://blog.ezyang.com/2011/11/how-to-read-haskell/ .


"Types. Ignore everything you see after :: (similarly, you can ignore type,
  class, instance and newtype. Some people claim that types help them
  understand code; if you're a complete beginner, things like Int and String
  will probably help, and things like LayoutClass and MonadError won't.
  Don't worry too much about it.)"

I am not sure whether or not this is good advice, since indeed beginners
might see types as yet another hurdle that gets in the way of understanding
how things work. But this advice addresses Python programmers, not
people new to programming.  Right now I am seeing, again, what it
means to rewrite portions of a program when there is no static type
system (and no parameter naming). Think of subprograms that have
defaulted parameters, now drop one parameter, permute their order,
... and no compiler (sometimes not even pylint) telling you that this
*will* *cause* a type error at run time---as is the case with Python.
__
Did the author (intentionally) miss the fact that monads, TTBOMK, add
a formal framework for reasoning (somewhat) about I/O in purely
functional programs? If not in terms of time and space, then
surely in terms of data flowing into, flowing through, and flowing
out of functions-whose-profile-includes-world? Ada's I/O related types
kind of allows this, I'd think, to the extent that one can answer
questions: "Which units call operations on types having to
do with I/O"?