Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #67493 > unrolled thread

Re: Functional programming

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Functional programming Ned Batchelder <ned@nedbatchelder.com> - 2014-03-02 20:27 -0500
    Re: Functional programming Rustom Mody <rustompmody@gmail.com> - 2014-03-03 03:45 -0800
      Re: Functional programming Chris Angelico <rosuav@gmail.com> - 2014-03-03 23:20 +1100
        Re: Functional programming Rustom Mody <rustompmody@gmail.com> - 2014-03-03 05:48 -0800
          Re: Functional programming Rustom Mody <rustompmody@gmail.com> - 2014-03-03 05:51 -0800
          Re: Functional programming Chris Angelico <rosuav@gmail.com> - 2014-03-04 01:00 +1100
            Re: Functional programming Rustom Mody <rustompmody@gmail.com> - 2014-03-03 06:08 -0800
              Re: Functional programming Chris Angelico <rosuav@gmail.com> - 2014-03-04 01:23 +1100
                Re: Functional programming Rustom Mody <rustompmody@gmail.com> - 2014-03-03 06:38 -0800
                  Re: Functional programming Chris Angelico <rosuav@gmail.com> - 2014-03-04 02:01 +1100
                    Re: Functional programming Rustom Mody <rustompmody@gmail.com> - 2014-03-03 07:28 -0800
                    Re: Functional programming Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-03 17:27 +0000
                      Re: Functional programming Chris Angelico <rosuav@gmail.com> - 2014-03-04 05:37 +1100
                        Re: Functional programming Steven D'Aprano <steve@pearwood.info> - 2014-03-04 05:35 +0000
                          Re: Functional programming Rustom Mody <rustompmody@gmail.com> - 2014-03-03 21:59 -0800
                          Re: Functional programming Chris Angelico <rosuav@gmail.com> - 2014-03-04 17:04 +1100
                            Re: Functional programming Rustom Mody <rustompmody@gmail.com> - 2014-03-03 22:20 -0800
                            Re: Functional programming Steven D'Aprano <steve@pearwood.info> - 2014-03-04 08:56 +0000
                              Re: Functional programming Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2014-03-04 11:56 +0100
                                Re: Functional programming Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-04 11:47 +0000
                                  Re: Functional programming Chris Angelico <rosuav@gmail.com> - 2014-03-05 00:01 +1100
                                    OT Sine Rule [was Re: Functional programming] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-04 14:25 +0000
                                      Re: OT Sine Rule [was Re: Functional programming] Tim Chase <python.list@tim.thechases.com> - 2014-03-04 08:37 -0600
                                      Re: OT Sine Rule [was Re: Functional programming] Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-03-04 14:42 +0000
                                      Re: OT Sine Rule [was Re: Functional programming] Chris Angelico <rosuav@gmail.com> - 2014-03-05 02:06 +1100
                                      Re: OT Sine Rule [was Re: Functional programming] Tim Chase <python.list@tim.thechases.com> - 2014-03-04 09:21 -0600
                                  Re: Functional programming Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2014-03-05 09:59 +0100
                                Re: Functional programming Marko Rauhamaa <marko@pacujo.net> - 2014-03-04 21:49 +0200
                                  Re: Functional programming Chris Angelico <rosuav@gmail.com> - 2014-03-05 07:01 +1100
                                    Re: Functional programming Marko Rauhamaa <marko@pacujo.net> - 2014-03-04 22:50 +0200
                                      Re: Functional programming Chris Angelico <rosuav@gmail.com> - 2014-03-05 08:06 +1100
                                        Re: Functional programming Marko Rauhamaa <marko@pacujo.net> - 2014-03-04 23:21 +0200
                                          Re: Functional programming Chris Angelico <rosuav@gmail.com> - 2014-03-05 08:26 +1100
                                            Re: Functional programming Marko Rauhamaa <marko@pacujo.net> - 2014-03-04 23:43 +0200
                                              Re: Functional programming Chris Angelico <rosuav@gmail.com> - 2014-03-05 08:52 +1100
                                              Re: Functional programming Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-03-05 12:57 +1300
                                                Re: Functional programming Marko Rauhamaa <marko@pacujo.net> - 2014-03-05 02:11 +0200
                              Re: Functional programming "BartC" <bc@freeuk.com> - 2014-03-04 13:30 +0000
                                Re: Functional programming Chris Angelico <rosuav@gmail.com> - 2014-03-05 00:47 +1100
                                Re: Functional programming Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-03-04 14:05 +0000
                                  Re: Functional programming Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-04 14:55 +0000
                                    Re: Functional programming Chris Angelico <rosuav@gmail.com> - 2014-03-05 02:13 +1100
                                    Re: Functional programming MRAB <python@mrabarnett.plus.com> - 2014-03-04 17:07 +0000
                                Re: Functional programming Chris Angelico <rosuav@gmail.com> - 2014-03-05 01:17 +1100
                                Re: Functional programming Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-04 15:18 +0000
                                  Re: Functional programming Chris Angelico <rosuav@gmail.com> - 2014-03-05 02:28 +1100
                                    Re: Functional programming Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-04 15:45 +0000
                                      Re: Functional programming Chris Angelico <rosuav@gmail.com> - 2014-03-05 03:04 +1100
                                  Re: Functional programming Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2014-03-05 10:09 +0100
                                  Re: Functional programming "BartC" <bc@freeuk.com> - 2014-03-05 11:28 +0000
                                    Re: Functional programming Chris Angelico <rosuav@gmail.com> - 2014-03-05 23:04 +1100
                                      Re: Functional programming Marko Rauhamaa <marko@pacujo.net> - 2014-03-05 14:11 +0200
                      Re: Functional programming Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-03-04 11:06 +1300
                        Re: Functional programming Ben Finney <ben+python@benfinney.id.au> - 2014-03-04 09:31 +1100
                          Re: Functional programming Grant Edwards <invalid@invalid.invalid> - 2014-03-04 14:59 +0000
                            Re: Functional programming Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-04 15:22 +0000
                        Re: Functional programming Chris Angelico <rosuav@gmail.com> - 2014-03-04 09:42 +1100
                        Re: Functional programming Ben Finney <ben+python@benfinney.id.au> - 2014-03-04 10:52 +1100
                      Re: Functional programming "BartC" <bc@freeuk.com> - 2014-03-04 09:41 +0000
              Re: Functional programming 88888 Dihedral <dihedral88888@gmail.com> - 2014-03-03 16:35 -0800

