Common Lisp isn't a functional programming language to be clear.
It definitely isn't one, when instead of looking at it with the eyes of CS knowledge, people take the mindset whatever Haskell does.
FP predates Haskell by decades.
It also isn't one when "looking at it with the eyes of CS knowledge", given that Common Lisp has very powerful support for OO and procedural programming out of the box, and in order to most effectively use an FP style it's necessary to rely on community developed libraries...
What FP style? Haskell style, I guess.
When I learnt Lisp, Lisp and Scheme were FP, Miranda was still around, and Caml Light had just started being known outside INRIA.
I really dislike revisionism regarding what it means to be FP.
The issue's that Schemes (and Clojure) are way more functional than Common Lisp and e.g. `funcall` feels like a kludge compared to lisp-1. If you read the old CL codebases or modern code, destructive and imperative use are common, so it doesn't feel terribly revisionist (just compared to pascal, c, bliss etc.).
Having the data structures is nice and all, but using them is kind of painful. They are certainly second class.
Having to use accessor functions or destructuring macros instead of just a period or -> is often annoying too. The lack of syntax has cons as well as pros.
Everything needed is place, there is no second class about using arrays instead of lists.
I mean you can write a macro that let's you write
(object -> slot)
and transforms it to (slot object)
"->" should be unused
Writing a reader macro that allows for something like...
[some-numbers 0]
(object -> slot)
> so we can forgive CL for this
The 1962 dated Lisp 1.5 Programmer's Manual already describes a 0 based array feature. Lisp was clearly one of the historic instigators of zero based array, rather than just playing along.
Yes, but the various Lisps that Common Lisp is the more-or-less common subset of are (were?) all 0-indexed. Between easy heap implementation (left is (ash index 1), right is (1+ (ash index 1)), parent is (ash index -1)) and easy last element selection (nth seq (length seq)) I prefer 1-indexing, but I realize that's an unpopular opinion.
A late reply but it's worth addressing one way of doing this. First, your concern about object not being a valid function or macro isn't relevant at read time. Second, note that Lisp already has similar syntax: '(1 . 2) is essentially (cons 1 2). Implementing this type of syntax is not a privilege of the implementation alone. You're allowed to redefine your own reader for left paren. In SBCL:
CL-USER> (get-macro-character #\()
SB-IMPL::READ-LIST
(when (and (eq firstchar #\-)
(eq (peek-char t stream t nil t) #\>))
(read-char stream t) ; actually read the nextchar > to discard it
(let ((next-obj (read stream)))
(sb-impl::flush-whitespace stream rt)
(return `(slot-value ,@listtail ',next-obj))))
CL-USER> (defclass vec2 ()
((x :initarg :x)
(y :initarg :y)))
#<STANDARD-CLASS COMMON-LISP-USER::VEC2>
CL-USER> (defparameter vec (make-instance 'vec2 :x 3 :y 4))
VEC
CL-USER> (vec -> y)
4
CL-USER> (read-from-string "(print (vec -> x))")
(PRINT (SLOT-VALUE VEC 'X))
18
Good things are worth waiting for. I never considered making a reader macro for a regular opening bracket, that's equal parts genius and insanity.
And also make sure that slot is a symbol in the correct package. Or do like Elisp and do without packages but then have a 16 character prefix
Another thing all modern Lisps have since the 1980's, is all major data structures, not only lists as many think when discussing Lisp.