[issue41460] Translation Error in in Functional Programming HOWTO page

[Terry J. Reedy]

Terry J. Reedy  added the comment:

This tracker is only for the original English version of the docs.  The 
translations are by a different group with different tools and workflow.  This 
page
https://docs.python.org/ja/3/bugs.html#
should not literally translate the instructions for the English version.

Julien, I thought there was something about translations in the devguide but 
cannot find it.  https://devguide.python.org/docquality/ would seen line a good 
place.

--
nosy: +terry.reedy
resolution:  -> third party
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41460] Translation Error in in Functional Programming HOWTO page

[Ned Deily]

Change by Ned Deily :


--
assignee:  -> docs@python
components: +Documentation
nosy: +cocoatomo, docs@python, mdk

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41460] Translation Error in in Functional Programming HOWTO page

[李冰]

New submission from 李冰 :

There seems a translation error in Python Documentation in Functional 
Programming HOWTO page.

The page's English version's url is 
https://docs.python.org/3/howto/functional.html
And the Japanese version's url is 
https://docs.python.org/ja/3/howto/functional.html.

In English version, there is a paragraph: 

"In declarative languages, you write a specification that describes the problem 
to be solved, and the language implementation figures out how to perform the 
computation efficiently. SQL is the declarative language you’re most likely to 
be familiar with; a SQL query describes the data set you want to retrieve, and 
the SQL engine decides whether to scan tables or use indexes, which subclauses 
should be performed first, etc."

The corresponding Japanses translation is this:

"宣言型 言語で書くのは、解くべき問題を説明する仕様書であって、それを効率的に計算処理する方法を見付けるのは言語実装の役目です。SQL 
はおそらく一番よく知られた宣言型言語です; SQL 
のクエリは取得したいデータセットを説明しているだけで、テーブルを走査するかインデックスを使うか、どのサブクローズから実行するか等々を決めるのは SQL 
エンジンなのです。"

In the above paragraph, I think the translator translate the word "subclauses" 
to "サブクローズ", which is wrong.

In Japanese, サブ means sub and クローズ means close, so it is just "subclose", not 
"subclause".

That is all. Thank you.

--
messages: 374713
nosy: mydairyyao
priority: normal
severity: normal
status: open
title: Translation Error in in Functional Programming HOWTO page
type: enhancement

___
Python tracker 
<https://bugs.python.org/issue41460>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34083] Functional Programming HOWTO: Dictionary ordering isn't "essentially random"

[miss-islington]

miss-islington  added the comment:


New changeset 151820e7a0ebe50b3d4fa64e22623c5470f1c56f by Miss Islington (bot) 
in branch '3.7':
bpo-34083: Update dict order in Functional HOWTO (GH-8230)
https://github.com/python/cpython/commit/151820e7a0ebe50b3d4fa64e22623c5470f1c56f


--
nosy: +miss-islington

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34083] Functional Programming HOWTO: Dictionary ordering isn't "essentially random"

[INADA Naoki]

INADA Naoki  added the comment:

Thanks, Stig.
And I'm sorry about I missed Raymond assigned himself.

--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34083] Functional Programming HOWTO: Dictionary ordering isn't "essentially random"

[miss-islington]

Change by miss-islington :


--
pull_requests: +

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34083] Functional Programming HOWTO: Dictionary ordering isn't "essentially random"

[INADA Naoki]

INADA Naoki  added the comment:


New changeset 5e5bbbec467a1569c914a048a94e7597528f92cf by INADA Naoki (Stig 
Johan Berggren) in branch 'master':
bpo-34083: Update dict order in Functional HOWTO (GH-8230)
https://github.com/python/cpython/commit/5e5bbbec467a1569c914a048a94e7597528f92cf


--
nosy: +inada.naoki

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34083] Functional Programming HOWTO: Dictionary ordering isn't "essentially random"

[Stig Johan Berggren]

Change by Stig Johan Berggren :


--
versions: +Python 3.8

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34083] Functional Programming HOWTO: Dictionary ordering isn't "essentially random"

[Stig Johan Berggren]

Change by Stig Johan Berggren :


--
keywords: +patch
pull_requests: +7768
stage:  -> patch review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34083] Functional Programming HOWTO: Dictionary ordering isn't "essentially random"

[Stig Johan Berggren]

Stig Johan Berggren  added the comment:

I'll try to patch it myself.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34083] Functional Programming HOWTO: Dictionary ordering isn't "essentially random"

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Thanks for noticing this.  Do you want to contribute a patch or would you like 
me to just fix it up?

--
assignee: docs@python -> rhettinger
nosy: +rhettinger

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34083] Functional Programming HOWTO: Dictionary ordering isn't "essentially random"

[Stig Johan Berggren]

New submission from Stig Johan Berggren :

The section about iterators in the Functional Programming HOWTO 
(https://docs.python.org/3/howto/functional.html#data-types-that-support-iterators)
 states the following about looping over dictionary keys:

"Note that the order is essentially random, because it’s based on the hash 
ordering of the objects in the dictionary."

Starting with 3.7, dictionary order is guaranteed to be the same as insertion 
order.

--
assignee: docs@python
components: Documentation
messages: 321375
nosy: Stig Johan Berggren, docs@python
priority: normal
severity: normal
status: open
title: Functional Programming HOWTO: Dictionary ordering isn't "essentially 
random"
versions: Python 3.7

___
Python tracker 
<https://bugs.python.org/issue34083>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31575] Functional Programming HOWTO sub-optimal example for reduce

[Raymond Hettinger]

Raymond Hettinger added the comment:

I think the existing code conveys the author's message better than the proposed 
revision.  The example isn't about efficiency; rather, it is about comparing 
several alternative formulations with this one being the weakest of the lost.  
For emphasizing that point and not getting lost in a made-up example, the a[1] 
and b[1] style is more effective.

That's for the suggestion but I don't think it is a win.

--
nosy: +rhettinger
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31575] Functional Programming HOWTO sub-optimal example for reduce

[Anran Yang]

New submission from Anran Yang:

At the end of the Functional Programming HOWTO document 
(https://docs.python.org/3.7/howto/functional.html) the usage of 
reduce/lambda/for loops are compared and discussed. However, the example for 
reduce seems sub-optimal and thus the discussion is not that efficient. The 
example:

total = functools.reduce(lambda a, b: (0, a[1] + b[1]), items)[1]

could be changed to:

total = functools.reduce(lambda total, item: total + item[1], items, 0)

which is much more readable and is actually not much inferior to the loop one 
(though the sum approach is still more concise).

--
assignee: docs@python
components: Documentation
messages: 302950
nosy: Anran Yang, docs@python
priority: normal
severity: normal
status: open
title: Functional Programming HOWTO sub-optimal example for reduce
versions: Python 3.5, Python 3.6, Python 3.7

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue31575>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30538] Functional Programming HOWTO describes one argument itertools.count()

[Mariatta Wijaya]

Mariatta Wijaya added the comment:


New changeset ce40550acd3a8928bb6fef4d4e73642a8a69745d by Mariatta (csabella) 
in branch '3.6':
bpo-30538: Update count() in Functional Programming HOWTO (GH-1919) (GH-1943)
https://github.com/python/cpython/commit/ce40550acd3a8928bb6fef4d4e73642a8a69745d


--

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30538>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30538] Functional Programming HOWTO describes one argument itertools.count()

[Mariatta Wijaya]

Mariatta Wijaya added the comment:


New changeset b32fb6c1fb6cdf019817176f573e60c0923a6e22 by Mariatta (csabella) 
in branch '3.5':
bpo-30538: Update count() in Functional Programming HOWTO (GH-1919) (GH-1944)
https://github.com/python/cpython/commit/b32fb6c1fb6cdf019817176f573e60c0923a6e22


--
nosy: +Mariatta

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30538>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30538] Functional Programming HOWTO describes one argument itertools.count()

[Cheryl Sabella]

Changes by Cheryl Sabella :


--
pull_requests: +2022

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30538] Functional Programming HOWTO describes one argument itertools.count()

[Cheryl Sabella]

Changes by Cheryl Sabella :


--
pull_requests: +2021

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30538] Functional Programming HOWTO describes one argument itertools.count()

[Cheryl Sabella]

Cheryl Sabella added the comment:

Thank you.  And thank you for explaining about the strings.  That's what I 
suspected, so I appreciate you confirming it.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30538] Functional Programming HOWTO describes one argument itertools.count()

[Raymond Hettinger]

Raymond Hettinger added the comment:

Thank you for the PR.

--
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30538] Functional Programming HOWTO describes one argument itertools.count()

[Raymond Hettinger]

Raymond Hettinger added the comment:


New changeset 9be4ff359daa67cde6246494f643ed7cd2825d46 by Raymond Hettinger 
(csabella) in branch 'master':
bpo-30538: Update count() in Functional Programming HOWTO (#1919)
https://github.com/python/cpython/commit/9be4ff359daa67cde6246494f643ed7cd2825d46


--

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30538>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30538] Functional Programming HOWTO describes one argument itertools.count()

[Raymond Hettinger]

Raymond Hettinger added the comment:

> Is it code churn to replace the old style string formatting
> or is that something else that should be done as clean-up?

Let's leave it as is.  Old-style formatting is still valid and is not going 
away.   We consciously decided not to sweep through the docs change the string 
formatting style.  Also, since both occur quite a bit in the wild, it is is 
useful for the docs to show some of both.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30538] Functional Programming HOWTO describes one argument itertools.count()

[Cheryl Sabella]

Cheryl Sabella added the comment:

Thank you.  I've added that.  

This may seem like an odd question, but should I assume that the docs should 
always match the code?  For example, in the Functional HOWTO, I wasn't sure if 
the arguments were left off purposely or if it was just something that hadn't 
been updated.  If the docs should always match, then I wouldn't have to ask so 
many questions if I see another place where this happens.

Also, the example for enumerate is this:

f = open('data.txt', 'r')
for i, line in enumerate(f):
if line.strip() == '':
print('Blank line at line #%i' % i)

Is it code churn to replace the old style string formatting or is that 
something else that should be done as clean-up?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30538] Functional Programming HOWTO describes one argument itertools.count()

[Raymond Hettinger]

Raymond Hettinger added the comment:

> enumerate was described with one argument, but it takes two.
> Should I update that as well?

Yes please.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30538] Functional Programming HOWTO describes one argument itertools.count()

[Cheryl Sabella]

Cheryl Sabella added the comment:

Submitted a PR, thank you.

I changed added the argument for count().  Also I noticed that the link to 
accumulate() was broken, so I fixed that and I added a link to functools in the 
references at the end of the page.

One other thing I noticed was that enumerate was described with one argument, 
but it takes two.  Should I update that as well?

Thanks!

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30538] Functional Programming HOWTO describes one argument itertools.count()

[Cheryl Sabella]

Changes by Cheryl Sabella :


--
pull_requests: +1998

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30538] Functional Programming HOWTO describes one argument itertools.count()

[Raymond Hettinger]

Raymond Hettinger added the comment:

If you would like, go ahead an submit a PR.

--
assignee: docs@python -> rhettinger
nosy: +rhettinger
priority: normal -> low

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30538] Functional Programming HOWTO describes one argument itertools.count()

[Cheryl Sabella]

Changes by Cheryl Sabella :


--
type:  -> enhancement

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30538] Functional Programming HOWTO describes one argument itertools.count()