Page 3 of 3 — ← Prev page 1 2 [3]

#67683

On Tue, 04 Mar 2014 14:05:44 +0000, 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/

[toc] | [prev] | [next] | [standalone]

#67686

On Wed, Mar 5, 2014 at 1:55 AM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> On Tue, 04 Mar 2014 14:05:44 +0000, 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

[toc] | [prev] | [next] | [standalone]

#67705

On 2014-03-04 15:13, Chris Angelico wrote:
> On Wed, Mar 5, 2014 at 1:55 AM, Steven D'Aprano
> <steve+comp.lang.python@pearwood.info> wrote:
>> On Tue, 04 Mar 2014 14:05:44 +0000, 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?

[toc] | [prev] | [next] | [standalone]

#67678

On Wed, Mar 5, 2014 at 1:05 AM, Mark Lawrence <breamoreboy@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

[toc] | [prev] | [next] | [standalone]

#67687

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

> "Steven D'Aprano" <steve@pearwood.info> wrote in message
> news:53159540$0$2923$c3e8da3$76491128@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/

[toc] | [prev] | [next] | [standalone]

#67693

On Wed, Mar 5, 2014 at 2:18 AM, Steven D'Aprano
<steve+comp.lang.python@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

[toc] | [prev] | [next] | [standalone]

#67696

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.python@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/

[toc] | [prev] | [next] | [standalone]

#67698

On Wed, Mar 5, 2014 at 2:45 AM, Steven D'Aprano
<steve+comp.lang.python@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

[toc] | [prev] | [next] | [standalone]

#67829

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

[toc] | [prev] | [next] | [standalone]

#67832

"Steven D'Aprano" <steve+comp.lang.python@pearwood.info> wrote in message
news:5315eec0$0$29985$c3e8da3$5496439d@news.astraweb.com...
> On Tue, 04 Mar 2014 13:30:04 +0000, 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
 

[toc] | [prev] | [next] | [standalone]

#67835

On Wed, Mar 5, 2014 at 10:28 PM, BartC <bc@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

[toc] | [prev] | [next] | [standalone]

#67836

Chris Angelico <rosuav@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:

   List<Integer> li = new LinkedList<Integer>();

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

   Iterable<Integer> li = new LinkedList<Integer>();

or maybe:

   Collection<Integer> li = new LinkedList<Integer>();

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

[toc] | [prev] | [next] | [standalone]

#67594

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

[toc] | [prev] | [next] | [standalone]

#67605

Gregory Ewing <greg.ewing@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

[toc] | [prev] | [next] | [standalone]

#67684

On 2014-03-03, Ben Finney <ben+python@benfinney.id.au> wrote:
> Gregory Ewing <greg.ewing@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.edwards        Yow! I'm young ... I'm
                                  at               HEALTHY ... I can HIKE
                              gmail.com            THRU CAPT GROGAN'S LUMBAR
                                                   REGIONS!

[toc] | [prev] | [next] | [standalone]

#67690

On Tue, 04 Mar 2014 14:59:51 +0000, 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/

[toc] | [prev] | [next] | [standalone]

#67608

On Tue, Mar 4, 2014 at 9:31 AM, Ben Finney <ben+python@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

[toc] | [prev] | [next] | [standalone]

#67618

Chris Angelico <rosuav@gmail.com> writes:

> On Tue, Mar 4, 2014 at 9:31 AM, Ben Finney <ben+python@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

[toc] | [prev] | [next] | [standalone]

#67654

"Steven D'Aprano" <steve+comp.lang.python@pearwood.info> wrote in message
news:5314bb96$0$29985$c3e8da3$5496439d@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 

[toc] | [prev] | [next] | [standalone]

#67619

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.

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

Back to top | Article view | comp.lang.python

csiph-web