Re: Functional Programming and python
On Tue, Oct 1, 2013 at 11:36 AM, rusi rustompm...@gmail.com 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. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Functional Programming and python
On 2013-10-01, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info 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 quotation marks), encoded using the legacy Windows-1252 codec, but your news client is falsely advertising it as US-ASCII: Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit It's almost 2014, it is unspeakably poor form that an application is still making this mistake. Is there an updated version of slrn that fixes this? Can you manually force it to use UTF-8? Can you report this as a bug? In case you aren't too clear on the concepts, here are two Must Read links: http://www.joelonsoftware.com/articles/Unicode.html http://nedbatchelder.com/text/unipain.html Thanks, Steve. I'm aware my news setup is crap when it comes to character set/unicode support. I haven't been motivated to fix it, because everything else about it works great for me. I'm afraid slrn is stagnated, but it might provide at least some support and I need to find out what. -- Neil Cerutti -- https://mail.python.org/mailman/listinfo/python-list
Re: Functional Programming and python
Antoon Pardon antoon.par...@rece.vub.ac.be writes: Op 30-09-13 20:55, Piet van Oostrum schreef: Franck Ditter nob...@nowhere.org 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 optimization throws away valuable stack trace information in case of an error. This is hardly relevant. Because what are we told to use instead of tail calls? We are told to use loops. But when you use a loop the stack trace doesn't contain the values of previous runs through the loop. So how valuable is that stack frame information when the proposed alternative doesn't produces it either. This is incorrect. Loops are not always a replacement for tail recursion optimization. Tail recursion optimization generally means that the last function call before a return in a function reuses the current stack frame instead of generating a new one. This is regardless of which function is called, otherwise mutually recursive calls will not be optimized. (Unless you do static analysis of all the functions calls involved, which is very hard or even impossible in python.) A better name for this process is therefore 'tail call optimization'. So any function call that is last in its flow will be optimized. This gives a lot of situations where stack trace information is thrown away, even in those situations where a loop would not be an alternative and where optimization would give little benefit. Anyway, deep recursion isn't used very often in Python, which diminishes the value of tail call optimization. -- Piet van Oostrum p...@vanoostrum.org WWW: http://pietvanoostrum.com/ PGP key: [8DAE142BE17999C4] -- https://mail.python.org/mailman/listinfo/python-list
Re: Functional Programming and python
In article ba94102b-18b6-4850-ac85-032b0fe2f...@googlegroups.com, rusi rustompm...@gmail.com 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 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 traditional languages like C/Java. eg with iterators/generators + itertools + functools you can do most of what lazy lists give in haskell Some discussion here: http://stackoverflow.com/questions/1017621/why-isnt-python-very-good-for-functional-programming [Not everything said there is correct; eg python supports currying better than haskell which is surprising considering that Haskell's surname is Curry!] So if I may break your question into two: 1. Why should a programmer of a non-FP language know FP? 2. What in FP should a (any|all) programmer know? 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 without an FP background have a poor appreciation of the centrality of recursion in CS; see http://blog.languager.org/2012/05/recursion-pervasive-in-cs.html 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. 2. Lambda-expression body is limited to one expression. Why ? Why the hell those limitations ? In this aspect, Javascript has a cooler approach. franck -- https://mail.python.org/mailman/listinfo/python-list
Re: Functional Programming and python
On Tue, Oct 1, 2013 at 3:04 AM, Franck Ditter nob...@nowhere.org 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/interpreter optimize
tail recursion that can't be achieved just as well, and usually more
clearly, with simple iteration. Recursion's important; tail
recursion's important; tail recursion optimization isn't. (But I do
sometimes yearn for a goto.)
2. Lambda-expression body is limited to one expression. Why ?
Why the hell those limitations ? In this aspect, Javascript has a cooler
approach.
Since you can just use def in the middle of another function, the
difference between def and lambda isn't all that huge. Yes, def isn't
an expression - but Python's lambda gives an incredibly compact
notation for the common case. Compare these two snippets:
# Python
odd_numbers = filter(lambda x: x%2, numbers)
//Pike
odd_numbers = filter(numbers, lambda(int x) {return x%2;})
Aside from the type declaration and the argument order, these two
snippets are doing exactly the same thing in exactly the same way.
Python's version is way more compact. Pike's version lets you put
multiple statements into the expression... but most of the time you
don't need that. Both approaches have their value.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: Functional Programming and python
On 2013-09-30, Franck Ditter nob...@nowhere.org wrote: In article ba94102b-18b6-4850-ac85-032b0fe2f...@googlegroups.com, rusi rustompm...@gmail.com 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 without an FP background have a poor appreciation of the centrality of recursion in CS; see http://blog.languager.org/2012/05/recursion-pervasive-in-cs.html 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. If you've got a set of recursive functions with recursive calls in tail-call position it's pretty easy to convert to a solution that doesn't blow the stack. Converting to a while loop is usually straightforward, or you try trampolining. If the calls aren't in tail-call position then you wouldn't get tail-call optimization from a language like scheme, either. Getting calls in tail position is often the sticking point, and tail-call optimization doesn't help with that. I think the Python rationale also discusses how it would make tracebacks harder to understand if stackframes could clobber each other. Personally I think that's more a theoretical than a practical problem. Languages with tail-call optimization aren't impossible to debug. 2. Lambda-expression body is limited to one expression. Why ? Why the hell those limitations ? In this aspect, Javascript has a cooler approach. It's in the Design and History FAQ. http://docs.python.org/3/faq/design.html Why cant lambda forms contain statements? Python lambda forms cannot contain statements because Pythons syntactic framework cant handle statements nested inside expressions. However, in Python, this is not a serious problem. Unlike lambda forms in other languages, where they add functionality, Python lambdas are only a shorthand notation if youre too lazy to define a function. Functions are already first class objects in Python, and can be declared in a local scope. Therefore the only advantage of using a lambda form instead of a locally-defined function is that you dont need to invent a name for the function but thats just a local variable to which the function object (which is exactly the same type of object that a lambda form yields) is assigned! What I usually end up with is a dictionary of callbacks, with the simple functions defined in-line and the more complex functions defined just before that and referenced instead. -- Neil Cerutti -- https://mail.python.org/mailman/listinfo/python-list
Re: Functional Programming and python
Franck Ditter nob...@nowhere.org 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 optimization throws away valuable stack trace information in case of an error. 2. Lambda-expression body is limited to one expression. Why ? Allowing general statements in a lambda body makes indentation more difficult, I think. -- Piet van Oostrum p...@vanoostrum.org WWW: http://pietvanoostrum.com/ PGP key: [8DAE142BE17999C4] -- https://mail.python.org/mailman/listinfo/python-list
Re: Functional Programming and python
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't like it. 2. Lambda-expression body is limited to one expression. Why ? Why the hell those limitations ? In this aspect, Javascript has a cooler approach. Guido prefers it that way. -- Antoon Pardon -- https://mail.python.org/mailman/listinfo/python-list
Re: Functional Programming and python
Op 30-09-13 20:55, Piet van Oostrum schreef: Franck Ditter nob...@nowhere.org 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 optimization throws away valuable stack trace information in case of an error. This is hardly relevant. Because what are we told to use instead of tail calls? We are told to use loops. But when you use a loop the stack trace doesn't contain the values of previous runs through the loop. So how valuable is that stack frame information when the proposed alternative doesn't produces it either. -- Antoon Pardon -- https://mail.python.org/mailman/listinfo/python-list
Re: Functional Programming and python
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 been implemented is because of Python's super-dynamism (to make up a word). That a function could be a tail recursion in one call, but the calling the same name could then become rebound. I'm making up the example, but I think it was something like this: def kablooie(*args): if not args: def kablooie(*args): woah() do_something(args) kablooie(args[1:]) where tail recursion optimization would do weird things. -tkc -- https://mail.python.org/mailman/listinfo/python-list
Re: Functional Programming and python
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 Windows-1252 codec, but your news client is falsely advertising it as US-ASCII: Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit It's almost 2014, it is unspeakably poor form that an application is still making this mistake. Is there an updated version of slrn that fixes this? Can you manually force it to use UTF-8? Can you report this as a bug? In case you aren't too clear on the concepts, here are two Must Read links: http://www.joelonsoftware.com/articles/Unicode.html http://nedbatchelder.com/text/unipain.html -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Functional Programming and python
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 bullshit. Tail recursion optimization isn't really that useful. There is a HUGE universe of recursive problems which are not tail-recursive, and so cannot be optimized at all, or at least not automatically. Instead of encouraging people to rewrite such code using tail-recursion, which usually ends up obfuscating the code and introducing subtle bugs, it is better to encourage them to rewrite it to be iterative instead of recursive. Or just use recursion -- in many cases (although not all), if you have to recurse so many times that you pass the limit, your code is probably doing something wrong. So tail-recursion optimization only helps in a tiny subset of recursive problems. Usually it doesn't help at all. And one cost is that you lose debugging information. Don't think of a single recursive function, where the traceback is extremely boring: py f() Traceback (most recent call last): File stdin, line 1, in module File stdin, line 2, in f File stdin, line 2, in f [...] File stdin, line 2, in f File stdin, line 2, in f File stdin, line 2, in f RuntimeError: maximum recursion depth exceeded Think of mutually recursive functions, where f calls g which calls h which sometimes calls f and sometimes calls g... Personally, I'm not 100% convinced by these arguments. I think having a runtime option to enable or disable tail recursive optimizations would make Python a better language. Not by a lot, but by a tiny bit. But the people who would actually do the work don't care enough to do it, and the people who say they care don't bother doing the work. 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 expression, doesn't break backwards compatibility, and isn't ugly. Since lambda is just a convenience, not a necessity -- it almost got dropped from Python 3 -- it is not worth compromising on those design requirements just for multiple-statement lambdas. It simply isn't important enough. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Functional Programming and python
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 that the primary reason it hadn't been implemented is because of Python's super-dynamism (to make up a word). Right. A tail call is a call immediately followed by a return (in the byte code or equivalent). A recursive tail call is a tail call to the function containing the tail call. In Python, the function to be called in a call is not determined until the call is made. This is because the function expression is evaluated to a function object at runtime, not when the function is compiled. It would be trivial to detect and somewhat optimize all tail calls in CPython. But the result would be to delete traceback info with *all* tail calls, not just for recursive tail calls. Some functions have multiple recursive calls, as with divide and conquer algorithms and graph traversal. The last recursive call might or might not be a tail call. When it is, having calls omitted from the traceback might be undesireable. It might be disconcerting, for instance, if the number of calls in the traceback for a balanced binary tree algorithm did *not* match the level where the error took place. That a function could be a tail recursion in one call, but the calling the same name could then become rebound. I'm making up the example, but I think it was something like this: def kablooie(*args): if not args: def kablooie(*args): woah() do_something(args) kablooie(args[1:]) where tail recursion optimization would do weird things. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Functional Programming and python
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.blogspot.com.au/2009/04/tail-recursion-elimination.html -- https://mail.python.org/mailman/listinfo/python-list
Re: Functional Programming and python
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 expression, doesn't break backwards compatibility, and isn't ugly. Since lambda is just a convenience, not a necessity -- it almost got dropped from Python 3 -- it is not worth compromising on those design requirements just for multiple-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 ] I find serious limitations in python from the pov of effectively doing FP; λ-expression limitations not the most crucial. eg - scope leakage in comprehensions - no comprehensions for tuples - need to use assignments to simulate let - mutable default parameters leak scope On Monday, September 30, 2013 10:47:45 PM UTC+5:30, Chris Angelico wrote: 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/interpreter optimize tail recursion that can't be achieved just as well, and usually more clearly, with simple iteration. Recursion's important; tail recursion's important; tail recursion optimization isn't. Yeah -- since register allocation is isomorphic to graph-coloring[1] and graph-coloring is computationally hard[2], lets all go back to machine language! [1] http://en.wikipedia.org/wiki/Register_allocation#Isomorphism_to_graph_colorability [2] http://en.wikipedia.org/wiki/Graph_coloring#Algorithms (But I do sometimes yearn for a goto.) Ha! In Scheme, a tail call IS a goto with parameter re-assignment The real advantage to mandatory tail-call optimized language like scheme is pedagogical. Students brought up on a scheme-like philosophy are liable to see recursion and iteration as synonymous [Certain common forms of recursion are more easily expressed as loops] and be more easy switching between them. Recursion is just too central to the business of programming to afford having it pushed to one side in beginner's heads. http://blog.languager.org/2012/05/recursion-pervasive-in-cs.html The irony is that most non-FP programmers imagine that FP consists of using recursion for any and everything. See the progression and specially the last entry here http://www.willamette.edu/~fruehr/haskell/evolution.html - no loops - no recursion - if possible no variables (the 'pointless' version) -- https://mail.python.org/mailman/listinfo/python-list
Re: Functional Programming and python
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 something like that).
I suppose rusi means functools.partial:
from functools import partial
trip = lambda x,y,z: (x,y,z)
partial(trip,'a','b')('c')
('a', 'b', 'c')
It also supports keyword arguments.
Instead every function in haskell implicitly support currying...
so... how does no support is better than full support?
Yes. I'm satisfied that Python does, but what can be seen as a
shortcoming in Haskell? Just curious.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Functional Programming and python
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 currying at all (if not via some decorators or something like that). Instead every function in haskell implicitly support currying... so... how does no support is better than full support? 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 -- https://mail.python.org/mailman/listinfo/python-list
Re: Functional Programming and python
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 in Haskell, you can freeze the first three parameters by calling it with three arguments. These are equivalent: f a b c d (f a b c) d (f a b) c d (f a) b c d So it's any initial sequence of arguments, not just the first. And I thought such types were preferred over A * B * C * D - E in Haskell, so you tend to get this for free. Not sure of the syntax here - it's been long since I did anything at all with Haskell. A difference seems to be that in Python, a call can refer to named parameters. This gives functools.partial some power over Haskell. Another difference is that the value of functools.partial is always a function that needs to be called with the remaining arguments, even if there are none. Both the creation and the evaluation of the curried functions just happens in Haskell. (I also think that the word currying used to refer to what Haskell does and it's an extension to use it to mean any partial evaluation.) -- https://mail.python.org/mailman/listinfo/python-list
Re: Functional Programming and python
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 parameter or at most with a right section the second You have an f of type A - B - C - D - E in Haskell, you can freeze the first three parameters by calling it with three arguments. These are equivalent: f a b c d (f a b c) d (f a b) c d (f a) b c d So it's any initial sequence of arguments, not just the first. Agreed. I missed that. However as n increases there are n initial sequences (Haskell) whereas there are 2^n possible subsets (Python) (2^n - 1 if we remove the fully saturated case). So I would argue that Python syntax gives more flexibility in this direction than Haskell. Add the further feature of **args and its even more (I also think that the word currying used to refer to what Haskell does and it's an extension to use it to mean any partial evaluation.) Hmm… Seems this is a contentious issue http://en.wikipedia.org/wiki/Currying#Contrast_with_partial_function_application which links to this LtU post that I find neat: --- If I have a function f:(x,y)-z, I can't apply it to only one of its arguments. I can curry it, turning it into a function g:x-(y-z) ... and I can apply g to only one of the original arguments. But turning f into g and applying g to some x are technically different things. I suspect the confusion arises because originally currying was a technique 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 - Anyways thanks for that Ive added it to my 'lost-booty' list http://blog.languager.org/2012/10/functional-programming-lost-booty.html#curry -- https://mail.python.org/mailman/listinfo/python-list
Re: Functional Programming and python
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 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 in Haskell, you can freeze the first three parameters by calling it with three arguments. These are equivalent: f a b c d (f a b c) d (f a b) c d (f a) b c d So it's any initial sequence of arguments, not just the first. Agreed. I missed that. Ok. However as n increases there are n initial sequences (Haskell) whereas there are 2^n possible subsets (Python) (2^n - 1 if we remove the fully saturated case). So I would argue that Python syntax gives more flexibility in this direction than Haskell. Strictly speaking and in principle, yes. I'm not sure how important this is in practice: the positional parameter list should be short anyway, Haskell does have the special mechanism for the second, and there is always the fully general mechanism (lambda) in both languages (and in another language I use that has neither built-in currying nor keyword parameters :). I agree that the ability to identify arguments by name gives a useful amount of quite practical power, and I see that functools.partial uses it nicely. So, no real disagreement on this from me. Would the type system get in the way of providing some analogous function in Haskell? I don't know. Add the further feature of **args and its even more (I also think that the word currying used to refer to what Haskell does and it's an extension to use it to mean any partial evaluation.) Hmm[] Seems this is a contentious issue http://en.wikipedia.org/wiki/Currying#Contrast_with_partial_function_application which links to this LtU post that I find neat: [snip] Thanks. I don't think I have anything useful to add, though. -- https://mail.python.org/mailman/listinfo/python-list
Re: Functional Programming and python
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 on upwards Vanilla Haskell makes it real hard to put all these under one type umbrella By comparison python's partial is quite effortless. 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 type would not fit the type system. And so printf can be made to crash quite easily; not so writeln! -- https://mail.python.org/mailman/listinfo/python-list
Re: Functional Programming and python
On Wed, Sep 25, 2013 at 1:07 AM, rusi rustompm...@gmail.com 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 type would not fit the type system. And so printf can be made to crash quite easily; not so writeln! I assume you're talking about mismatching percent-markers and arguments, there. That's because of a limitation in C's variadic function support, ameliorated somewhat by gcc's warnings system, and completely solved by other languages in which (s)printf can still be an external function, but with reliable type checking. It's not whether it's part of the language or not that does that. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Functional Programming and python
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 Pascal, writeln cannot be outside the language because as a user defined function, its type would not fit the type system. And so printf can be made to crash quite easily; not so writeln! I assume you're talking about mismatching percent-markers and arguments, there. That's because of a limitation in C's variadic function support, ameliorated somewhat by gcc's warnings system, and completely solved by other languages in which (s)printf can still be an external function, but with reliable type checking. It's not whether it's part of the language or not that does that. Sure there can be and are specific workarounds. My point was a general one: Strong type system: Some desirable programs will get kicked out Weak type system: Some undesirable programs will slip in 'Exactly' correct type system: Impossible by halting problem -- https://mail.python.org/mailman/listinfo/python-list
Re: Functional Programming and python
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 in haskell implicitly support currying... so... how does no support is better than full support? -- By ZeD -- https://mail.python.org/mailman/listinfo/python-list