[Cheryl Sabella]

New submission from Cheryl Sabella:

The Functional Programming HOWTO describes single variable itertools.count 
instead of the two variable version that is linked to.

--
assignee: docs@python
components: Documentation
messages: 294935
nosy: csabella, docs@python
priority: normal
severity: normal
status: open
title: Functional Programming HOWTO describes one argument itertools.count()
versions: Python 3.7

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30538>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

DerbyPy: Louisville Python MeetUp - Functional Programming Introduction - Tuesday March 24 6:30PM

[Alex Sisson]

Functional Programming (FP) is becoming a popular alternative to the 
mainstream paradigms of Object-Oriented Programming and Procedural 
Programming. Sometimes referred to as Value-Oriented Programming, FP 
helps programmers think with more mathematical precision and carries 
many practical benefits to computing, like formal provability, algebraic 
reasoning, stable concurrency, and a host of powerful deductions that 
compilers can leverage for optimization. As a multi-paradigm language, 
Python has received much attention from the FP world. This talk covers 
the basics of the FP design philosophy and demonstrates its use in Python.


* General overview: What is FP?
* Basic premise
* Differences from OOP and Procedural
* Pros/Cons
* Every-day life
* Declarative style
* Dependency injection
* Limiting effects
* More (TBD)
--

*Alex Sisson*
BizDev Strategist
Direct: 502.380.7210
Office: 812.285.8766
Level 12 https://www.level12.io/


--
https://mail.python.org/mailman/listinfo/python-announce-list

   Support the Python Software Foundation:
   http://www.python.org/psf/donations/

Re: Functional programming

[Antoon Pardon]

Op 04-03-14 12:47, Steven D'Aprano schreef:

 On Tue, 04 Mar 2014 11:56:07 +0100, Antoon Pardon wrote:

 Op 04-03-14 09:56, Steven D'Aprano schreef:
 If you
 explicitly say that this is an int, then yes, that should be
 disallowed;
 It's that explicitly part that doesn't follow. Having to manage types
 is the most tedious, boring, annoying, *unproductive* part of languages
 like Java, C and Pascal. Almost always, you're telling the compiler
 stuff that it can work out for itself.
 In the same way writing unit tests is the most tedious, boring,
 annoying, *unproductive* part. 
 Actually, I like writing unit tests. How do you know what the function 
 does until you test it? I'm not a TDD fanatic, but often I write tests 
 before I write the code, and there's really nothing nicer than seeing a 
 whole lot of failing unit tests suddenly start working.

You examine the code. Just like you examine the code to interfere the type. 

 Well, maybe a nice BLT sandwich, when the bacon is nice and lean and the 
 lettuce crisp and the tomato flavourful and not too soggy. But other than 
 that, writing unit tests and seeing them pass is great.

 On the other hand, writing

 int n, m
 double x, y

 and similar three hundred times throughout your program is not terribly 
 exciting. Even when it compiles, it doesn't mean it works.

Even if your unit tests pass, that doesn't mean your program works.
 

 Amost always you are giving the program 
 results it can work out for itself.
 Not even close. I'd like to see the compiler that can work out for itself 
 that this function is buggy:

Who said anything about buggy. If you want to test the function add1, what do 
you do?
You call for example add1(5) and check that it is equal to 6. In other words 
you provide
the result yourself you want the function to produce.

 def sine_rule(side_a, side_b, angle_a):
 Return the angle opposite side_b.
 return math.sin(side_b/side_a)*angle_a


 If you don't remember your Sine Rule from trigonometry, that's okay. 
 Trust me, the function is badly wrong. It's rubbish really. But short of 
 some really impressive AI coupled with a Mathematica-level of maths 
 knowledge, how is the compiler supposed to know that?

 Static type testing, while valuable, cannot tell you that the program 
 does what you wanted it to do.

In the same way it can't interfere the return type you want the function to 
have.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Functional programming

[Antoon Pardon]

Op 04-03-14 16:18, Steven D'Aprano schreef:
 Depends on the type: I suppose you can draw an analogy between records or 
 structs and classes with no methods.

 But I'm not talking about creating types, I'm talking about type 
 declarations.

 int x=2;  # 2 is an int? Who would have guessed!

How about:

decimal[precision=4] x = 2.6;
int[min = -10, max = 20] n = 7;

-- 
Antoon Pardon
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Functional programming

[BartC]

Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote in message
news:5315eec0$0$29985$c3e8da3$54964...@news.astraweb.com...

On Tue, 04 Mar 2014 13:30:04 +, BartC wrote:



Isn't creating classes in Python similar to creating types elsewhere?


Depends on the type: I suppose you can draw an analogy between records or
structs and classes with no methods.

But I'm not talking about creating types, I'm talking about type
declarations.

int x=2;  # 2 is an int? Who would have guessed!


Think of the int as a 'var' then:

var x=2;

Now you're just declaring the names. But writing 'var' as 'int' is exactly
the same amount of work.

However, in the sorts of languages that require you to describe types in
this much detail, then the exact kind of type can be important:
float/integer, signed/unsigned, short/long, character/numeric etc.

Especially when declaring an array or struct element, or a pointer; in these
cases, providing a sample value in initialisation data is more awkward (for
one thing, because you need to initialise the instance, whereas a struct is
usually declared separately as a type).

But I agree that in many cases, an initialised declaration *could* often be
used to infer the likely type without too much trouble:

var x=2 # integer
var y=3.0   # real
var z=A   # probably, a C-style string pointer ('char*')

(And since I'm working on such a language at the moment, I felt obliged to
implement exactly this. And yes, with 10 minutes' effort, something like
this was working, to prove my assertion.

However it is not satisfactory, which is one reason why no well-established
static language is likely to adopt such a feature. It is just too untidy,
too ad-hoc and undisciplined, to say that usually you need to provide an
exact type, but sometimes, in such and such an instance, you don't need to
bother!)

--
Bartc


--
https://mail.python.org/mailman/listinfo/python-list

Re: Functional programming

[Chris Angelico]

On Wed, Mar 5, 2014 at 10:28 PM, BartC b...@freeuk.com wrote:
 But I agree that in many cases, an initialised declaration *could* often be
 used to infer the likely type without too much trouble:

 var x=2 # integer
 var y=3.0   # real
 var z=A   # probably, a C-style string pointer ('char*')

 (And since I'm working on such a language at the moment, I felt obliged to
 implement exactly this. And yes, with 10 minutes' effort, something like
 this was working, to prove my assertion.

 However it is not satisfactory, which is one reason why no well-established
 static language is likely to adopt such a feature. It is just too untidy,
 too ad-hoc and undisciplined, to say that usually you need to provide an
 exact type, but sometimes, in such and such an instance, you don't need to
 bother!)

C++ has something very like this, with the 'auto' keyword. It's not
particularly useful for the examples you give, but can be much more so
when you have templates, iterators, and so on - where the exact type
declaration might be a couple dozen characters of pure syntactic salt,
since you're initializing it to some function's return value.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Functional programming

[Marko Rauhamaa]

Chris Angelico ros...@gmail.com:

 C++ has something very like this, with the 'auto' keyword. It's not
 particularly useful for the examples you give, but can be much more so
 when you have templates, iterators, and so on - where the exact type
 declaration might be a couple dozen characters of pure syntactic salt,
 since you're initializing it to some function's return value.

Java has a widely practiced ideal that you should not tie variables to
class types but instead stick to interface types. Thus, you want to
declare:

   ListInteger li = new LinkedListInteger();

Thing is, though, you can't automatically guess this. After all, you
might be after:

   IterableInteger li = new LinkedListInteger();

or maybe:

   CollectionInteger li = new LinkedListInteger();

This principle doesn't concern only collections. A well-designed
application should specify interfaces for pretty much all classes to
separate design blocks and APIs from implementations du jour.

(Again, something that has no relevance for Python users.)


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Functional programming

