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

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

Functional Programing: stop using recursion, cons. Use map & vectors

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

Contents

  Functional Programing: stop using recursion, cons. Use map & vectors Xah Lee <xahlee@gmail.com> - 2011-05-22 15:47 -0700
    Re: Functional Programing: stop using recursion, cons. Use map & vectors Deeyana <d.awlberg@hotmail.invalid> - 2011-05-23 02:29 +0000
      Re: Functional Programing: stop using recursion, cons. Use map & vectors asandroq <asandroq@gmail.com> - 2011-05-23 00:52 -0700
        Re: Functional Programing: stop using recursion, cons. Use map & vectors Deeyana <d.awlberg@hotmail.invalid> - 2011-05-23 22:27 +0000
          Re: Functional Programing: stop using recursion, cons. Use map & vectors asandroq <asandroq@gmail.com> - 2011-05-24 13:39 -0700
            Re: Functional Programing: stop using recursion, cons. Use map & vectors Deeyana <d.awlberg@hotmail.invalid> - 2011-05-25 00:03 +0000
          Re: Functional Programing: stop using recursion, cons. Use map & vectors Chris Angelico <rosuav@gmail.com> - 2011-05-25 08:38 +1000
    Re: Functional Programing: stop using recursion, cons. Use map & vectors torbenm@diku.dk (Torben Ægidius Mogensen) - 2011-05-23 10:51 +0200
      Re: Functional Programing: stop using recursion, cons. Use map & vectors "Pascal J. Bourguignon" <pjb@informatimago.com> - 2011-05-23 15:39 +0200
        Re: Functional Programing: stop using recursion, cons. Use map & vectors Antti J Ylikoski <antti.ylikoski@tkk.fi> - 2011-05-23 19:36 +0300

#6017 — Functional Programing: stop using recursion, cons. Use map & vectors

this is important but i think most lispers and functional programers
still don't know it.

Functional Programing: stop using recursion, cons. Use map & vectors.

〈Guy Steele on Parallel Programing〉
http://xahlee.org/comp/Guy_Steele_parallel_computing.html

