Re: OO in Python? ^^
On Mon, 12 Dec 2005, Steven D'Aprano wrote:
[color=blue]
> On Sun, 11 Dec 2005 05:48:00 -0800, bonono wrote:
>[color=green]
>> And I don't think Haskell make the programmer do a lot of work(just
>> because of its static type checking at compile time).[/color]
>
> I could be wrong, but I think Haskell is *strongly* typed (just like
> Python), not *statically* typed.[/color]
Haskell is strongly and statically typed - very strongly and very
statically!
However, what it's not is manifestly typed - you don't have to put the
types in yourself; rather, the compiler works it out. For example, if i
wrote code like this (using python syntax):
def f(x):
return 1 + x
The compiler would think "well, he takes some value x, and he adds it to 1
and 1 is an integer, and the only thing you can add to an integer is
another integer, so x must be an integer; he returns whatever 1 + x works
out to, and 1 and x are both integers, and adding two integers makes an
integer, so the return type must be integer", and concludes that you meant
(using Guido's notation):
def f(x: int) -> int:
return 1 + x
Note that this still buys you type safety:
def g(a, b):
c = "{" + a + "}"
d = 1 + b
return c + d
The compiler works out that c must be a string and d must be an int, then,
when it gets to the last line, finds an expression that must be wrong, and
refuses to accept the code.
This sounds like it wouldn't work for complex code, but somehow, it does.
And somehow, it works for:
def f(x):
return x + 1
Too. I think this is due to the lack of polymorphic operator overloading.
A key thing is that Haskell supports, and makes enormous use of, a
powerful system of generic types; with:
def h(a):
return a + a
There's no way to infer concrete types for h or a, so Haskell gets
generic; it says "okay, so i don't know what type a is, but it's got to be
something, so let's call it alpha; we're adding two alphas, and one thing
i know about adding is that adding two things of some type makes a new
thing of that type, so the type of some-alpha + some-alpha is alpha, so
this function returns an alpha". ISTR that alpha gets written 'a, so this
function is:
def h(a: 'a) -> 'a:
return a + a
Although that syntax might be from ML. This extends to more complex
cases, like:
def i(a, b):
return [a, b]
In Haskell, you can only make lists of a homogenous type, so the compiler
deduces that, although it doesn't know what type a and b are, they must be
the same type, and the return value is a list of that type:
def i(a: 'a, b: 'a) -> ['a]:
return [a, b]
And so on. I don't know Haskell, but i've had long conversations with a
friend who does, which is where i've got this from. IANACS, and this could
all be entirely wrong!
[color=blue]
> At least the "What Is Haskell?" page at haskell.org describes the
> language as strongly typed, non-strict, and allowing polymorphic typing.[/color]
When applied to functional languages, 'strict' (or 'eager'), ie that
expressions are evaluated as soon as they are formed; 'non-strict' (or
'lazy') means that expressions can hang around as expressions for a while,
or even not be evaluated all in one go. Laziness is really a property of
the implementation, not the the language - in an idealised pure functional
language, i believe that a program can't actually tell whether the
implementation is eager or lazy. However, it matters in practice, since a
lazy language can do things like manipulate infinite lists.
tom
--
ø¤º°`°º¤ø,,,,ø¤ º°`°º¤ø,,,,ø¤º° `°º¤ø,,,,ø¤º°`° º¤ø
On Mon, 12 Dec 2005, Steven D'Aprano wrote:
[color=blue]
> On Sun, 11 Dec 2005 05:48:00 -0800, bonono wrote:
>[color=green]
>> And I don't think Haskell make the programmer do a lot of work(just
>> because of its static type checking at compile time).[/color]
>
> I could be wrong, but I think Haskell is *strongly* typed (just like
> Python), not *statically* typed.[/color]
Haskell is strongly and statically typed - very strongly and very
statically!
However, what it's not is manifestly typed - you don't have to put the
types in yourself; rather, the compiler works it out. For example, if i
wrote code like this (using python syntax):
def f(x):
return 1 + x
The compiler would think "well, he takes some value x, and he adds it to 1
and 1 is an integer, and the only thing you can add to an integer is
another integer, so x must be an integer; he returns whatever 1 + x works
out to, and 1 and x are both integers, and adding two integers makes an
integer, so the return type must be integer", and concludes that you meant
(using Guido's notation):
def f(x: int) -> int:
return 1 + x
Note that this still buys you type safety:
def g(a, b):
c = "{" + a + "}"
d = 1 + b
return c + d
The compiler works out that c must be a string and d must be an int, then,
when it gets to the last line, finds an expression that must be wrong, and
refuses to accept the code.
This sounds like it wouldn't work for complex code, but somehow, it does.
And somehow, it works for:
def f(x):
return x + 1
Too. I think this is due to the lack of polymorphic operator overloading.
A key thing is that Haskell supports, and makes enormous use of, a
powerful system of generic types; with:
def h(a):
return a + a
There's no way to infer concrete types for h or a, so Haskell gets
generic; it says "okay, so i don't know what type a is, but it's got to be
something, so let's call it alpha; we're adding two alphas, and one thing
i know about adding is that adding two things of some type makes a new
thing of that type, so the type of some-alpha + some-alpha is alpha, so
this function returns an alpha". ISTR that alpha gets written 'a, so this
function is:
def h(a: 'a) -> 'a:
return a + a
Although that syntax might be from ML. This extends to more complex
cases, like:
def i(a, b):
return [a, b]
In Haskell, you can only make lists of a homogenous type, so the compiler
deduces that, although it doesn't know what type a and b are, they must be
the same type, and the return value is a list of that type:
def i(a: 'a, b: 'a) -> ['a]:
return [a, b]
And so on. I don't know Haskell, but i've had long conversations with a
friend who does, which is where i've got this from. IANACS, and this could
all be entirely wrong!
[color=blue]
> At least the "What Is Haskell?" page at haskell.org describes the
> language as strongly typed, non-strict, and allowing polymorphic typing.[/color]
When applied to functional languages, 'strict' (or 'eager'), ie that
expressions are evaluated as soon as they are formed; 'non-strict' (or
'lazy') means that expressions can hang around as expressions for a while,
or even not be evaluated all in one go. Laziness is really a property of
the implementation, not the the language - in an idealised pure functional
language, i believe that a program can't actually tell whether the
implementation is eager or lazy. However, it matters in practice, since a
lazy language can do things like manipulate infinite lists.
tom
--
ø¤º°`°º¤ø,,,,ø¤ º°`°º¤ø,,,,ø¤º° `°º¤ø,,,,ø¤º°`° º¤ø
Comment