[Steven D'Aprano]

On Tue, 04 Mar 2014 17:04:55 +1100, Chris Angelico wrote:

 On Tue, Mar 4, 2014 at 4:35 PM, Steven D'Aprano st...@pearwood.info
 wrote:
 On Tue, 04 Mar 2014 05:37:27 +1100, Chris Angelico wrote:
 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.

 It won't be a Syntax Error, it will be a compile-time Type Error. And,
 yes, it is fine. That's the point of static typing! The tradeoff of
 being able to detect a whole lot of errors *at compile time* is that
 you give up the ability to re-use the same variable for different types
 in a single scope. (You can have an x which is a string elsewhere, just
 not in this scope where it is an int.)
 
 Okay, a compile-type type error, same difference. What I'm saying is
 that the auto-detection can't know what else you plan to do. 

Obviously it can't see the code you haven't written yet, but it can see 
what you *do* do.


 If you
 explicitly say that this is an int, then yes, that should be disallowed;

It's that explicitly part that doesn't follow. Having to manage types 
is the most tedious, boring, annoying, *unproductive* part of languages 
like Java, C and Pascal. Almost always, you're telling the compiler stuff 
that it can work out for itself.

In the same way that managing jumps for GOTO has been automated with for 
loops, while, etc., and managing memory has been automated, there's no 
good reason not to allow the compiler to manage types. Dynamically typed 
languages like Python do so at runtime. Type inference simply allows 
statically typed languages to do the same only at compile time.


[...]
 That Haskell has homogeneous lists is not a property of the type
 system, but a design choice. I'm sure Haskell will also have a tuple or
 record type that allows fields of different types.
 
 If it's not the list type, pick some other. It's not uncommon to want to
 have a record that has different types (C does this with struct, C++ has
 a few more ways to do it); what I'm finding odd is that whatever goes
 into it first is specifying for everything else.

That's because in Haskell the design was made that lists *must* be used 
for homogeneous data. If you read Python documentation from back in the 
1.5 and early 2.x days, there was a *very* strong recommendation that 
lists be used for homogeneous data only and tuples for heterogeneous 
data. This recommendation goes all the way up to Guido.

# Yes
[1, 3, 4, 2, 5, 9]
(1, hello, None, 3.5)

# No
[1, hello, None, 3.5]


That is, lists are for collections of data of arbitrary length, tuples 
are for records or structs with dedicated fields.

That convention is a bit weaker these days than it used to be. Tuples now 
have list-like methods, and we have namedtuple for record/struct-like 
objects with named fields. But still, it is normal to use lists with 
homogeneous data, where there is an arbitrary number of things with 
different values, but all the same kind of thing.

In the case of Haskell, that's more than a mere convention, it's a rule, 
but that's not terribly different from (say) Pascal where you can have an 
array of integer but not an array of integer-or-real.

The thing is though, how often do you really have a situation where you 
have a bunch of arbitrary data, or unknown length, where you don't know 
what type of data it is? Sure, in the interactive interpreter it is 
useful to be able to write

[1, spam, None, [], {}, 0.1, set()]

and I write unit tests with that sort of thing all the time:

for obj in list_of_arbitrary_objects:
self.assertRaises(TypeError, func, obj)

kind of thing. But that doesn't have to be a *list*. It just needs to 
have convenient syntax.


 I have not used Haskell enough to tell you whether you can specify
 subtypes. I know that, at least for numeric (integer) types, venerable
 old Pascal allows you to define subtypes based on integer ranges, so
 I'd be surprised if you couldn't do the same thing in Haskell.

 The flexibility of the type system -- its ability to create subtypes
 and union types -- is independent of whether it is explicitly declared
 or uses type inference.
 
 I'm not sure how you could have type inference with subtypes. How does
 the compiler figure out what subtype of integers is acceptable, such
 that it can reject some?

You seem to be under the impression that type inference means guess what 
the programmer wants, or even read the programmer's mind. Take this 
example:

 x = 5
 x = 7
 x = 11
 x = 17
 x = 27
 
 Should the last one be rejected because it's not prime? How can it know
 that I actually wanted that to be int(3..20)? 

It can't, of course, any more than I could, or anyone other than you. But 
if you asked a hundred people what all those values of x had in common, 

Re: Functional programming

[BartC]

Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote in message
news:5314bb96$0$29985$c3e8da3$54964...@news.astraweb.com...


Think about the sort of type declarations you have to do in (say) Pascal,
and consider how stupid the compiler must be:

function add_one(x: integer):integer;
 begin
   add_one := x+1;
 end;

Given that x is an integer, and that you add 1 (also an integer) to it,
is it really necessary to tell the compiler that add_one returns an
integer? What else could the output type be?

This was state of the art back in 1970, but these days, if the compiler
cannot *at least* infer the type of the return result of a function given
the argument types, the static type system is too dumb to bother with.


To me that is perfectly reasonable. This kind of language, while it allows
expressions of mixed numeric types, treats each kind of number type as
different: integer and real, even signed and unsigned integer, and there
might be short, medium and long versions of each! And Pascal has an
unlimited number of scalar types too.

The compiler could make a guess at what the intended result might be, based
on a hundred add_one:= assignments, all with a slightly different type on 
the right-hand-side, and perhaps choose a type that encompasses all the 
possibilities (although it might erroneously decide the result is real, 
based on one of those hundred, and use floating point for all of them).


But then someone edits the code, and this time the guess will be different!
For a static language such as this, type-discipline is important. And even
if the compiler gets it right, a human reading the code would have trouble
determining the return type, except in trivial examples like this.

Putting in an explicit return type is the simplest way to go.

--
Bartc 


--
https://mail.python.org/mailman/listinfo/python-list

Re: Functional programming

[Antoon Pardon]

Op 04-03-14 09:56, Steven D'Aprano schreef:



 If you
 explicitly say that this is an int, then yes, that should be disallowed;
 It's that explicitly part that doesn't follow. Having to manage types 
 is the most tedious, boring, annoying, *unproductive* part of languages 
 like Java, C and Pascal. Almost always, you're telling the compiler stuff 
 that it can work out for itself.

In the same way writing unit tests is the most tedious, boring, annoying,
*unproductive* part. Amost always you are giving the program results
it can work out for itself.

-- 

Antoon Pardon

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Functional programming

[Steven D'Aprano]

On Tue, 04 Mar 2014 11:56:07 +0100, Antoon Pardon wrote:

 Op 04-03-14 09:56, Steven D'Aprano schreef:
 
 

 If you
 explicitly say that this is an int, then yes, that should be
 disallowed;
 It's that explicitly part that doesn't follow. Having to manage types
 is the most tedious, boring, annoying, *unproductive* part of languages
 like Java, C and Pascal. Almost always, you're telling the compiler
 stuff that it can work out for itself.
 
 In the same way writing unit tests is the most tedious, boring,
 annoying, *unproductive* part. 

Actually, I like writing unit tests. How do you know what the function 
does until you test it? I'm not a TDD fanatic, but often I write tests 
before I write the code, and there's really nothing nicer than seeing a 
whole lot of failing unit tests suddenly start working.

Well, maybe a nice BLT sandwich, when the bacon is nice and lean and the 
lettuce crisp and the tomato flavourful and not too soggy. But other than 
that, writing unit tests and seeing them pass is great.

On the other hand, writing

int n, m
double x, y

and similar three hundred times throughout your program is not terribly 
exciting. Even when it compiles, it doesn't mean it works.

 Amost always you are giving the program 
 results it can work out for itself.

Not even close. I'd like to see the compiler that can work out for itself 
that this function is buggy:

def sine_rule(side_a, side_b, angle_a):
Return the angle opposite side_b.
return math.sin(side_b/side_a)*angle_a


If you don't remember your Sine Rule from trigonometry, that's okay. 
Trust me, the function is badly wrong. It's rubbish really. But short of 
some really impressive AI coupled with a Mathematica-level of maths 
knowledge, how is the compiler supposed to know that?

Static type testing, while valuable, cannot tell you that the program 
does what you wanted it to do.



-- 
Steven D'Aprano
http://import-that.dreamwidth.org/
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Functional programming

[Chris Angelico]

On Tue, Mar 4, 2014 at 10:47 PM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
 Not even close. I'd like to see the compiler that can work out for itself
 that this function is buggy:

 def sine_rule(side_a, side_b, angle_a):
 Return the angle opposite side_b.
 return math.sin(side_b/side_a)*angle_a


 If you don't remember your Sine Rule from trigonometry, that's okay.
 Trust me, the function is badly wrong. It's rubbish really.

I'm not entirely sure what it's trying to do, but you're taking the
sine of a ratio. That... seems wrong, gut-feeling-wise. You take the
sine of an angle and get a ratio, or the arcsine of a ratio and get an
angle. Also, trig functions apply only to right triangles, so the
other angle is either going to be 90°-angle_a or 90°, depending on
whether you want the angle opposite the hypotenuse or not.

But it's years since I studied any of that.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Functional programming

[BartC]

Steven D'Aprano st...@pearwood.info wrote in message
news:53159540$0$2923$c3e8da3$76491...@news.astraweb.com...


It's that explicitly part that doesn't follow. Having to manage types
is the most tedious, boring, annoying, *unproductive* part of languages
like Java, C and Pascal. Almost always, you're telling the compiler stuff
that it can work out for itself.


Isn't creating classes in Python similar to creating types elsewhere?


In the same way that managing jumps for GOTO has been automated with for
loops, while, etc., and managing memory has been automated, there's no
good reason not to allow the compiler to manage types. Dynamically typed
languages like Python do so at runtime. Type inference simply allows
statically typed languages to do the same only at compile time.


Eliminating 'goto' is simple code-generation logic; type inference is more
of an art.

But declaring variables is not just about specifying a type; it registers
the name too so that misspelled names can be picked up very early rather
than at runtime (and that's if you're lucky).


# Yes
[1, 3, 4, 2, 5, 9]
(1, hello, None, 3.5)

# No
[1, hello, None, 3.5]


That is, lists are for collections of data of arbitrary length, tuples
are for records or structs with dedicated fields.

That convention is a bit weaker these days than it used to be. Tuples now
have list-like methods, and we have namedtuple for record/struct-like
objects with named fields.


(Aren't tuples immutable? They wouldn't work well for records then, because 
it would be impossible to change a field of a record.)


--
Bartc 


--
https://mail.python.org/mailman/listinfo/python-list

Re: Functional programming

[Chris Angelico]

On Wed, Mar 5, 2014 at 12:30 AM, BartC b...@freeuk.com wrote:
 But declaring variables is not just about specifying a type; it registers
 the name too so that misspelled names can be picked up very early rather
 than at runtime (and that's if you're lucky).

The two are separate. I don't know of any language that lets you
declare a type without catching the names, but there's certainly the
other way around (ECMAScript just has var x, y, z). It'd be
theoretically possible to have a Python-style variable inference
system (if I can call it that - the rules of if you assign to it and
don't declare it as global/nonlocal, it's local) coupled with an
optional type declaration system; if you don't declare, then it can
hold anything. I just don't know of any language that does it.

 That convention is a bit weaker these days than it used to be. Tuples now
 have list-like methods, and we have namedtuple for record/struct-like
 objects with named fields.

 (Aren't tuples immutable? They wouldn't work well for records then, because
 it would be impossible to change a field of a record.)

They are, including namedtuples. But an object() can be used that way,
if you want.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Functional programming

[Mark Lawrence]

On 04/03/2014 13:30, BartC wrote:


But declaring variables is not just about specifying a type; it registers
the name too so that misspelled names can be picked up very early rather
than at runtime (and that's if you're lucky).



I've said before that this, to me, is one of the major downsides of 
dynamic typing.  Once a statically typed language has been compiled the 
programmer can head down to the pub.  The programmer using dynamically 
typed languages has to hang around doing long, boring, tedious testing. 
 Unless they're using an IDE like Pydev and have Pylint turned on so it 
picks up errors as they type, in which case they can also head down to 
the pub.


--
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.


Mark Lawrence

---
This email is free from viruses and malware because avast! Antivirus protection 
is active.
http://www.avast.com


--
https://mail.python.org/mailman/listinfo/python-list

Re: Functional programming

[Chris Angelico]

On Wed, Mar 5, 2014 at 1:05 AM, Mark Lawrence breamore...@yahoo.co.uk wrote:
 On 04/03/2014 13:30, BartC wrote:


 But declaring variables is not just about specifying a type; it registers
 the name too so that misspelled names can be picked up very early rather
 than at runtime (and that's if you're lucky).


 I've said before that this, to me, is one of the major downsides of dynamic
 typing.  Once a statically typed language has been compiled the programmer
 can head down to the pub.  The programmer using dynamically typed languages
 has to hang around doing long, boring, tedious testing.  Unless they're
 using an IDE like Pydev and have Pylint turned on so it picks up errors as
 they type, in which case they can also head down to the pub.

Type declarations are orthogonal to that. ECMAScript, as mentioned,
just has 'var'. If it didn't have the implicit variables rule
(anything not explicitly declared goes onto the primary object), it'd
give you exactly that functionality, without any type checking at all.

And there's not static and dynamic. It's a spectrum. Each time you
move one direction, you gain a set of potential bugs that the language
can detect; each time you move the other direction, you save on
keyboarding. But at no time do you truly get away from the need to
test, because anything non-trivial can't be proven by the language
anyway.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

OT Sine Rule [was Re: Functional programming]

[Steven D'Aprano]

On Wed, 05 Mar 2014 00:01:01 +1100, Chris Angelico wrote:

 On Tue, Mar 4, 2014 at 10:47 PM, Steven D'Aprano
 steve+comp.lang.pyt...@pearwood.info wrote:
 Not even close. I'd like to see the compiler that can work out for
 itself that this function is buggy:

 def sine_rule(side_a, side_b, angle_a):
 Return the angle opposite side_b. return
 math.sin(side_b/side_a)*angle_a


 If you don't remember your Sine Rule from trigonometry, that's okay.
 Trust me, the function is badly wrong. It's rubbish really.
 
 I'm not entirely sure what it's trying to do, 

The Sine Rule applies to any triangle, right-angled or not. I'm not going 
to try to draw an ASCII-art triangle here, so you just have to imagine 
one. Label the three sides a, b and c. Now label the angle opposite 
each side as A, B and C, so angle A is opposite side a, and so 
forth. The Sine Rule, or Law of Sines, tells us that the ratio of the 
length of a side and the sine of the angle opposite that side is constant 
for any triangle. That is:

a/sin(A) == b/sin(B) == c/sin(C)


Given any two sides and one corresponding angle, let's say a, b and A, 
you can calculate the other angle B. The correct formula would be:

B = asin( sin(A)*b/a )

which is not what my bogus function does.


 but you're taking the sine
 of a ratio. That... seems wrong, gut-feeling-wise. 

Well of course it's wrong. Given the intended geometric meanings of the 
function parameters, the quantity calculated is meaningless. But 
mathematically, it's okay to calculate the sine of a ratio of two other 
quantities. It's just a number. These even a whole lot of double-angle 
formulae that allow you to calculate sin(2*x) given sin(x), or sin(x/2) 
given sin(x), etc.

But, giving that ratio physical or geometric meaning is another story, 
and in this case the semantics of the function is entirely bogus. That 
was my point -- the compiler cannot possibly tell what the function is 
intended to do, it can only check that it is self-consistent.


 You take the sine of
 an angle and get a ratio, or the arcsine of a ratio and get an angle.
 Also, trig functions apply only to right triangles, 

Not quite. Or to put it another way, not at all :-)

Trig functions are *defined* in terms of right-angled triangles, but 
(say) the sine of 30° is 0.5 regardless of whether that 30° angle is in a 
right-angled triangle, an acute triangle or an obtuse triangle. 30° is 
30° regardless of what the rest of the triangle is doing.



Ask-me-about-versine-and-haversine-ly y'rs,

-- 
Steven D'Aprano
http://import-that.dreamwidth.org/
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: OT Sine Rule [was Re: Functional programming]

[Tim Chase]

On 2014-03-04 14:25, Steven D'Aprano wrote:
 Ask-me-about-versine-and-haversine-ly y'rs,

More interested in a karosine, cuisine, and a limousine. ;-)

-tkc


-- 
https://mail.python.org/mailman/listinfo/python-list

Re: OT Sine Rule [was Re: Functional programming]

[Mark Lawrence]

On 04/03/2014 14:37, Tim Chase wrote:

On 2014-03-04 14:25, Steven D'Aprano wrote:

Ask-me-about-versine-and-haversine-ly y'rs,


More interested in a karosine, cuisine, and a limousine. ;-)

