Lisp refactoring puzzle
tjreedy at udel.edu
Wed Jul 13 16:34:41 CEST 2011
On 7/13/2011 4:29 AM, Teemu Likonen wrote:
> * 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.
Thank you for clarifying that. Some Lispers appear to promote the
'simple, uniform syntax' as a end in itself (making code=data a side
effect) rather than as a means to accomplish a deeper end.
> 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
> Lisp is
> CL-USER> (let ((lisp (cons 'programmable nil)))
> (setf (rest lisp) lisp))
This much looks like Lisp
> #1=(PROGRAMMABLE . #1#)
This must be some of the new-fangled Common LIsp stuff I never learned ;=).
> 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
Terry Jan Reedy
More information about the Python-list