btw, lists (as cons, car, cdr) in the lisp world has always been some
kinda cult. Like, if you are showing some code example and you
happened to use lisp vector datatype and not cons (lists) and it
doesn't really matter in your case, but some lisper will always rise
up to bug you, either as innocent curious question or attacking you
for not “understanding” lisp. (just as other idiocies happen in other
lang that lispers see but other langs don't see)

it's interesting to me that all other high level langs: Mathematica,
perl, python, php, javascript, all don't have linked list as lisp's
list. It's also curious that somehow lispers never realises this. I've
been having problems with lisp's cons ever since i'm learning Scheme
Lisp in 1998 (but mostly the reason is language design at syntax and
lack of abstraction level in calling “cons, car, cdr” stuff, without
indexing mechanism). Realizing the algorithmic property and parallel-
execution issues of linked list is only recent years.

 Xah

[toc] | [next] | [standalone]

#6032

On Sun, 22 May 2011 15:47:53 -0700, Xah Lee wrote:

> this is important but i think most lispers and functional programers
> still don't know it.
> 
> Functional Programing: stop using recursion, cons. Use map & vectors.
> 
> 〈Guy Steele on Parallel Programing〉
> http://xahlee.org/comp/Guy_Steele_parallel_computing.html
> 
> btw, lists (as cons, car, cdr) in the lisp world has always been some
> kinda cult. Like, if you are showing some code example and you happened
> to use lisp vector datatype and not cons (lists) and it doesn't really
> matter in your case, but some lisper will always rise up to bug you,
> either as innocent curious question or attacking you for not
> “understanding” lisp. (just as other idiocies happen in other lang that
> lispers see but other langs don't see)
> 
> it's interesting to me that all other high level langs: Mathematica,
> perl, python, php, javascript, all don't have linked list as lisp's
> list. It's also curious that somehow lispers never realises this. I've
> been having problems with lisp's cons ever since i'm learning Scheme
> Lisp in 1998 (but mostly the reason is language design at syntax and
> lack of abstraction level in calling “cons, car, cdr” stuff, without
> indexing mechanism). Realizing the algorithmic property and parallel-
> execution issues of linked list is only recent years.

You might be interested in Clojure, then. Lists are more abstracted, like 
in Scheme, and vectors and also dictionaries/maps and sets are first 
class citizens along side lists. And unlike Scheme, Clojure has good 
library/host interop support. You can write real-world applications in it 
without spontaneously combusting.

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

#6047

On May 23, 4:29 am, Deeyana <d.awlb...@hotmail.invalid> wrote:
>
> You might be interested in Clojure, then. Lists are more abstracted, like
> in Scheme, and vectors and also dictionaries/maps and sets are first
> class citizens along side lists. And unlike Scheme, Clojure has good
> library/host interop support. You can write real-world applications in it
> without spontaneously combusting.

     Nonsense. Several Scheme systems have excellent FFIs with more
than "good library/host interop support".

-alex

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

#6098

On Mon, 23 May 2011 00:52:07 -0700, asandroq wrote:

> On May 23, 4:29 am, Deeyana <d.awlb...@hotmail.invalid> wrote:
>>
>> You might be interested in Clojure, then. Lists are more abstracted,
>> like in Scheme, and vectors and also dictionaries/maps and sets are
>> first class citizens along side lists. And unlike Scheme, Clojure has
>> good library/host interop support. You can write real-world
>> applications in it without spontaneously combusting.
> 
>      Nonsense.

Classic unsubstantiated and erroneous claim. Nothing that I write is ever 
"nonsense".

> Several Scheme systems have excellent FFIs with more than "good library/
> host interop support".

Classic unsubstantiated and erroneous claim. Scheme does not come OOTB 
with any suitable libraries for host interop and though it can make calls 
to C libraries, doing so is awkward and involves difficulties with the 
impedance mismatch between Scheme's data structures and C's char *, void 
*, int, double, array, etc. types. To top it off, C lacks automatic 
memory management, which means you'll have to concern yourself with 
manually disposing of allocated data structures used in interop. (Or, 
worse, things will get garbage collected by the Scheme runtime that the 
Scheme code no longer references, but the C library is still using, and 
bam! SIGSEGV.)

And then you gain what, the diverse mix of platform-specific, unportable, 
sometimes-wonky C libraries?

Versus Clojure immediately granting simple, easy to use access to a large 
standard Java library that works more or less the same across a broad 
range of host platforms, as well as the rest of the JVM library 
ecosystem, which mostly has the same qualities. Clojure being designed 
for the JVM, there's much less of an impedance mismatch with Java's 
types, and the interop call syntax is easy to master and won't set your 
hair on fire.

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

#6174

On May 24, 12:27 am, Deeyana <d.awlb...@hotmail.invalid> wrote:
>
> Classic unsubstantiated and erroneous claim. Scheme does not come OOTB
> with any suitable libraries for host interop and though it can make calls
> to C libraries, doing so is awkward and involves difficulties with the
> impedance mismatch between Scheme's data structures and C's char *, void
> *, int, double, array, etc. types. To top it off, C lacks automatic
> memory management, which means you'll have to concern yourself with
> manually disposing of allocated data structures used in interop. (Or,
> worse, things will get garbage collected by the Scheme runtime that the
> Scheme code no longer references, but the C library is still using, and
> bam! SIGSEGV.)
>

Classic unsubstantiated and erroneous claim.

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

#6187

On Tue, 24 May 2011 13:39:15 -0700, asandroq wrote:

> On May 24, 12:27 am, Deeyana <d.awlb...@hotmail.invalid> wrote:
>>
>> Classic unsubstantiated and erroneous claim. Scheme does not come OOTB
>> with any suitable libraries for host interop and though it can make
>> calls to C libraries, doing so is awkward and involves difficulties
>> with the impedance mismatch between Scheme's data structures and C's
>> char *, void *, int, double, array, etc. types. To top it off, C lacks
>> automatic memory management, which means you'll have to concern
>> yourself with manually disposing of allocated data structures used in
>> interop. (Or, worse, things will get garbage collected by the Scheme
>> runtime that the Scheme code no longer references, but the C library is
>> still using, and bam! SIGSEGV.)
>
> Classic unsubstantiated and erroneous claim.

On your part, asandroq.

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

#6182

On Tue, May 24, 2011 at 8:27 AM, Deeyana <d.awlberg@hotmail.invalid> wrote:
> Classic unsubstantiated and erroneous claim. Scheme does not come OOTB
> with any suitable libraries for host interop and though it can make calls
> to C libraries, doing so is awkward and involves difficulties with the
> impedance mismatch between Scheme's data structures and C's char *, void
> *, int, double, array, etc. types. To top it off, C lacks automatic
> memory management, which means you'll have to concern yourself with
> manually disposing of allocated data structures used in interop. (Or,
> worse, things will get garbage collected by the Scheme runtime that the
> Scheme code no longer references, but the C library is still using, and
> bam! SIGSEGV.)

How is this fundamentally different from Python calling into C?

Chris Angelico

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

#6051

Xah Lee <xahlee@gmail.com> writes:


> Functional Programing: stop using recursion, cons. Use map & vectors.
>
> 〈Guy Steele on Parallel Programing〉
> http://xahlee.org/comp/Guy_Steele_parallel_computing.html

This is more or less what Backus said in his Turing Award lecture about
FP.

	Torben

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

#6075

torbenm@diku.dk (Torben Ægidius Mogensen) writes:

> Xah Lee <xahlee@gmail.com> writes:
>
>
>> Functional Programing: stop using recursion, cons. Use map & vectors.
>>
>> 〈Guy Steele on Parallel Programing〉
>> http://xahlee.org/comp/Guy_Steele_parallel_computing.html
>
> This is more or less what Backus said in his Turing Award lecture about
> FP.

Stop inflating his ego!  Next he'll quote Nobel prize winners...

-- 
__Pascal Bourguignon__                     http://www.informatimago.com/
A bad day in () is better than a good day in {}.

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

#6080

On 23.5.2011 16:39, Pascal J. Bourguignon wrote:
> torbenm@diku.dk (Torben Ægidius Mogensen) writes:
>
>> Xah Lee<xahlee@gmail.com>  writes:
>>
>>
>>> Functional Programing: stop using recursion, cons. Use map&  vectors.
>>>
>>> 〈Guy Steele on Parallel Programing〉
>>> http://xahlee.org/comp/Guy_Steele_parallel_computing.html
>>
>> This is more or less what Backus said in his Turing Award lecture about
>> FP.
>
> Stop inflating his ego!  Next he'll quote Nobel prize winners...
>

Well said.... That inspired me to note:

LISP without recursion would be like a jet airplane without wings.... 
Recursion is an important part of the functional programming paradigm
(yes, I do know that LISP is not a purely functional language...)

LISP denotes, List Processing.  List Processing without cons ?????  Ugh.

regards, andy

[toc] | [prev] | [standalone]

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

csiph-web