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


Groups > comp.lang.python > #9374

Re: Lisp refactoring puzzle

From Teemu Likonen <tlikonen@iki.fi>
Newsgroups comp.lang.python
Subject Re: Lisp refactoring puzzle
Date 2011-07-13 11:29 +0300
Organization A noiseless patient Spider
Message-ID <87mxgilh15.fsf@mithlond.arda> (permalink)
References <19f8eb5b-cc90-472a-8399-4a5787b6fecf@glegroupsg2000goo.googlegroups.com> <c1749ae0-46ee-4ae6-a4e9-60eaebbc2a35@e18g2000vbx.googlegroups.com> <2c59f63a-b46f-4ea9-bc12-da4841687117@l28g2000yqc.googlegroups.com> <5cb297e4-6a39-461c-98c5-639e72e166af@p10g2000prf.googlegroups.com> <ivhtuo$dfd$1@dough.gmane.org>

Show all headers | View raw


* 2001-01-01T14:11:11-05:00 * Terry Reedy wrote:

> As a side note, the same principle of expressions matching operations
> in symmetry suggest that majority of up are quite sensible and not
> dumb idiots for preferring 'f(x)' to the '(f x)' of Lisp. In a
> function call, the function has a different role than the arguments,
> so it is appropriate that it have a different role in the expression.

Please don't forget that the whole point of Lisps' (f x) syntax is that
code is also Lisp data. It's not just a function call with arguments.
First, it's literal data (two linked cons cells and symbols) and then
the Lisp evaluating model makes it a function call in certain
situations.

Lisp is

    CL-USER> (let ((lisp (cons 'programmable nil)))
               (setf (rest lisp) lisp))
    #1=(PROGRAMMABLE . #1#)

programming language and it's totally irrelevant and pointless to say
"which syntax someone prefers" because this feature (code being data) is
very fundamental principle of the language. You know, it's easy to write
programs that write programs. If we remove this feature (i.e., don't
talk about Lisp at all) then it's perhaps relevant to discuss about such
choices in syntax.

You wouldn't want Python arrays have a read and print format "a[b, c]",
that is, the first item of the array printed outside []'s. It would be
silly.

Back to comp.lang.python | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

Re: Lisp refactoring puzzle Xah Lee <xahlee@gmail.com> - 2011-07-11 20:37 -0700
  Re: Lisp refactoring puzzle jvt <vincent.toups@gmail.com> - 2011-07-12 07:30 -0700
  Re: Lisp refactoring puzzle "WJ" <w_a_x_man@yahoo.com> - 2011-07-12 15:27 +0000
  Re: Lisp refactoring puzzle fortunatus <daniel.eliason@excite.com> - 2011-07-12 09:16 -0700
  Re: Lisp refactoring puzzle gene heskett <gheskett@wdtv.com> - 2011-07-12 14:23 -0400
  Re: Lisp refactoring puzzle Petter Gustad <newsmailcomp6@gustad.com> - 2011-07-12 21:02 +0200
    Re: Lisp refactoring puzzle Neil Cerutti <neilc@norwich.edu> - 2011-07-12 19:44 +0000
      Re: Lisp refactoring puzzle "Pascal J. Bourguignon" <pjb@informatimago.com> - 2011-07-13 00:51 +0200
      Re: Lisp refactoring puzzle William Clifford <wobh@yahoo.com> - 2011-07-13 17:53 -0700
    Re: Lisp refactoring puzzle "WJ" <w_a_x_man@yahoo.com> - 2011-07-12 19:52 +0000
  Re: Lisp refactoring puzzle Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2011-07-13 13:47 +1200
    Re: Lisp refactoring puzzle Roy Smith <roy@panix.com> - 2011-07-12 21:58 -0400
  Re: Lisp refactoring puzzle Terry Reedy <tjreedy@udel.edu> - 2011-07-13 00:39 -0400
    Re: Lisp refactoring puzzle rusi <rustompmody@gmail.com> - 2011-07-12 22:10 -0700
  Re: Lisp refactoring puzzle Teemu Likonen <tlikonen@iki.fi> - 2011-07-13 11:29 +0300
    Re: Lisp refactoring puzzle Terry Reedy <tjreedy@udel.edu> - 2011-07-13 10:34 -0400
      Re: Lisp refactoring puzzle Teemu Likonen <tlikonen@iki.fi> - 2011-07-13 18:25 +0300
    Re: Lisp refactoring puzzle Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2011-07-14 15:12 +1200

csiph-web