-tkc




What do you get if you differentiate versines, haversines, karosines, 
cuisines and limosines?


--
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.


Mark Lawrence

---
This email is free from viruses and malware because avast! Antivirus protection 
is active.
http://www.avast.com


--
https://mail.python.org/mailman/listinfo/python-list

Re: Functional programming

[Steven D'Aprano]

On Tue, 04 Mar 2014 14:05:44 +, Mark Lawrence wrote:

 Once a statically typed language has been compiled the programmer can
 head down to the pub.

It compiles? Quick! Ship it!

Well, that certainly explains the quality of some programs...




-- 
Steven D'Aprano
http://import-that.dreamwidth.org/
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Functional programming

[Grant Edwards]

On 2014-03-03, Ben Finney ben+pyt...@benfinney.id.au wrote:
 Gregory Ewing greg.ew...@canterbury.ac.nz writes:

 Just because the compiler *can* infer the return type doesn't
 necessarily mean it *should*. When I was playing around with
 functional languages, I ended up adopting the practice of always
 declaring the types of my functions, because it helps the *human*
 reader.

 Sure. In a duck-typed language like Python, it is still helpful to the
 human reader to document the *meaning* of each parameter, beyond what is
 indicated by the name. We have reStructuredText and docstrings for this
 purpose.

 def frobnicate(flang, splets, queeble=False):
  Righteously frobnicate the flang.

 :param flang: A file-like object, opened for reading.
 :param splets: A sequence of unprocessed Splet instances.
 :param queeble: If ``True``, re-vitrify the flang during
 frobnication.
 :return: A new list of processed Splet instances.

 The flang is frobnicated according to the Weebly-Ruckford
 algorithm.

 
 for line in flang:

That's fine, if the comments are correct.  

I'm currently working with a library of third party code that was
internally documented like that (though in a different language, with
a slightly different comment formatting). Then they run it through
something (Doxygen?) to produce a giant .CHM file that's pretty much
useless to those of us running Linux.  It turns out it's just as well
I can't read a CHM file: the documentation in the comments is wrong
often enough that I've learned it's best to ignore it completely.
Sometimes the number of parameters and their names don't even match up
with the comments. Sometimes the docstring is from a completely
different function which was apparently cut/pasted and then reworked
to do something else.

After a couple decades of working in software development, I've
decided that comments like that are not correct often enough to be
useful. You've got to reverse-engineer the code if there's no such
comment.  If there _is_ a comment, you have to reverse-engineer the
code to see of the comment is accurate.

-- 
Grant Edwards   grant.b.edwardsYow! I'm young ... I'm
  at   HEALTHY ... I can HIKE
  gmail.comTHRU CAPT GROGAN'S LUMBAR
   REGIONS!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: OT Sine Rule [was Re: Functional programming]

[Chris Angelico]

On Wed, Mar 5, 2014 at 1:25 AM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:

 The Sine Rule, or Law of Sines, tells us that the ratio of the
 length of a side and the sine of the angle opposite that side is constant
 for any triangle. That is:

 a/sin(A) == b/sin(B) == c/sin(C)

Oh! Right. Now I remember. Yeah. Still, it looks wrong to... well,
what I said next:

 On Wed, 05 Mar 2014 00:01:01 +1100, Chris Angelico wrote:
 but you're taking the sine
 of a ratio. That... seems wrong, gut-feeling-wise.

 Well of course it's wrong. Given the intended geometric meanings of the
 function parameters, the quantity calculated is meaningless. But
 mathematically, it's okay to calculate the sine of a ratio of two other
 quantities. It's just a number. These even a whole lot of double-angle
 formulae that allow you to calculate sin(2*x) given sin(x), or sin(x/2)
 given sin(x), etc.

What I meant there was ratio of side lengths. The definition of sine
is that, in a right triangle, the ratio of the lengths of the side
opposite an angle and the hypotenuse is the sine of that angle. So I
consider sine to be a function that takes an angle and returns a
side-length-ratio, and arcsine does the reverse. It's like asking for
the length of an integer and getting back a string - it just looks
wrong. The sine of double an angle makes sense - it's still an angle.
You don't multiply an angle by a side length, you don't take the sine
of a number of meters per second, and you don't calculate the number
of parsecs it takes you to get to Kessel. The units are just wrong.
Maybe there's some specific situation where that makes sense, but I'd
call it formula smell. And note that your corrected form still
applies the functions the way I describe - the units are maintained.
(Technically the sine of an angle is a pure number, a straight ratio.
I'm not sure that pure number is a unit - it's kinda the absence of
any unit - but that's still something to be maintained.)

 But, giving that ratio physical or geometric meaning is another story,
 and in this case the semantics of the function is entirely bogus. That
 was my point -- the compiler cannot possibly tell what the function is
 intended to do, it can only check that it is self-consistent.

Right. It's a consequence of a type system that distinguishes floating
point from string, but not angle_in_degrees from length_in_meters.
It's theoretically possible to build a type system that's like that
(sometimes you can subclass to do that, and create explicit operations
only), but I've never really felt the need to. But that's the theory
behind some forms of Hungarian notation - identifying a data type
concept that's broader than the compiler knows.

 You take the sine of
 an angle and get a ratio, or the arcsine of a ratio and get an angle.
 Also, trig functions apply only to right triangles,

 Not quite. Or to put it another way, not at all :-)

 Trig functions are *defined* in terms of right-angled triangles, but
 (say) the sine of 30° is 0.5 regardless of whether that 30° angle is in a
 right-angled triangle, an acute triangle or an obtuse triangle. 30° is
 30° regardless of what the rest of the triangle is doing.

Yes indeed. Like I said, I'm a bit rusty on all that, and forgot about
the ways of using them in non-right triangles :) But that 0.5 doesn't
have intrinsic meaning if you don't have a right triangle around it;
it needs something else to give it useful meaning, like another
angle's sine.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Functional programming

[Chris Angelico]

On Wed, Mar 5, 2014 at 1:55 AM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
 On Tue, 04 Mar 2014 14:05:44 +, Mark Lawrence wrote:

 Once a statically typed language has been compiled the programmer can
 head down to the pub.

 It compiles? Quick! Ship it!

 Well, that certainly explains the quality of some programs...

It explains the quality of other programs too. They were written after
the programmer came back from the pub.

*ducks for cover*

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Functional programming

[Steven D'Aprano]

On Tue, 04 Mar 2014 13:30:04 +, BartC wrote:

 Steven D'Aprano st...@pearwood.info wrote in message
 news:53159540$0$2923$c3e8da3$76491...@news.astraweb.com...
 
 It's that explicitly part that doesn't follow. Having to manage types
 is the most tedious, boring, annoying, *unproductive* part of languages
 like Java, C and Pascal. Almost always, you're telling the compiler
 stuff that it can work out for itself.
 
 Isn't creating classes in Python similar to creating types elsewhere?

Depends on the type: I suppose you can draw an analogy between records or 
structs and classes with no methods.

But I'm not talking about creating types, I'm talking about type 
declarations.

int x=2;  # 2 is an int? Who would have guessed!


 In the same way that managing jumps for GOTO has been automated with
 for loops, while, etc., and managing memory has been automated, there's
 no good reason not to allow the compiler to manage types. Dynamically
 typed languages like Python do so at runtime. Type inference simply
 allows statically typed languages to do the same only at compile time.
 
 Eliminating 'goto' is simple code-generation logic; type inference is
 more of an art.

Type inference is nothing like an art. It's a mathematically provable 
correct algorithm from the lambda calculus.

http://en.wikipedia.org/wiki/Hindley%E2%80%93Milner

Unfortunately the wikipedia page above appears to be complete 
gobbledygook if you aren't an expert in the lambda calculus, which I 
certainly am not, so I'm not even going to try to explain how it works. 
But there is no *guessing* involved, no heuristics which only sometimes 
work. There are certain assumptions involved, e.g. that the type of 
something is, in the absence of a declaration otherwise, the *most* 
general thing it could be (e.g. it's an integer rather than it's an 
integer between 3 and 27). But they're reasonable, practical assumptions.


 But declaring variables is not just about specifying a type; it
 registers the name too so that misspelled names can be picked up very
 early rather than at runtime (and that's if you're lucky).

You don't need to have static typing to have declared variables. The two 
are independent. E.g. one might have a system like Python, except you 
have to declare your variables before using them:

global x
local a
a = x+1
...

Or a system like (ancient) BASIC, where the type of the variable is given 
by the name. E.g. X is a numeric variable, and X$ is a string variable. 
There's no need for a separate declaration, because the presence or 
absence of the $ sign tells the interpreter whether it is a number or 
string variable. Perl, PHP and many other languages also use sigils.

Having to declare variables, and having to declare their type, are 
independent.


-- 
Steven D'Aprano
http://import-that.dreamwidth.org/
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: OT Sine Rule [was Re: Functional programming]

[Tim Chase]

On 2014-03-04 14:42, Mark Lawrence wrote:
 What do you get if you differentiate versines, haversines,
 karosines, cuisines and limosines?

Well, with cuisines, you can usually differentiate by seasoning:
your Tex/Mex is spicier and tends to have chili  cumin, while your
Indian tends to lean more towards the garam masala.

With your limosines, you have stretch and non-stretch, and some are
these crazy contraptions made out of Hummers or buses rather than
luxury sedans.

And if I could spell kerosine instead of karosine, I guess they
would differentiate from other hydrocarbons by the length of the
carbon chain. ;-)

-tkc


-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Functional programming

