Path: csiph.com!usenet.pasdenom.info!news.franciliens.net!fdn.fr!usenet-fr.net!nerim.net!novso.com!newsfeed.xs4all.nl!newsfeed3.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
MIME-Version: 1.0
In-Reply-To: <5314bb96$0$29985$c3e8da3$5496439d@news.astraweb.com>
References: <B512F079-4F01-4865-BEF3-07DF94F21832@gmail.com> <mailman.7612.1393810048.18130.python-list@python.org> <4c7dbc57-eef9-4582-aecd-aac13a39b45f@googlegroups.com> <mailman.7633.1393849247.18130.python-list@python.org> <3b54a279-03a1-4a81-a428-ecad6eb16036@googlegroups.com> <mailman.7641.1393855219.18130.python-list@python.org> <216bb5f4-32c4-4f86-a9f4-1b0dd37a2a81@googlegroups.com> <mailman.7644.1393856584.18130.python-list@python.org> <0129a5b9-b85f-4ad5-b5e2-bfb2a48041d5@googlegroups.com> <mailman.7647.1393858917.18130.python-list@python.org> <5314bb96$0$29985$c3e8da3$5496439d@news.astraweb.com>
Date: Tue, 4 Mar 2014 05:37:27 +1100
Subject: Re: Functional programming
From: Chris Angelico <rosuav@gmail.com>
Cc: "python-list@python.org" <python-list@python.org>
Content-Type: text/plain; charset=UTF-8
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.7651.1393871851.18130.python-list@python.org>
Lines: 62
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:67570

On Tue, Mar 4, 2014 at 4:27 AM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> On Tue, 04 Mar 2014 02:01:47 +1100, Chris Angelico wrote:
>
>> This is why it's tricky to put rules in based on type inference. The
>> programmer's intent isn't in the picture.
>
> Of course it is. If I assign 23 to variable x, that signals my intent to
> assign an int to x. By Occam's razor, it is reasonable to extrapolate
> that intent to mean "x is an int", rather than "an int, or a list" or "an
> odd int larger than 7 but smaller than 25", or "any int except 13". Type
> inference picks the type which involves the fewest additional
> assumptions. The programmer can always over-ride the type inference by
> explicitly stating the type.

Yes, and that's fine for most purposes. The problem isn't the
inference, the problem is when rules are created based on that kind of
guess - when the programmer's subsequent actions are governed by a
guess the compiler takes.

x = 23 # Compiler goes: Okay, x takes ints.
x += 5 # Compiler: No prob, int += int --> int
x = str(x) # Compiler: NO WAY! str(int) --> str, not allowed!

It's fine and correct to infer that x is an int, x is an int, x is a
str. It's *not* okay to make the third line a SyntaxError because you
just put a str into an int variable.

>> If Python ever acquires that
>> kind of restriction ("here's a list that can contain only this type /
>> these types of object"), I would hope that it's left up to the
>> programmer, not the compiler, to stipulate.
>
> That's not type inference. That's ancient and annoying obligatory type
> declarations as used by ancient languages with primitive type systems,
> like Pascal and C.

And that's exactly what Haskell apparently has, with homogeneous lists
and no easy way to say that it can take more types.

Python's handling is: A list can hold anything.

Pike's handling is: An array can hold anything, unless you specify
otherwise. You can specify whatever you can code:
array(int(1000..2000) | string('a'..'z') | float) foo = ({1234,
"abcd", 1.2});

Haskell's handling apparently is: A list/array can hold one thing and
one thing only. That 'thing' can be a union, but then you need to be
REALLY explicit about which side is which. It's not possible to
sub-specify a type (like the "string('a'..'x')" type in Pike that will
take only strings with nothing but the first 24 lower-case letters -
not that I've ever needed that), but the compiler can work out
everything else.

The way I see it, Python's form is fully dynamic and open, Pike's is
fully dynamic and the programmer's allowed to explicitly close things,
and Haskell's is rigidly tight. That's not to say that tight is a bad
thing (it's probably good for learning under), but personally, I'd
rather have the freedom.

ChrisA