Chris Angelico :
> 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
On Wed, Mar 5, 2014 at 10:28 PM, BartC 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
"Steven D'Aprano" 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
str
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!
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
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
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
On Wed, Mar 5, 2014 at 8:43 AM, Marko Rauhamaa wrote:
> Chris Angelico :
>
>> 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
Chris Angelico :
> 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
On Wed, Mar 5, 2014 at 8:21 AM, Marko Rauhamaa wrote:
> Chris Angelico :
>
>> 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
Chris Angelico :
> 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
di
On Wed, Mar 5, 2014 at 7:50 AM, Marko Rauhamaa 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 limitatio
Chris Angelico :
> On Wed, Mar 5, 2014 at 6:49 AM, Marko Rauhamaa wrote:
>> public ConnectionPool(int maxConnections, String url) throws SQLException {
>> try {
>> super(() -> {
>> try {
>> return DriverManager.getConnection(url);
>> } catch ( S
On Wed, Mar 5, 2014 at 6:49 AM, Marko Rauhamaa wrote:
> public ConnectionPool(int maxConnections, String url) throws SQLException {
> try {
> super(() -> {
> try {
> return DriverManager.getConnection(url);
> } catch ( SQLException ex ) {
>
Antoon Pardon :
> 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 signi
On 2014-03-04 15:13, Chris Angelico wrote:
On Wed, Mar 5, 2014 at 1:55 AM, Steven D'Aprano
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 c
On Wed, Mar 5, 2014 at 2:45 AM, Steven D'Aprano
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
On Wed, 05 Mar 2014 02:28:17 +1100, Chris Angelico wrote:
> On Wed, Mar 5, 2014 at 2:18 AM, Steven D'Aprano
> 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 variabl
On Wed, Mar 5, 2014 at 2:18 AM, Steven D'Aprano
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
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,
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
On Tue, 04 Mar 2014 13:30:04 +, BartC wrote:
> "Steven D'Aprano" 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 languag
On Wed, Mar 5, 2014 at 1:55 AM, Steven D'Aprano
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
On Wed, Mar 5, 2014 at 1:25 AM, Steven D'Aprano
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.
On 2014-03-03, Ben Finney wrote:
> Gregory Ewing 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, b
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.dreamwi
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?
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
On Wed, 05 Mar 2014 00:01:01 +1100, Chris Angelico wrote:
> On Tue, Mar 4, 2014 at 10:47 PM, Steven D'Aprano
> 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 ang
On Wed, Mar 5, 2014 at 1:05 AM, Mark Lawrence 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).
>
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 o
On Wed, Mar 5, 2014 at 12:30 AM, 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).
The two are separate. I don't know of any language t
"Steven D'Aprano" 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 th
On Tue, Mar 4, 2014 at 10:47 PM, Steven D'Aprano
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
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 tedi
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
"Steven D'Aprano" 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 th
On Tue, 04 Mar 2014 17:04:55 +1100, Chris Angelico wrote:
> On Tue, Mar 4, 2014 at 4:35 PM, Steven D'Aprano
> 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) # Compile
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
On Tue, Mar 4, 2014 at 4:35 PM, Steven D'Aprano 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 c
nt 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
On Tue, 04 Mar 2014 05:37:27 +1100, Chris Angelico wrote:
> On Tue, Mar 4, 2014 at 4:27 AM, Steven D'Aprano
> 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 pictur
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
Chris Angelico writes:
> On Tue, Mar 4, 2014 at 9:31 AM, Ben Finney 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
On Tue, Mar 4, 2014 at 9:31 AM, Ben Finney 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 "fil
Gregory Ewing 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.
Su
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 *sho
On Tue, Mar 4, 2014 at 4:27 AM, Steven D'Aprano
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
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 reaso
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
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])
O
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
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, e
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]
> > ***
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 exp
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
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
> ge
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.
ChrisA
--
https://mail.pytho
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. Pyth
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
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 clue
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 pa
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 Haske
In article ,
Terry Reedy 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 abo
“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 Ma
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 n
If Python is not a fnctional language, then which programming paradigmis
dominant?
--
https://mail.python.org/mailman/listinfo/python-list
On 2014-02-16, Sam 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. I
Python*can* do functional programming, but, for learning, Haskell will work
better.
Sam 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
On Sunday, February 16, 2014 10:15:58 AM UTC+5:30, Sam 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
On Mon, Feb 17, 2014 at 12:20 AM, Mark Lawrence wrote:
> On 16/02/2014 08:00, Pat Johnson wrote:
>>
>> This made me grin. ;)
>>
>
> What did, using google groups? :)
"Well! I've often seen context without a grin," thought Alice; "but a grin
without context! It's the most curious thing I ever saw
On 16/02/2014 08:00, Pat Johnson wrote:
This made me grin. ;)
What did, using google groups? :)
--
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
On 2/16/2014 1:38 AM, Devin Jeanpierre wrote:
On Sat, Feb 15, 2014 at 8:45 PM, Sam 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
This made me grin. ;)
--
https://mail.python.org/mailman/listinfo/python-list
On Sun, Feb 16, 2014 at 5:38 PM, Devin Jeanpierre
wrote:
> Otherwise you will likely be confused when you overhear functional
> programmers talking, whether it's about Hindley-Milner or sum types or
> eta conversion.
ETA conversion? I know what that is. That's when a programmer says
something'll
On Sat, Feb 15, 2014 at 8:45 PM, Sam 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 th
Sam writes:
> Some have advised me to use Haskell instead because Python is not a
> good language for FP.
There are some features of functional programming which are not a good
fit with Python. By attempting to learn functional programming in
Python, you will necessarily compromise your
On Sun, Feb 16, 2014 at 3:45 PM, Sam 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 th
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
Antoon Pardon writes:
> Op 30-09-13 20:55, Piet van Oostrum schreef:
>> Franck Ditter writes:
>>
>>> Good approach of FP in Python, but two points make me crazy :
>>> 1. Tail recursion is not optimized. We are in 2013, why ? This is known
>>> technology (since 1960).
>>> And don't answer with "
On 2013-10-01, Steven D'Aprano wrote:
> On Mon, 30 Sep 2013 18:36:28 +, Neil Cerutti quoted:
>
>> Why can??t lambda forms contain statements?
>
> Gah! Please fix your news client! (I see you're using slrn.)
> The \x92 bytes found in your message are apostrophes
> (technically: right single
On Tue, Oct 1, 2013 at 11:36 AM, rusi wrote:
>> (But I do sometimes yearn for a goto.)
>
> Ha! In Scheme, a tail call IS a goto with parameter re-assignment
Precisely. In fact, tail call optimization basically consists of that
exact rewrite. I'm absolutely fine with it being completely explicit.
-statement lambdas. It simply isn't
> important enough.
Agreed. λ-expressions are fundamental to functional programming theory; they
are not strictly necessary to practical functional programming.
[Miranda one of the predecessors to haskell and a seminal FP language had no
λ-expressions
On 1/10/2013 3:04 AM, Franck Ditter wrote:
1. Tail recursion is not optimized. We are in 2013, why ? This is known
technology (since 1960).
And don't answer with "good programmers don't use recursion", this is bullshit.
Here's an article Guido wrote explaining his reasoning:
http://neopythonic
On 9/30/2013 5:02 PM, Tim Chase wrote:
On 2013-09-30 19:04, Franck Ditter wrote:
two points make me crazy :
1. Tail recursion is not optimized. We are in 2013, why ? This is
known technology (since 1960). And don't answer with "good
programmers don't use recursion",
I seem to recall hearing th
On Mon, 30 Sep 2013 19:04:32 +0200, Franck Ditter wrote:
> Good approach of FP in Python, but two points make me crazy : 1. Tail
> recursion is not optimized. We are in 2013, why ? This is known
> technology (since 1960). And don't answer with "good programmers don't
> use recursion", this is bull
On Mon, 30 Sep 2013 18:36:28 +, Neil Cerutti quoted:
> Why cant lambda forms contain statements?
Gah! Please fix your news client! (I see you're using slrn.) The \x92
bytes found in your message are apostrophes (technically: right single
quotation marks), encoded using the legacy Windo
On 2013-09-30 19:04, Franck Ditter wrote:
> two points make me crazy :
> 1. Tail recursion is not optimized. We are in 2013, why ? This is
> known technology (since 1960). And don't answer with "good
> programmers don't use recursion",
I seem to recall hearing that the primary reason it hadn't bee
Op 30-09-13 20:55, Piet van Oostrum schreef:
Franck Ditter writes:
Good approach of FP in Python, but two points make me crazy :
1. Tail recursion is not optimized. We are in 2013, why ? This is known
technology (since 1960).
And don't answer with "good programmers don't use recursion", this
Op 30-09-13 19:04, Franck Ditter schreef:
Good approach of FP in Python, but two points make me crazy :
1. Tail recursion is not optimized. We are in 2013, why ? This is known
technology (since 1960).
And don't answer with "good programmers don't use recursion", this is bullshit.
Guido doesn
Franck Ditter writes:
> Good approach of FP in Python, but two points make me crazy :
> 1. Tail recursion is not optimized. We are in 2013, why ? This is known
> technology (since 1960).
> And don't answer with "good programmers don't use recursion", this is
> bullshit.
Tail recursion optimiza
On 2013-09-30, Franck Ditter wrote:
> In article ,
> rusi wrote:
>> I touched upon these in two blog-posts:
>> 1. http://blog.languager.org/2013/06/functional-programming-invades.html
>> 2. http://blog.languager.org/2012/10/functional-programming-lost-booty.html
>
On Tue, Oct 1, 2013 at 3:04 AM, Franck Ditter wrote:
> 1. Tail recursion is not optimized. We are in 2013, why ? This is known
> technology (since 1960).
> And don't answer with "good programmers don't use recursion", this is
> bullshit.
I've yet to see any value in having the compiler/interpre
for improving the lambda forms then that's
> > good. I wanted a link about functional programming because it is mentioned
> > as
> > if it were a household word.
>
> Python is not a functional programming language; however it supports most of
> FP better than tr
On Tuesday, September 24, 2013 8:56:21 PM UTC+5:30, Chris Angelico wrote:
> On Wed, Sep 25, 2013 at 1:07 AM, rusi wrote:
> > And this is an old conundrum in programming language design:
> >
> > In C printf is easy to write and NOT put into the language but into
> > external libraries
>
> > In Pa
On Wed, Sep 25, 2013 at 1:07 AM, rusi wrote:
> And this is an old conundrum in programming language design:
>
> In C printf is easy to write and NOT put into the language but into external
> libraries
> In Pascal, writeln cannot be outside the language because as a user defined
> function, its t
On Tuesday, September 24, 2013 8:21:19 PM UTC+5:30, Jussi Piitulainen wrote:
> Would the type system get in the way of providing some analogous
> function in Haskell? I don't know.
Yes.
The haskell curry
curry f x y = f (x,y)
is really only curry2
curry3 would be
curry3 f x y z = f (x,y,z)
and so
rusi writes:
> On Tuesday, September 24, 2013 1:12:51 PM UTC+5:30, Jussi Piitulainen wrote:
> > rusi writes:
> >
> > > Without resorting to lambdas/new-functions:
> > > With functools.partial one can freeze any subset of a
> > > function(callable's) parameters.
> >
> > > In Haskell one can onl
ue to
model multiple-argument functions in a single-argument framework and was a
meta-operation. In ML-like languages, the functions are typically already
curried, so the only operation you see being done is partial application.
---
from http://lambda-the-ultimate.org/node/2266
rusi writes:
> Without resorting to lambdas/new-functions:
> With functools.partial one can freeze any subset of a
> function(callable's) parameters.
>
> In Haskell one can only freeze the first parameter or at most with
> a right section the second
You have an f of type A -> B -> C -> D -> E
1 - 100 of 165 matches
Mail list logo