[Steven D'Aprano]

On Tue, 04 Mar 2014 14:59:51 +, Grant Edwards wrote:

 After a couple decades of working in software development, I've decided
 that comments like that are not correct often enough to be useful.
 You've got to reverse-engineer the code if there's no such comment.  If
 there _is_ a comment, you have to reverse-engineer the code to see of
 the comment is accurate.

http://import-that.dreamwidth.org/956.html




-- 
Steven D'Aprano
http://import-that.dreamwidth.org/
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Functional programming

[Chris Angelico]

On Wed, Mar 5, 2014 at 2:18 AM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
 You don't need to have static typing to have declared variables. The two
 are independent. E.g. one might have a system like Python, except you
 have to declare your variables before using them:

 global x
 local a
 a = x+1

Aside: If you declare your locals, you shouldn't need to declare your
globals. Though I could imagine a rule that global rebinding still
needs to be declared, but you certainly shouldn't need to declare
nonlocal if you have a local declaration. Absence of local =
nonlocal.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Functional programming

[Steven D'Aprano]

On Wed, 05 Mar 2014 02:28:17 +1100, Chris Angelico wrote:

 On Wed, Mar 5, 2014 at 2:18 AM, Steven D'Aprano
 steve+comp.lang.pyt...@pearwood.info wrote:
 You don't need to have static typing to have declared variables. The
 two are independent. E.g. one might have a system like Python, except
 you have to declare your variables before using them:

 global x
 local a
 a = x+1
 
 Aside: If you declare your locals, you shouldn't need to declare your
 globals. Though I could imagine a rule that global rebinding still needs
 to be declared, but you certainly shouldn't need to declare nonlocal if
 you have a local declaration. Absence of local = nonlocal.

You missed that the purpose of the declaration is to avoid accidental 
typos:

local process
procces = 1234


With declarations, the compiler can catch some typos at compile-time.




-- 
Steven D'Aprano
http://import-that.dreamwidth.org/
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Functional programming

[Chris Angelico]

On Wed, Mar 5, 2014 at 2:45 AM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
 Aside: If you declare your locals, you shouldn't need to declare your
 globals. Though I could imagine a rule that global rebinding still needs
 to be declared, but you certainly shouldn't need to declare nonlocal if
 you have a local declaration. Absence of local = nonlocal.

 You missed that the purpose of the declaration is to avoid accidental
 typos:

 local process
 procces = 1234


 With declarations, the compiler can catch some typos at compile-time.

Yep, but if you're declaring all your locals (and globals get declared
at module scope - they're just local to a different and broader
scope), then procces will never have been declared anywhere. You
shouldn't need to re-declare everything you're referencing from an
outer scope.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Functional programming

[MRAB]

On 2014-03-04 15:13, Chris Angelico wrote:

On Wed, Mar 5, 2014 at 1:55 AM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:

On Tue, 04 Mar 2014 14:05:44 +, Mark Lawrence wrote:


Once a statically typed language has been compiled the programmer can
head down to the pub.


It compiles? Quick! Ship it!

Well, that certainly explains the quality of some programs...


It explains the quality of other programs too. They were written after
the programmer came back from the pub.

*ducks for cover*


Or compiled before and tested after?

--
https://mail.python.org/mailman/listinfo/python-list

Re: Functional programming

[Marko Rauhamaa]

Antoon Pardon antoon.par...@rece.vub.ac.be:

 In the same way writing unit tests is the most tedious, boring,
 annoying, *unproductive* part. Amost always you are giving the program
 results it can work out for itself.

Undoubtedly, explicit type declarations add a dimension of quality to
software. However, they also significantly reduce readability and tempt
you to dirty shortcuts (to avoid writing truckloads of boilerplate
code).

On the balance, I estimate the explicit style reduces code quality.

Example (found by a random Google search):

===JAVA BEGIN===

class WrappedSqlException extends RuntimeException {
static final long serialVersionUID = 2013080804480L;
public WrappedSqlException(SQLException cause) { super(cause); }
public SQLException getSqlException() { return (SQLException) getCause(); }
}

public ConnectionPool(int maxConnections, String url) throws SQLException {
try {
super(() - {
try {
return DriverManager.getConnection(url);
} catch ( SQLException ex ) {
throw new WrappedSqlException(ex);
}
}, maxConnections);
} catch (WrappedSqlException wse) {
throw wse.getSqlException();
}
}

===JAVA END=

===PYTHON BEGIN=

def __init__(self, max_connections, url):
super().__init__(lambda: DriverManager.get_connection(url), max_connections)

===PYTHON END===

or, a bit less cryptically:

===PYTHON BEGIN=

def __init__(self, max_connections, url):
def get_connection():
return DriverManager.get_connection(url)

super().__init__(get_connection, max_connections)

===PYTHON END===


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Functional programming

[Chris Angelico]

On Wed, Mar 5, 2014 at 6:49 AM, Marko Rauhamaa ma...@pacujo.net wrote:
 public ConnectionPool(int maxConnections, String url) throws SQLException {
 try {
 super(() - {
 try {
 return DriverManager.getConnection(url);
 } catch ( SQLException ex ) {
 throw new WrappedSqlException(ex);
 }
 }, maxConnections);
 } catch (WrappedSqlException wse) {
 throw wse.getSqlException();
 }
 }

 ===JAVA END=

 ===PYTHON BEGIN=

 def __init__(self, max_connections, url):
 super().__init__(lambda: DriverManager.get_connection(url), 
 max_connections)

You're not doing the same thing, though. The Java rigmarole is to
ensure that an SQLException thrown in getConnection will propagate up,
despite (presumably) something inside the equivalent of
super().__init__ that swallows SQLExceptions. Of course it looks
tidier when you don't do the messy bit.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Functional programming

[Marko Rauhamaa]

Chris Angelico ros...@gmail.com:

 On Wed, Mar 5, 2014 at 6:49 AM, Marko Rauhamaa ma...@pacujo.net wrote:
 public ConnectionPool(int maxConnections, String url) throws SQLException {
 try {
 super(() - {
 try {
 return DriverManager.getConnection(url);
 } catch ( SQLException ex ) {
 throw new WrappedSqlException(ex);
 }
 }, maxConnections);
 } catch (WrappedSqlException wse) {
 throw wse.getSqlException();
 }
 }

 ===JAVA END=

 You're not doing the same thing, though. The Java rigmarole is to
 ensure that an SQLException thrown in getConnection will propagate up,
 despite (presumably) something inside the equivalent of
 super().__init__ that swallows SQLExceptions. Of course it looks
 tidier when you don't do the messy bit.

See URL: http://stackoverflow.com/questions/14039995/
java-8-mandatory-checked-exceptions-handling-in-lambd
a-expressions-for-standard.

The rigmarole is trying to get around Java's mandatory exception
handling limitations, which Python doesn't have.

You are not allowed to pass a lambda to the super constructor that
throws an SQLException. To get around the limitation, a RuntimeException
wrapper is created to smuggle the SQLException through the compiler's
defenses. Any code is free to throw a RuntimeException.

I don't know, though, if this is that good of an example. I don't know
if the lambda gets called within the constructor or, as I would guess,
whenever a new connection is needed. The whole wrapping exercise would
be for nothing, then.

Here's a more prosaic example (probably contains errors):

===JAVA BEGIN===

private MapTaxpayerIdNumber, MapFormId, Form filings =
new TreeMapTaxpayerIdNumber, MapFormId, Form();

class FormFiling {
public FormFiling(TaxpayerIdNumber taxpayerId, Form form) {
this.taxpayerId = taxpayerId;
this.form = form;
}

public TaxpayerIdNumber getTaxpayerId() { return taxpayerId; }
public Form getForm() { return form; }

private TaxpayerIdNumber taxpayerId;
private Form form;
};

ListFormFiling getForms(FormId formId)
{
ListFormFiling forms = new LinkedListFormFiling();
for (Map.EntryTaxpayerIdNumber, MapFormId, Form payerEntry :
 filings.entrySet()) {
TaxpayerIdNumber taxpayerId = payerEntry.getKey();
MapFormId, Form filing = payerEntry.getValue();
if (filing.containsKey(formId))
forms.add(new FormFiling(taxpayerId, filing.get(formId)))
}
return forms;
}

===JAVA END=

===PYTHON BEGIN=

filings = {}

def getForms(formId):
forms = []
for taxpayerId, filing in filings.iteritems():
 if formId in filing:
 forms.append((taxpayerId, filing[formId]))
return forms

===PYTHON END===

or:

===PYTHON BEGIN=

filings = {}

def getForms(formId):
return ((taxpayerId, filing[formId])
for (taxpayerId, filing) in filings.iteritems()
if formId in filing)

===PYTHON END===


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Functional programming

[Chris Angelico]

On Wed, Mar 5, 2014 at 7:50 AM, Marko Rauhamaa ma...@pacujo.net wrote:
 The rigmarole is trying to get around Java's mandatory exception
 handling limitations, which Python doesn't have.

 You are not allowed to pass a lambda to the super constructor that
 throws an SQLException. To get around the limitation, a RuntimeException
 wrapper is created to smuggle the SQLException through the compiler's
 defenses. Any code is free to throw a RuntimeException.


Oh, it's THAT problem. Well, it's still not really a fair comparison
of declared types. It shows how Python's much easier to work with, but
what you're showing off is the simpler exception handling :)

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Functional programming

[Marko Rauhamaa]

Chris Angelico ros...@gmail.com:

 Oh, it's THAT problem. Well, it's still not really a fair comparison
 of declared types. It shows how Python's much easier to work with, but
 what you're showing off is the simpler exception handling :)

The other example I gave is really bread-and-butter Java. An ergonomic
disaster and takes some staring at to figure out what's going on.

Note that Java doesn't possess typedef's so you really are pretty much
forced to write those  ,  's a lot.


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Functional programming

[Chris Angelico]

On Wed, Mar 5, 2014 at 8:21 AM, Marko Rauhamaa ma...@pacujo.net wrote:
 Chris Angelico ros...@gmail.com:

 Oh, it's THAT problem. Well, it's still not really a fair comparison
 of declared types. It shows how Python's much easier to work with, but
 what you're showing off is the simpler exception handling :)

 The other example I gave is really bread-and-butter Java. An ergonomic
 disaster and takes some staring at to figure out what's going on.

 Note that Java doesn't possess typedef's so you really are pretty much
 forced to write those  ,  's a lot.

C++ at least has typedefs, and in the newer standards, the 'auto'
keyword was repurposed.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Functional programming

[Marko Rauhamaa]

Chris Angelico ros...@gmail.com:

 C++ at least has typedefs, and in the newer standards, the 'auto'
 keyword was repurposed.

Last I checked, C++ had no satisfactory way to express
callbacks/functors/listeners/lambdas. That's why Qt came up with a
metacompiler to supplement C++'s facilities.

No, STL and Boost can't remedy the situation.

The main reason was the unfortunate way method pointers were defined in
C++. C#'s delegates and Java's anonymous inner classes are something a
C++ developer can only dream of (unless something has already been
dreamt up in a recent standard).

Python, of course, has delegates:

   that_object.register_callback(self.handle_it)

Python doesn't have anonymous inner classes, but it has named inner
classes, and that's quite sufficient.


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Functional programming

[Chris Angelico]

On Wed, Mar 5, 2014 at 8:43 AM, Marko Rauhamaa ma...@pacujo.net wrote:
 Chris Angelico ros...@gmail.com:

 C++ at least has typedefs, and in the newer standards, the 'auto'
 keyword was repurposed.

 Last I checked, C++ had no satisfactory way to express
 callbacks/functors/listeners/lambdas. That's why Qt came up with a
 metacompiler to supplement C++'s facilities.

I think one of the recent standards added some kind of closure for
callbacks. I tried to grok it and couldn't figure out what it was
doing, so I gave it up as a bad job. It got hairy. Really hairy.
Either that, or I was reading a poorly-written article, which is also
possible.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Functional programming

[Gregory Ewing]

Marko Rauhamaa wrote:

Python doesn't have anonymous inner classes, but it has named inner
classes, and that's quite sufficient.


I would say it's Python's closures that make up for
not having Java's inner classes.

Or to put it another way, inner classes are Java's
kludgy way of working around a lack of closures.

--
Greg
--
https://mail.python.org/mailman/listinfo/python-list

Re: Functional programming

[Marko Rauhamaa]

Gregory Ewing greg.ew...@canterbury.ac.nz:

 Marko Rauhamaa wrote:
 Python doesn't have anonymous inner classes, but it has named inner
 classes, and that's quite sufficient.

 I would say it's Python's closures that make up for not having Java's
 inner classes.

 Or to put it another way, inner classes are Java's kludgy way of
 working around a lack of closures.

I actually quite like Java's inner classes. In fact, I think introducing
lambdas into Java was a grave mistake; the silly competitive pressure
from C# made them accept a very ugly and disheveled syntax.

Inner classes *are* closures. They are more general than (Lisp-style)
lambda's because they accept more than one method.

Python, of course, has all of the above.


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Functional programming

[Alister]

On Mon, 03 Mar 2014 06:14:09 +0700, musicdenotation wrote:

 If Python is not a fnctional language, then which programming paradigmis
 dominant?

Python follows the Pythonic paradigm :-)



