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
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 lett
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
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 functio
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
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.
On Tuesday, October 1, 2013 6:11:18 AM UTC+5:30, Steven D'Aprano wrote:
> On Mon, 30 Sep 2013 19:04:32 +0200, Franck Ditter wrote:
> > 2. Lambda-expression body is limited to one expression. Why ?
>
> Nobody has come up with syntax that is unambiguous, would allow multiple
> statements in an expr
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
>>
>> Also most programmers with
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
In article ,
rusi wrote:
> Combining your two questions -- Recently:
> What minimum should a person know before saying "I know Python"
>
> And earlier this
> On Sunday, August 4, 2013 10:00:35 PM UTC+5:30, Aseem Bansal wrote:
> > If there is an issue in place for improving the lambda forms then
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
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 only freeze the first parame
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
On Monday, September 23, 2013 11:54:53 PM UTC+5:30, Vito De Tullio wrote:
> rusi wrote:
>
> > [Not everything said there is correct; eg python supports currying better
> > [than haskell which is surprising considering that Haskell's surname is
> > [Curry!]
>
>
> AFAIK python does not support cur
Vito De Tullio writes:
> rusi wrote:
>
> > [Not everything said there is correct; eg python supports currying
> > better [than haskell which is surprising considering that
> > Haskell's surname is [Curry!]
>
> AFAIK python does not support currying at all (if not via some
> decorators or somethi
rusi wrote:
> [Not everything said there is correct; eg python supports currying better
> [than haskell which is surprising considering that Haskell's surname is
> [Curry!]
AFAIK python does not support currying at all (if not via some decorators or
something like that).
Instead every function
90 matches
Mail list logo
