A few comments come to mind about this discussion about TCO.
First, TCO, Tail Call Optimization, is talking about something that is
an optimization.
Optimizations, are generally some OPTIONAL improvement in the method of
executing the code that doesn't alter its DEFINED meaning.
First big
Op 15/08/20 om 15:02 schreef Chris Angelico:
> On Sat, Aug 15, 2020 at 10:45 PM Antoon Pardon
> wrote:
>>
>>
>> I don't understand this argument. The trace back information that is
>> destroyed with this optimization, is information that isn't available
>> anyway if you write the code in an
@Chris: you're very right, but, I repeat, you can't have a real TCO
(asyncio apart):
(venv_3_10) marco@buzz:~$ python
Python 3.10.0a0 (heads/master-dirty:ba18c0b13b, Aug 14 2020, 17:52:45)
[GCC 10.1.1 20200718] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>>
On Sat, Aug 15, 2020 at 10:45 PM Antoon Pardon
wrote:
>
> Op 7/08/20 om 18:45 schreef Chris Angelico:
> > On Sat, Aug 8, 2020 at 2:21 AM <2qdxy4rzwzuui...@potatochowder.com> wrote:
> >>
> >> On 2020-08-07 at 17:55:45 +0200,
> >> Marco Sulla wrote:
> >>> @Chris: note that "real" recursion in
Op 7/08/20 om 18:45 schreef Chris Angelico:
> On Sat, Aug 8, 2020 at 2:21 AM <2qdxy4rzwzuui...@potatochowder.com> wrote:
>>
>> On 2020-08-07 at 17:55:45 +0200,
>> Marco Sulla wrote:
>>> @Chris: note that "real" recursion in Python is not possible, since
>>> there's no support for tail recursion.
Christian Seberino wrote:
> A beginner I think could learn Lisp much faster than Python.
For talented beginners, Lisp rocks much like Python, in that easy assignments
are easy enough to implement. On the high end, Lisp rocks again: Lisp masters
are astonishingly productive. In between, beyond
On Tue, Aug 11, 2020 at 5:48 AM Roel Schroeven wrote:
> I'm not saying there is nothing useful in functional programming and the
> use of recursion; there most certainly is. But the way many texts
> introduce it IMO doesn't help at all to understand the elegance that can
> be achieved.
Indeed.
Terry Reedy schreef op 7/08/2020 om 22:08:
On 8/7/2020 11:46 AM, Chris Angelico wrote:
My point is that doing Fibonacci recursively is arguably more elegant
while being materially worse at performance.
This is a common misconception. Linear iteration and tail recursion are
equivalent. The
On Sat, 8 Aug 2020 at 03:46, Christian Seberino wrote:
> >> Readability of programming languages was measured
> >> using an objective method, and Python was one of
> >> the most readable.
>
> Do you have a source for this?
This question means you have not read at all my suggestions :-D
Anyway,
>> Readability of programming languages was measured
>> using an objective method, and Python was one of
>> the most readable.
Do you have a source for this?
--
https://mail.python.org/mailman/listinfo/python-list
On 8/7/20 6:55 PM, Marco Sulla wrote:
> On Sat, 8 Aug 2020 at 00:28, Richard Damon wrote:
>> The really interesting part is that since Lisp programs manipulate lists
>> as data, and the program is just a list, Lisp programs have the
>> theoretical ability to edit themselves (assuming the
On Sat, 8 Aug 2020 at 00:28, Richard Damon wrote:
> The really interesting part is that since Lisp programs manipulate lists
> as data, and the program is just a list, Lisp programs have the
> theoretical ability to edit themselves (assuming the implementation give
> access to the list of the
On 8/7/20 3:54 PM, Marco Sulla wrote:
> On Fri, 7 Aug 2020 at 19:48, Richard Damon wrote:
>> The difference is that the two languages define 'expression' differently.
>> [...]
> I don't know if this is interesting or pertinent to the topic.
>
> Christian Seberino just expressed a doubt about how
On 8/7/2020 11:55 AM, Marco Sulla wrote:
@Chris: note that "real" recursion in Python is not possible,
This is backwards. Python only does real recursion when one writes
recursive calls.
since there's no support for tail recursion.
I am pretty sure that what you mean by 'support' is to
On Sat, Aug 08, 2020 at 01:46:28AM +1000, Chris Angelico wrote:
> On Sat, Aug 8, 2020 at 1:38 AM Python wrote:
> TBH most people won't get the recursive version right the first time
> either.
So FWIW, I/my team don't find this to be true. I was originally going
to mention this in my previous
On 8/7/20 4:08 PM, Terry Reedy wrote:
> On 8/7/2020 11:46 AM, Chris Angelico wrote:
>
>> My point is that doing Fibonacci recursively is arguably more elegant
>> while being materially worse at performance.
>
> This is a common misconception. Linear iteration and tail recursion
> are equivalent.
On Sat, Aug 8, 2020 at 6:34 AM Terry Reedy wrote:
>
> On 8/7/2020 11:46 AM, Chris Angelico wrote:
>
> > My point is that doing Fibonacci recursively is arguably more elegant
> > while being materially worse at performance.
>
> This is a common misconception. Linear iteration and tail recursion
On Fri, 7 Aug 2020 at 22:35, Terry Reedy wrote:
> This is a common misconception. Linear iteration and tail recursion are
> equivalent. The issue is calculating values once versus multiple times.
> Here is the fast recursion equivalent to the fast iteration.
>
> def fib(n, pair=(1,0)):
>
On Fri, 7 Aug 2020 at 19:41, Christian Seberino wrote:
> I think this is really significant point why more syntax does necessarily
> mean less readability.
I don't think so. Readability of programming languages was measured
using an objective method, and Python was one of the most readable.
On 2020-08-07 at 13:43:06 -0500,
Wyatt Biggs wrote:
> > It's also probably significantly slower, so you'd likely still want to
> > use the iterative version
>
> Generalizing this to the majority of recursive functions/methods, are
> their iterative counterparts more efficient? (I say "majority
On 8/7/2020 11:46 AM, Chris Angelico wrote:
My point is that doing Fibonacci recursively is arguably more elegant
while being materially worse at performance.
This is a common misconception. Linear iteration and tail recursion are
equivalent. The issue is calculating values once versus
On 2020-08-07 at 21:54:35 +0200,
Marco Sulla wrote:
> On Fri, 7 Aug 2020 at 19:48, Richard Damon wrote:
> Christian Seberino just expressed a doubt about how a clear separation
> between a statement and an expression is quite desiderable in the
> "real" programming world. And I tried to
On 2020-08-07 at 11:02:50 -0700,
Christian Seberino wrote:
> > In Lisp, your hammer is the list.
>
> > In, say, Java, your tool is classes and inheritance.
>
> And yet if Lisp or Java programmers were here they would say their
> languages //are// multi-paradigm too. For example, Lisp has the
On Fri, 7 Aug 2020 at 19:48, Richard Damon wrote:
> The difference is that the two languages define 'expression' differently.
> [...]
I don't know if this is interesting or pertinent to the topic.
Christian Seberino just expressed a doubt about how a clear separation
between a statement and an
> It's also probably significantly slower, so you'd likely still want to
> use the iterative version
Generalizing this to the majority of recursive functions/methods, are their
iterative counterparts more efficient? (I say "majority of" because I've
personally encountered one or two recursive
> In Lisp, your hammer is the list.
> In, say, Java, your tool is classes and inheritance.
And yet if Lisp or Java programmers were here they would say their
languages //are// multi-paradigm too. For example, Lisp has the
Common Lisp Object System (CLOS) and Java has the Vector class and so
On 2020-08-07 at 10:00:25 -0600,
Akkana Peck wrote:
> I wrote:
> > > > Trying to maintain that recursive list of unclosed lists in your
> > > > brain is fun. It stretches the brain in interesting ways.
> > > > [ ... ] But I never found Lisp code very maintainable, [ ... ]
>
>
On 8/7/20 12:52 PM, Marco Sulla wrote:
> About statement vs expression: maybe you, Richard and
> 2QdxY4RzWzUUiLuE, are right, maybe not. This is hard to say, since the
> official C documentation is not public and you have to pay a small fee
> to obtain it.
>
> Anyway, I said "in C, the assignment
> Another point to consider is the ecosystem of your language. If you
> install Python, then you get basic math, I/O, a GUI toolkit, network
> libraries, ... In more "traditional" languages like C or Lisp, you get
> math and I/O, period. For everything else you need to hunt down a
> library.
Your iterative fib(x) code and comment was quite nice.
--
https://mail.python.org/mailman/listinfo/python-list
On Fri, 7 Aug 2020 at 18:48, Chris Angelico wrote:
> Tail call optimization (there's no reason to restrict it to recursion
> alone) is something a Python implementation could choose to do, but
> the trouble is that full optimization tends to destroy traceback
> information
Indeed this is
About statement vs expression: maybe you, Richard and
2QdxY4RzWzUUiLuE, are right, maybe not. This is hard to say, since the
official C documentation is not public and you have to pay a small fee
to obtain it.
Anyway, I said "in C, the assignment is a statement that can be used
in expression".
On Sat, Aug 8, 2020 at 2:44 AM Richard Damon wrote:
>
> On 8/7/20 11:46 AM, Chris Angelico wrote:
> > My point is that doing Fibonacci recursively is arguably more elegant
> > while being materially worse at performance, but there are other
> > examples that are fundamentally recursive, are just
On Sat, Aug 8, 2020 at 2:21 AM <2qdxy4rzwzuui...@potatochowder.com> wrote:
>
> On 2020-08-07 at 17:55:45 +0200,
> Marco Sulla wrote:
> > @Chris: note that "real" recursion in Python is not possible, since
> > there's no support for tail recursion. Maybe something similar can be
> > done using
On 8/7/20 11:46 AM, Chris Angelico wrote:
> My point is that doing Fibonacci recursively is arguably more elegant
> while being materially worse at performance, but there are other
> examples that are fundamentally recursive, are just as elegant (merge
> sort: "fracture the array in half, sort
On 8/7/20 11:55 AM, Marco Sulla wrote:
> Commonly, in imperative languages like C, you can write
>
> if (a = b) {...}
>
> This is allowed in C, even if a = b is not an expression, but an
> assignment statement. 99% of times you simply wrong and wanted:
But in C (and related languages) it IS an
On 2020-08-07 at 17:55:45 +0200,
Marco Sulla wrote:
> On Fri, 7 Aug 2020 at 17:14, Christian Seberino wrote:
> Commonly, in imperative languages like C, you can write
>
> if (a = b) {...}
>
> This is allowed in C, even if a = b is not an expression ...
In C, a = b *is* an expression. An
I wrote:
> > > Trying to maintain that recursive list of unclosed lists in your
> > > brain is fun. It stretches the brain in interesting ways.
> > > [ ... ] But I never found Lisp code very maintainable, [ ... ]
2qdxy4rzwzuui...@potatochowder.com writes:
> "[R]ecursive list of unclosed lists"?
Am 06.08.20 um 17:13 schrieb Christian Seberino:
Python is my favorite language and the easiest to use in my opinion.
Lisp has a far simpler grammar and syntax. A beginner I think could
learn Lisp much faster than Python.
Therefore, it seems like Lisp *should* be easier to work with and more
On Fri, 7 Aug 2020 at 17:14, Christian Seberino wrote:
> This is an interesting observation. I've heard people say the fact that
> Python has both expressions and statements is a negative. (Lisp only
> has expressions.)
Commonly, in imperative languages like C, you can write
if (a = b) {...}
On Sat, Aug 8, 2020 at 1:38 AM Python wrote:
>
> On Fri, Aug 07, 2020 at 04:23:42PM +1000, Chris Angelico wrote:
> > On Fri, Aug 7, 2020 at 11:11 AM Python wrote:
> > > Pretty straightforward. Now try yourself to write the iterative
> > > version.
> >
> > It might look slightly better to a
On Fri, Aug 07, 2020 at 04:23:42PM +1000, Chris Angelico wrote:
> On Fri, Aug 7, 2020 at 11:11 AM Python wrote:
> > Pretty straightforward. Now try yourself to write the iterative
> > version.
>
> It might look slightly better to a mathematician, but it's so
> abysmally inefficient (unless you
> 1. Python mostly separates computation of values (expressions) from flow
> control and name binding (statements). When the latter are mixed with
> the former, most people restrict the mixing to a line or two.
This is an interesting observation. I've heard people say the fact that
Python
On Sat, Aug 8, 2020 at 1:06 AM Christian Seberino wrote:
>
>
> > ChrisA
>
> You're definitely an expert programmer.
>
Uhh thank you? I think? I'm not sure if you're complimenting me or
making some sort of joke relating to the code I posted, or if it's
actually nothing to do with me at all.
> ChrisA
You're definitely an expert programmer.
--
https://mail.python.org/mailman/listinfo/python-list
> If "the Python way" seems simpler to you than "the Lisp way,"
> or iteration seems simpler to you than recursion, then so be it. Other
> languages and other programmers are different.
I think this is so true. I've had similar conversations with Lisp fans
and it has confused me at times why
On 8/6/2020 11:13 AM, Christian Seberino wrote:
Python is my favorite language and the easiest to use in my opinion.
Lisp has a far simpler grammar and syntax. A beginner I think could
learn Lisp much faster than Python.
Therefore, it seems like Lisp *should* be easier to work with and more
On 8/6/2020 2:39 PM, Akkana Peck wrote:
Christian Seberino writes:
Python is my favorite language and the easiest to use in my opinion.
Lisp has a far simpler grammar and syntax. A beginner I think could
learn Lisp much faster than Python.
Therefore, it seems like Lisp *should* be easier to
On Fri, Aug 7, 2020 at 11:11 AM Python wrote:
> Not necessarily. Some problems very naturally lend themselves to
> recursive solutions. Fibonacci's sequence is one.
>
> #!/usr/bin/python
>
> def fib(x):
> if x < 1:
> raise "arg must be >= 1"
> if x == 1:
> return 0
>
On 2020-08-06 at 20:07:05 -0700,
Christian Seberino wrote:
> Some problems are well suited to recursion but perhaps //most//
> problems are better suited to iteration?
> Maybe the spread is 10% vs 90%?
Citation needed?
> Therefore in general more often the Python way seems simpler than Lisp?
Some problems are well suited to recursion but perhaps //most// problems are
better suited to iteration?
Maybe the spread is 10% vs 90%?
Therefore in general more often the Python way seems simpler than Lisp?
--
https://mail.python.org/mailman/listinfo/python-list
On 2020-08-06 at 16:08:29 -0700,
Christian Seberino wrote:
> > Trying to maintain that recursive list of unclosed lists in your
> > brain is fun. It stretches the brain in interesting ways. I was
> > way into Lisp at one point, including writing several Lisp
> > interpreters (that simple
On Thu, Aug 06, 2020 at 04:08:29PM -0700, Christian Seberino wrote:
> > Trying to maintain that recursive list of unclosed lists in your
> > brain is fun. It stretches the brain in interesting ways. I was
> > way into Lisp at one point, including writing several Lisp
> > interpreters (that simple
> Trying to maintain that recursive list of unclosed lists in your
> brain is fun. It stretches the brain in interesting ways. I was
> way into Lisp at one point, including writing several Lisp
> interpreters (that simple structure makes Lisp very easy to
> implement). But I never found Lisp code
On 8/6/20 4:07 PM, 2qdxy4rzwzuui...@potatochowder.com wrote:
> for (index, value) in enumerate(this_list):
> this_list[index] = 2 * value
>
> Or:
>
> for index in range(len(this_list)):
> this_list[index] *= 2
>
> (But I tend to avoid that, though, because I can never
On 2020-08-07 at 05:22:53 +1000,
Chris Angelico wrote:
> On Fri, Aug 7, 2020 at 5:10 AM <2qdxy4rzwzuui...@potatochowder.com> wrote:
> One thing worth noting is that your mental pseudo-code is affected by
> the languages you're comfortable with. You said:
>
> > create a new list in which each
On Fri, Aug 7, 2020 at 5:10 AM <2qdxy4rzwzuui...@potatochowder.com> wrote:
>
> I would say that expressiveness is how *directly* you can translate your
> ideas into code, and how *directly* some one else can see your original
> idea by reading your code.
Yep, how directly or how accurately.
> So
On 2020-08-07 at 04:00:34 +1000,
Regarding "Re: How explain why Python is easier/nicer than Lisp which has a
simpler grammar/syntax?,"
Chris Angelico wrote:
> On Fri, Aug 7, 2020 at 2:36 AM Christian Seberino wrote:
> >
> > On Thursday, August 6, 2020 at 10:52:00 AM UT
Christian Seberino writes:
> Python is my favorite language and the easiest to use in my opinion.
>
> Lisp has a far simpler grammar and syntax. A beginner I think could
> learn Lisp much faster than Python.
>
> Therefore, it seems like Lisp *should* be easier to work with and more
>
On Fri, Aug 7, 2020 at 2:36 AM Christian Seberino wrote:
>
> On Thursday, August 6, 2020 at 10:52:00 AM UTC-5, Chris Angelico wrote:
> > The point of learning a
> > language isn't that you can take a piece of pre-existing code and
> > figure out what it'll do, step by step; the point is to be
On Thursday, August 6, 2020 at 10:52:00 AM UTC-5, Chris Angelico wrote:
> The point of learning a
> language isn't that you can take a piece of pre-existing code and
> figure out what it'll do, step by step; the point is to be able to
> encode your intentions in that language, and to read the code
On Fri, Aug 7, 2020 at 1:16 AM Christian Seberino wrote:
>
> Python is my favorite language and the easiest to use in my opinion.
>
> Lisp has a far simpler grammar and syntax. A beginner I think could
> learn Lisp much faster than Python.
>
> Therefore, it seems like Lisp *should* be easier to
Python is my favorite language and the easiest to use in my opinion.
Lisp has a far simpler grammar and syntax. A beginner I think could
learn Lisp much faster than Python.
Therefore, it seems like Lisp *should* be easier to work with and more
readable. I don't feel like it is easier to use
63 matches
Mail list logo