-- 
Hope this helps some, sorry for not being able to do a brain dump.

- Mike Stump helping a clueless user on the gcc mailing list
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Functional programming

[Bob Martin]

in 718085 20140302 231409 musicdenotat...@gmail.com wrote:
If Python is not a fnctional language, then which programming paradigmis dom=
inant?=

Labels are always misleading.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Functional programming

[Rustom Mody]

On Monday, March 3, 2014 6:57:15 AM UTC+5:30, Ned Batchelder wrote:
 On 3/2/14 6:14 PM, musicdenotation wrote:
  If Python is not a fnctional language, then which programming paradigmis 
  dominant?

 is_a_functional_language() is not a binary condition, yes or no.  It's a 
 continuum.  Python has more functional constructs than Pascal, and fewer 
 than Haskell.

I find this the most agreeable answer. I would add:

There are really two continuaa:
the 'CAN' and the 'CANNOT' (sounds 180 deg apart but they are actually
rather independent)

As Ned says on the CAN spectrum python sits between standard
imperative languages like C,Pascal and Haskell, in fact coming quite close
to Haskell.

However it is also useful to consider the CANNOT spectrum for
beginners/pedagogical purposes.

If you start a beginner on a language like Haskell which CANNOT:
- express iteration except with recursion
- cannot have assignments (and therefore anything remotely like a normal
program variable; variables are only ever math variables)
- cannot do a 'type-incorrect' expression like
 [1,2] + [[3,4],[5]]
[1, 2, [3, 4], [5]]

the beginner will develop a significantly different mind-set than
starting from a python-like language

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Functional programming

[Chris Angelico]

On Mon, Mar 3, 2014 at 10:45 PM, Rustom Mody rustompm...@gmail.com wrote:
 - cannot do a 'type-incorrect' expression like
 [1,2] + [[3,4],[5]]
 [1, 2, [3, 4], [5]]

What do you mean by type-incorrect? This is adding two lists and
getting back a list. Seems perfectly correct to me.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Functional programming

[Rustom Mody]

On Monday, March 3, 2014 5:50:37 PM UTC+5:30, Chris Angelico wrote:
 On Mon, Mar 3, 2014 at 10:45 PM, Rustom Mody  wrote:
  - cannot do a 'type-incorrect' expression like
  [1,2] + [[3,4],[5]]
  [1, 2, [3, 4], [5]]

 What do you mean by type-incorrect? This is adding two lists and
 getting back a list. Seems perfectly correct to me.


Here's the behavior from an (old version of) haskell.

Unfortunately modern versions give a less helpful error message
'++' is list-append, '?' is the prompt

? [1,2] + [[3,4],[5]]   
ERROR: Type error in application
*** expression : [1,2] + [[3,4],[5]]
*** term   : [1,2]
*** type   : [Int]
*** does not match : [[Int]]

IOW [1,2,[3,4],[5]]
is a type-wise ill-formed expression just as in python
[[1,2])
is syntax-wise ill-formed

Is it worth having such a restriction?
Thats a different argument...
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Functional programming

[Rustom Mody]

On Monday, March 3, 2014 7:18:00 PM UTC+5:30, Rustom Mody wrote:

 Unfortunately modern versions give a less helpful error message
 '++' is list-append, '?' is the prompt

 ? [1,2] + [[3,4],[5]]   

Whoops Wrong cut-paste!

? [1,2] ++ [[3,4],[5]]
ERROR: Type error in application
*** expression : [1,2] ++ [[3,4],[5]]
*** term   : [1,2]
*** type   : [Int]
*** does not match : [[Int]]

? 

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Functional programming

[Chris Angelico]

On Tue, Mar 4, 2014 at 12:48 AM, Rustom Mody rustompm...@gmail.com wrote:
 ? [1,2] + [[3,4],[5]]
 ERROR: Type error in application
 *** expression : [1,2] + [[3,4],[5]]
 *** term   : [1,2]
 *** type   : [Int]
 *** does not match : [[Int]]

 IOW [1,2,[3,4],[5]]
 is a type-wise ill-formed expression just as in python
 [[1,2])
 is syntax-wise ill-formed

 Is it worth having such a restriction?
 Thats a different argument...

How do you know that [1,2] is a list that must contain nothing but
integers? By extension, it's also a list that must contain positive
integers less than three, so adding [5] violates that. And [] is a
list that must contain nothing, ergo it can't be added to, although
(since it contains nothing) it can be added to anything.

Some languages do let you specify element types (Pike has an array
type that can hold anything, or you can say array(int) to restrict
it to integers; you could also say array(int(1..2)) to specify what
I said above, if you actually intend that), but without a declaration
from the programmer, it's dangerous to assume there's an error.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Functional programming

[Rustom Mody]

On Monday, March 3, 2014 7:30:17 PM UTC+5:30, Chris Angelico wrote:
 On Tue, Mar 4, 2014 at 12:48 AM, Rustom Mody wrote:
  ? [1,2] + [[3,4],[5]]
  ERROR: Type error in application
  *** expression : [1,2] + [[3,4],[5]]
  *** term   : [1,2]
  *** type   : [Int]
  *** does not match : [[Int]]
  IOW [1,2,[3,4],[5]]
  is a type-wise ill-formed expression just as in python
  [[1,2])
  is syntax-wise ill-formed
  Is it worth having such a restriction?
  Thats a different argument...

 How do you know that [1,2] is a list that must contain nothing but
 integers? By extension, it's also a list that must contain positive
 integers less than three, so adding [5] violates that. And [] is a
 list that must contain nothing, ergo it can't be added to, although
 (since it contains nothing) it can be added to anything.

If 'integer-less-than-3' were a type then yes there would be this
problem. More generally, if types could overlap then automatic
type-inference is impossible

Whether all thats good is as I earlier said a different argument

The OP asked about FP and so its appropriate to mention how python's
and standard FPL's choices differ
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Functional programming

[Chris Angelico]

On Tue, Mar 4, 2014 at 1:08 AM, Rustom Mody rustompm...@gmail.com wrote:
 How do you know that [1,2] is a list that must contain nothing but
 integers? By extension, it's also a list that must contain positive
 integers less than three, so adding [5] violates that. And [] is a
 list that must contain nothing, ergo it can't be added to, although
 (since it contains nothing) it can be added to anything.

 If 'integer-less-than-3' were a type then yes there would be this
 problem. More generally, if types could overlap then automatic
 type-inference is impossible


First, does Haskell allow this?

? [1,2,'foo'] ++ [3,4,'bar']

If not, then find some other form of the expression that has the same
point, and substitute in for the below. And then: which of these is
permitted?

? [1,2] ++ [3,4,'bar']
? [1,2,'foo'] ++ [3,4]
? [] ++ [3,4,'bar']
? [1,2,'foo'] ++ []
? ([1,2,'foo'] ++ []) ++ [3,4,'bar']
? [1,2,'foo'] ++ ([] ++ [3,4,'bar'])

If it's okay to have heterogeneous lists, how do you tell it that your
[1,2] is actually going to get strings in it later, and that it's okay
to combine it with one that has strings?

With Pike, that's all based on the variable type. (There is type
inference; the type of an array containing just 3 and 4 is
array(int(3..4)), but it's acceptable to add that to an array
containing the string asdf, which itself has type
array(string(97..115)) - the combination would be array(int(3..4) |
string(97..115)), which gets a bit wordy.) I can't assign an
array(string) to a variable that's been declared as taking array(int).
But I can assign an array(int) to a variable declared as accepting
array(int|string), and then I can append a string to it, because
that's legal based on the destination.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Functional programming

[Rustom Mody]

On Monday, March 3, 2014 7:53:01 PM UTC+5:30, Chris Angelico wrote:
 On Tue, Mar 4, 2014 at 1:08 AM, Rustom Mody wrote:
  How do you know that [1,2] is a list that must contain nothing but
  integers? By extension, it's also a list that must contain positive
  integers less than three, so adding [5] violates that. And [] is a
  list that must contain nothing, ergo it can't be added to, although
  (since it contains nothing) it can be added to anything.
  If 'integer-less-than-3' were a type then yes there would be this
  problem. More generally, if types could overlap then automatic
  type-inference is impossible

 First, does Haskell allow this?

 ? [1,2,'foo'] ++ [3,4,'bar']

 If not, then find some other form of the expression that has the same
 point, and substitute in for the below. And then: which of these is
 permitted?


Dunno what you mean/whats the 'point'


 ? [1,2] ++ [3,4,'bar']
 ? [1,2,'foo'] ++ [3,4]
 ? [] ++ [3,4,'bar']
 ? [1,2,'foo'] ++ []
 ? ([1,2,'foo'] ++ []) ++ [3,4,'bar']
 ? [1,2,'foo'] ++ ([] ++ [3,4,'bar'])

 If it's okay to have heterogeneous lists, 

Its not.  None of the above work

If you want the (semantic) equivalent of python's [1,2,'foo']
you need to make an explicit union Int and String and its that
*single* union type's elements that must go in.

