Lisp refactoring puzzle

[Terry Reedy]

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
> situations.
>
> 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
> silly.


-- 
Terry Jan Reedy