In all cases its always a single type. And so
sum([1,2,[3])
is a syntax error unlike python where its a runtime error


-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Functional programming

[Chris Angelico]

On Tue, Mar 4, 2014 at 1:38 AM, Rustom Mody rustompm...@gmail.com wrote:
 If you want the (semantic) equivalent of python's [1,2,'foo']
 you need to make an explicit union Int and String and its that
 *single* union type's elements that must go in.

 In all cases its always a single type. And so
 sum([1,2,[3])

Okay. That's how the declaration goes, then. So how do you tell it
that 1 isn't an Int, it's a member of the union of Int and String? How
do you create a list which has [Int_String(1), Int_String(2)] and is
therefore allowed to be added to [Int_String('foo')] ? Can you do that
with literals?

This is why it's tricky to put rules in based on type inference. The
programmer's intent isn't in the picture. 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 how it is with Pike
(if you just say array, it can take anything), and that's the only
way to be sure the programmer doesn't have to fight the language.

You said earlier

 On Tue, Mar 4, 2014 at 1:08 AM, Rustom Mody wrote:
  If 'integer-less-than-3' were a type then yes there would be this
  problem. More generally, if types could overlap then automatic
  type-inference is impossible

The type Int overlaps with the type Union of Int and String. How
is that resolved? Type inference ignores unions? That's the only way I
can think of. Hence the original difficulty of type-inferring on a
list that isn't complete yet.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Functional programming

[Rustom Mody]

On Monday, March 3, 2014 8:31:47 PM UTC+5:30, Chris Angelico wrote:
 On Tue, Mar 4, 2014 at 1:38 AM, Rustom Mody  wrote:
  If you want the (semantic) equivalent of python's [1,2,'foo']
  you need to make an explicit union Int and String and its that
  *single* union type's elements that must go in.
  In all cases its always a single type. And so
  sum([1,2,[3])

 Okay. That's how the declaration goes, then. So how do you tell it
 that 1 isn't an Int, it's a member of the union of Int and String? How
 do you create a list which has [Int_String(1), Int_String(2)] and is
 therefore allowed to be added to [Int_String('foo')] ? Can you do that
 with literals?

Mmmm This is getting a bit OT for a python list
Anyway here goes
The Union type is called Either.
Its got two constructors -- Left and Right -- better to think of them as
tags to not confuse with OO constructors.
The names Left and Right seem to be a bit meaningless because the Either
type is completely generic -- any types S and T can be 'unioned' as
Either S T
where the S components look like Left x for x : S
and the T components look like Right x for x : T

So python's [1,2,foo] is
written as
[Left 1, Left 2, Right foo]

 This is why it's tricky to put rules in based on type inference. The
 programmer's intent isn't in the picture. 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 how it is with Pike
 (if you just say array, it can take anything), and that's the only
 way to be sure the programmer doesn't have to fight the language.

 You said earlier

  On Tue, Mar 4, 2014 at 1:08 AM, Rustom Mody wrote:
   If 'integer-less-than-3' were a type then yes there would be this
   problem. More generally, if types could overlap then automatic
   type-inference is impossible

 The type Int overlaps with the type Union of Int and String. How
 is that resolved? 

By decreeing no overlap! :-)

Left 1 : Either Int String
whereas 1 : Int

Strictly speaking 'union' should be called 'disjoint union' but this is
so universal in programming that its dropped as redundant.

Heck even C's union is disjoint! If we have

union u
{ 
  int i;
  char c;
};

union u x;

Now you cant interchange the usages of x x.i and x.c

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Functional programming

[Steven D'Aprano]

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.

It works really well in practice, because most of the time you don't need 
a lot of type dynamism. Or even any.

Think about the sort of type declarations you have to do in (say) Pascal, 
and consider how stupid the compiler must be:

function add_one(x: integer):integer;
  begin
add_one := x+1;
  end;

Given that x is an integer, and that you add 1 (also an integer) to it, 
is it really necessary to tell the compiler that add_one returns an 
integer? What else could the output type be?

This was state of the art back in 1970, but these days, if the compiler 
cannot *at least* infer the type of the return result of a function given 
the argument types, the static type system is too dumb to bother with. A 
good static type system can even detect infinite loops at compile time:

http://perl.plover.com/yak/typing/notes.html

This is not cutting edge technology: ML dates back to the 1990s, if not 
older.


 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.


 That's how it is with Pike
 (if you just say array, it can take anything), and that's the only way
 to be sure the programmer doesn't have to fight the language.

To be sure, any form of static typing is going to restrict what you can 
do. This isn't intended to imply that static typing is better than 
dynamic typing. But if you have static typing, there's *no point* to it 
if the type system cannot detect bugs, and having to declare types is 
like having to calculate your own GOTO addresses. With a good type system 
like ML or Haskell have, you're not fighting the compiler, *every* type 
error you get is a real, actual bug in your code.



-- 
Steven D'Aprano
http://import-that.dreamwidth.org/
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Functional programming

[Chris Angelico]

On Tue, Mar 4, 2014 at 4:27 AM, Steven D'Aprano
steve+comp.lang.pyt...@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
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Functional programming

[Gregory Ewing]

Steven D'Aprano wrote:
Given that x is an integer, and that you add 1 (also an integer) to it, 
is it really necessary to tell the compiler that add_one returns an 
integer? What else could the output type be?


Just because the compiler *can* infer the return type
doesn't necessarily mean it *should*. When I was playing
around with functional languages, I ended up adopting the
practice of always declaring the types of my functions,
because it helps the *human* reader. (It also helped the
compiler produce comprehensible error messages in the
event of a type error.)

--
Greg
--
https://mail.python.org/mailman/listinfo/python-list

Re: Functional programming

[Chris Angelico]

On Tue, Mar 4, 2014 at 9:31 AM, Ben Finney ben+pyt...@benfinney.id.au wrote:
 def frobnicate(flang, splets, queeble=False):
  Righteously frobnicate the flang.

 :param flang: A file-like object, opened for reading.

I had to read that a few times before I was sure that you actually
meant file there, you used a real word with its real meaning!

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Functional programming

[Ben Finney]

Gregory Ewing greg.ew...@canterbury.ac.nz writes:

 Just because the compiler *can* infer the return type doesn't
 necessarily mean it *should*. When I was playing around with
 functional languages, I ended up adopting the practice of always
 declaring the types of my functions, because it helps the *human*
 reader.

Sure. In a duck-typed language like Python, it is still helpful to the
human reader to document the *meaning* of each parameter, beyond what is
indicated by the name. We have reStructuredText and docstrings for this
purpose.

def frobnicate(flang, splets, queeble=False):
 Righteously frobnicate the flang.

:param flang: A file-like object, opened for reading.
:param splets: A sequence of unprocessed Splet instances.
:param queeble: If ``True``, re-vitrify the flang during
frobnication.
:return: A new list of processed Splet instances.

The flang is frobnicated according to the Weebly-Ruckford
algorithm.


for line in flang:
…

 (It also helped the compiler produce comprehensible error messages in
 the event of a type error.)

Docstrings in the above reStructuredText field-list style will be
processed by Epydoc URL:http://epydoc.sourceforge.net/fields.html.

Other styles of specifying parameters in an mechanically-extractable
form are also used, by Sphinx for example. The point is, we have
docstrings, and conventions in docstrings for specifying parameters for
the human reader *and* for automated tools to read.

-- 
 \“… Nature … is seen to do all things Herself and through |
  `\ herself of own accord, rid of all gods.” —Titus Lucretius |
_o__) Carus, c. 40 BCE |
Ben Finney

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Functional programming

[Ben Finney]

Chris Angelico ros...@gmail.com writes:

 On Tue, Mar 4, 2014 at 9:31 AM, Ben Finney ben+pyt...@benfinney.id.au wrote:
  def frobnicate(flang, splets, queeble=False):
   Righteously frobnicate the flang.
 
  :param flang: A file-like object, opened for reading.

 I had to read that a few times before I was sure that you actually
 meant file there, you used a real word with its real meaning!

Sometimes I say what I mean, to test whether people are alert.

-- 
 \   “Faith, n. Belief without evidence in what is told by one who |
  `\   speaks without knowledge, of things without parallel.” —Ambrose |
_o__)   Bierce, _The Devil's Dictionary_, 1906 |
Ben Finney

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Functional programming

[88888 Dihedral]

On Monday, March 3, 2014 10:08:11 PM UTC+8, Rustom Mody wrote:
 On Monday, March 3, 2014 7:30:17 PM UTC+5:30, Chris Angelico wrote:
 
  On Tue, Mar 4, 2014 at 12:48 AM, Rustom Mody wrote:
 
   ? [1,2] + [[3,4],[5]]
 
   ERROR: Type error in application
 
   *** expression : [1,2] + [[3,4],[5]]
 
   *** term   : [1,2]
 
   *** type   : [Int]
 
   *** does not match : [[Int]]
 
   IOW [1,2,[3,4],[5]]
 
   is a type-wise ill-formed expression just as in python
 
   [[1,2])
 
   is syntax-wise ill-formed
 
   Is it worth having such a restriction?
 
   Thats a different argument...
 
 
 
  How do you know that [1,2] is a list that must contain nothing but
 
  integers? By extension, it's also a list that must contain positive
 
  integers less than three, so adding [5] violates that. And [] is a
 
  list that must contain nothing, ergo it can't be added to, although
 
  (since it contains nothing) it can be added to anything.
 
 
 
 If 'integer-less-than-3' were a type then yes there would be this
 
 problem. More generally, if types could overlap then automatic
 
 type-inference is impossible
 
 
 
 Whether all thats good is as I earlier said a different argument
 
 
 
 The OP asked about FP and so its appropriate to mention how python's
 
 and standard FPL's choices differ

OK, lets talk about the real 
meats of high-level dynamical typed
languages.

Test the claim that the old OOP programs and modules can use the new objects 
and programs written or obtained later in the run time.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Functional programming

[Steven D'Aprano]

On Tue, 04 Mar 2014 05:37:27 +1100, Chris Angelico wrote:

 On Tue, Mar 4, 2014 at 4:27 AM, Steven D'Aprano
 steve+comp.lang.pyt...@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.

It won't be a Syntax Error, it will be a compile-time Type Error. And, 
yes, it is fine. That's the point of static typing! The tradeoff of being 
able to detect a whole lot of errors *at compile time* is that you give 
up the ability to re-use the same variable for different types in a 
single scope. (You can have an x which is a string elsewhere, just not in 
this scope where it is an int.)

It's okay if you personally prefer the flexibility and freedom of dynamic 
typing. The cost of this choice is that you become responsible for 
writing unit tests that ensure that code behaves safely when given 
unexpected types. If you choose static typing instead, you get a whole 
lot of error checking done at compile time, and likely a lot of compiler 
optimizations. But the cost is that you can't write:

x = 23
x += 5
x = str(x)

and instead have to write:

x = 23
x += 5
s = str(x)


You should, I think, read this:

http://cdsmith.wordpress.com/2011/01/09/an-old-article-i-wrote/


[...]
 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.

That Haskell has homogeneous lists is not a property of the type system, 
but a design choice. I'm sure Haskell will also have a tuple or record 
type that allows fields of different types.


 Python's handling is: A list can hold anything.
[...]
 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. 

Yes. 


 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.

I have not used Haskell enough to tell you whether you can specify 
subtypes. I know that, at least for numeric (integer) types, venerable 
old Pascal allows you to define subtypes based on integer ranges, so I'd 
be surprised if you couldn't do the same thing in Haskell.

The flexibility of the type system -- its ability to create subtypes and 
union types -- is independent of whether it is explicitly declared or 
uses type inference.


 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.

Hey, I'm a Python programmer! You don't have to sell me on the benefits 
of dynamic typing. Before Python, my language of choice was Apple's 
Hyperscript, which is untyped -- everything, and I mean everything, is a 
string in Hyperscript. It works remarkably well, so long as you don't 
care about speed. But even in the late 80s or early 1990s, on single-core 
CPUs running at a piddly 7.8 MHz (compared to about 1000 MHz for desktops 
today), you could get acceptable performance for a remarkable range of 
applications.

But don't be fooled, those benefits aren't free. Static typing has 
benefits too.


-- 
Steven
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Functional programming

[Rustom Mody]

On Tuesday, March 4, 2014 11:05:24 AM UTC+5:30, Steven D'Aprano wrote:
 On Tue, 04 Mar 2014 05:37:27 +1100, Chris Angelico wrote:

  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.

 I have not used Haskell enough to tell you whether you can specify 
 subtypes. I know that, at least for numeric (integer) types, venerable 
 old Pascal allows you to define subtypes based on integer ranges, so I'd 
 be surprised if you couldn't do the same thing in Haskell.

Its a bit murkier. See
http://lambda-the-ultimate.org/node/4771

Especially see the scala choices comment

Also this comment by Peyton Jones is telling

Damas-Milner* is on a cusp: 
Can infer most-general types without any type annotations at all
But virtually any extension destroys this property

from www.cs.nott.ac.uk/~gmh/appsem-slides/peytonjones.ppt

* The functional programming type inference algorithm
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Functional programming

[Chris Angelico]

On Tue, Mar 4, 2014 at 4:35 PM, Steven D'Aprano st...@pearwood.info wrote:
 On Tue, 04 Mar 2014 05:37:27 +1100, Chris Angelico wrote:
 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.

 It won't be a Syntax Error, it will be a compile-time Type Error. And,
 yes, it is fine. That's the point of static typing! The tradeoff of being
 able to detect a whole lot of errors *at compile time* is that you give
 up the ability to re-use the same variable for different types in a
 single scope. (You can have an x which is a string elsewhere, just not in
 this scope where it is an int.)

Okay, a compile-type type error, same difference. What I'm saying is
that the auto-detection can't know what else you plan to do. If you
explicitly say that this is an int, then yes, that should be
disallowed; if you explicitly say that it's either an int or a float,
then you should be able to have either, but not a string. (C does this
with explicitly tagged unions, usually. Python and Pike do it by
simply allowing multiple types in the same slot.)

 That Haskell has homogeneous lists is not a property of the type system,
 but a design choice. I'm sure Haskell will also have a tuple or record
 type that allows fields of different types.

If it's not the list type, pick some other. It's not uncommon to want
to have a record that has different types (C does this with struct,
C++ has a few more ways to do it); what I'm finding odd is that
whatever goes into it first is specifying for everything else.

 I have not used Haskell enough to tell you whether you can specify
 subtypes. I know that, at least for numeric (integer) types, venerable
 old Pascal allows you to define subtypes based on integer ranges, so I'd
 be surprised if you couldn't do the same thing in Haskell.

 The flexibility of the type system -- its ability to create subtypes and
 union types -- is independent of whether it is explicitly declared or
 uses type inference.

I'm not sure how you could have type inference with subtypes. How does
the compiler figure out what subtype of integers is acceptable, such
that it can reject some?

x = 5
x = 7
x = 11
x = 17
x = 27

Should the last one be rejected because it's not prime? How can it
know that I actually wanted that to be int(3..20)? That's why I see
them as connected. All sorts of flexibilities are possible when the
programmer explicitly tells the compiler what the rules are.

 Hey, I'm a Python programmer! You don't have to sell me on the benefits
 of dynamic typing. Before Python, my language of choice was Apple's
 Hyperscript, which is untyped -- everything, and I mean everything, is a
 string in Hyperscript. It works remarkably well, so long as you don't
 care about speed. But even in the late 80s or early 1990s, on single-core
 CPUs running at a piddly 7.8 MHz (compared to about 1000 MHz for desktops
 today), you could get acceptable performance for a remarkable range of
 applications.

 But don't be fooled, those benefits aren't free. Static typing has
 benefits too.

For me, that untyped language was REXX. One data type (the string),
and a special feature of variable names to handle what most people
would do with arrays/lists/mappings/dicts/etc/etc/etc. (Or, of course,
you do what you'd presumably do in Hyperscript, and implement an array
of words as a string that you separate on ' '. VX-REXX had a neat
'initializer format' where you simply prefix every element with the
separator - that is to say, the first character of the string is the
separator. It nests perfectly and is pretty convenient to type. A
little obscure for most people, though.) Was also my first taste of
arbitrary-precision arithmetic. C could cream it as long as I didn't
need anything over 2**32 or anything I can't do in a double-precision
float, but I could calculate 200! with clean brute-force code and it'd
work perfectly.

Static and dynamic typing both have their uses. But when I use static
typing, I want to specify the types myself. I'm aware that's a matter
of opinion, but I don't like the idea of the compiler rejecting code
based on inferred types.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Functional programming

[Rustom Mody]

On Tuesday, March 4, 2014 11:34:55 AM UTC+5:30, Chris Angelico wrote:
 On Tue, Mar 4, 2014 at 4:35 PM, Steven D'Aprano wrote:
  I have not used Haskell enough to tell you whether you can specify
  subtypes. I know that, at least for numeric (integer) types, venerable
  old Pascal allows you to define subtypes based on integer ranges, so I'd
  be surprised if you couldn't do the same thing in Haskell.
  The flexibility of the type system -- its ability to create subtypes and
  union types -- is independent of whether it is explicitly declared or
  uses type inference.

 I'm not sure how you could have type inference with subtypes.

Short answer: You cant [Yeah Some folks dont like my short answers :-) ]

Long answer: See the links I posted above

Intermediate answer:
Types (for a modern FPL) are like math sets except that:
- set-membership is in general hard and in principle undecidable
- type-membership had better be decidable and preferably linear-time if its 
to be part of an implementation (and not a philosophical discussion over a cuppa
chai)
- Which means that...

 Static and dynamic typing both have their uses. But when I use static
 typing, I want to specify the types myself. I'm aware that's a matter
 of opinion, but I don't like the idea of the compiler rejecting code
 based on inferred types.

...Type inference is strictly (aka mathematically) syntax even though
in the implementation, the parsing phase and the type checking/inferencing phase
are sequenced

In short: An important flavor of the FP koolaid is the Damas-Milner
type-inferencing algorithm. Damas-Milner + Subtyping is the recipe for
a severe headache -- An important reason why FP and OOP are incompatible
-- 
https://mail.python.org/mailman/listinfo/python-list

Functional programming

[musicdenotation]

If Python is not a fnctional language, then which programming paradigmis 
dominant?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Functional programming

[Terry Reedy]

On 3/2/2014 6:14 PM, musicdenotat...@gmail.com wrote:

If Python is not a fnctional language, then which programming paradigmis 
dominant?


Python is an object based procedural language with builtin classes and 
many functional features. Arguing about the precise wording of such a 
statement is not worthwhile.


--
Terry Jan Reedy

--
https://mail.python.org/mailman/listinfo/python-list

Re: Functional programming

[Ben Finney]

musicdenotat...@gmail.com writes:

 If Python is not a fnctional language, then which programming
 paradigmis dominant?

Python uses a mixture of programming paradigms. Object-oriented,
procedural, functional, and probably some I don't recall.

So it's not accurate to say “Python is not a functional language”. You
can do functional programming in Python. But you're not required to :-)

-- 
 \  “It's dangerous to be right when the government is wrong.” |
  `\   —Francois Marie Arouet Voltaire |
_o__)  |
Ben Finney

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Functional programming

[Roy Smith]

In article mailman.7605.1393805404.18130.python-l...@python.org,
 Terry Reedy tjre...@udel.edu wrote:

 On 3/2/2014 6:14 PM, musicdenotat...@gmail.com wrote:
  If Python is not a fnctional language, then which programming paradigmis 
  dominant?
 
 Python is an object based procedural language with builtin classes and 
 many functional features. Arguing about the precise wording of such a 
 statement is not worthwhile.

+1 QOTW.  Especially the second sentence.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Functional programming

[Ned Batchelder]

On 3/2/14 6:14 PM, musicdenotat...@gmail.com wrote:

If Python is not a fnctional language, then which programming paradigmis 
dominant?



is_a_functional_language() is not a binary condition, yes or no.  It's a 
continuum.  Python has more functional constructs than Pascal, and fewer 
than Haskell.


--
Ned Batchelder, http://nedbatchelder.com

--
https://mail.python.org/mailman/listinfo/python-list

Re: Functional programming

[Steven D'Aprano]

On Mon, 03 Mar 2014 06:14:09 +0700, musicdenotation wrote:

 If Python is not a fnctional language, then which programming paradigmis
 dominant?

Object oriented and procedural are about equally dominant, with a strong 
influence from functional paradigm.

There are small amounts of imperative paradigm (e.g. the import and del 
statements), and you can use iterators and generators to program using a 
pipelining paradigm.



-- 
Steven D'Aprano
http://import-that.dreamwidth.org/
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Can one use Python to learn and even apply Functional Programming?

[Neil Cerutti]

On 2014-02-16, Sam lightai...@gmail.com wrote:
 I would like to learn and try out functional programming (FP).
 I love Python and would like to use it to try FP. Some have
 advised me to use Haskell instead because Python is not a good
 language for FP. I am sort of confused at the moment. Is Python
 a dysfunctional programming language to apply FP? Can the more
 experienced Python users advise?

I recommend Scheme to learn functional programming style.

There's a short scheme tutorial that was entered in the
Interactive Fiction competition in 1998 or so. You can play it
online here, and try out functional programming on a scheme
interepreter implemented in Inform and running on a Z-machine
interpreter written in javascript. It was *my* first introduction
to functional programming.

http://www.eblong.com/zarf/if.html#lists

I purchased and really enjoyed Simply Scheme as a followup to
that mind-bending experience.

http://www.eecs.berkeley.edu/~bh/ss-toc2.html

I wouldn't recommend trying to learn anything at the same time as
learning Haskell. ;)

-- 
Neil Cerutti

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Can one use Python to learn and even apply Functional Programming?

[Pat Johnson]

This made me grin. ;)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Can one use Python to learn and even apply Functional Programming?

[Terry Reedy]

On 2/16/2014 1:38 AM, Devin Jeanpierre wrote:

On Sat, Feb 15, 2014 at 8:45 PM, Sam lightai...@gmail.com wrote:

I would like to learn and try out functional programming (FP). I love Python 
and would like to use it to try FP. Some have advised me to use Haskell instead 
because Python is not a good language for FP. I am sort of confused at the 
moment. Is Python a dysfunctional programming language to apply FP? Can the 
more experienced Python users advise?


Everything about FP that can be done in, say, Scheme, can be done in
Python, with the exception of tail recursion (but that isn't important


You can do tail recursion in Python, but it will not be noticed and 
optimized in the way it is is some functional languages.



for real FP). But Scheme is old, and people keep thinking of new
things and more interesting variations on the lambda calculus.

Haskell is kind of the core of modern functional programming, and
involves heavy use of concepts that do not exist or are visibly alien
in Python. If you want to learn FP properly, you should learn Haskell.
Otherwise you will likely be confused when you overhear functional
programmers talking, whether it's about Hindley-Milner or sum types or
eta conversion.


In some ways, Haskell is more different from Python than Scheme is, so 
it may stretch your brain more.


--
Terry Jan Reedy

--
https://mail.python.org/mailman/listinfo/python-list