Orange site is funny, on the topic of the Ideal #Lisp:
"> It would be something like a fusion of Clojure and Common Lisp, (...)
Mine would be, too. Unfortunately, that's not possible. Clojure is one of those few languages actually designed by somebody who knows what they are doing."
So .. the Lisp Machine folks, the Common Lisp people, Maclisp .. etc had no clue what they where doing.
Oh yeah .. Clojure isn't a Lisp, now bite me.
@hayley You wish us folk could get VC cash and burn it for whatever shenanigans we might come up with… the world would be si much colorful!
@counteractor @hayley No. Please no!
@amszmidt Since it is not en vogue anymore to search for the Holy Grail, Ideal Lisp must suffice as a replacement.
@amszmidt
I thought Common Lisp accreted
Uh, ... I get that the context is light-hearted. And I'm sure you know there's no actual test for what is or is not a lisp. As a matter of maybe mostly accident, I think the cons operator is present in nearly all dialects, but I don't think there are many commonalities. Probably someone calls cons pair or make-pair or some such. So excluding clojure will be hard...
But the most interesting part of probably -unsupportable statements like you made (even if in response to other probably-unsupportable statements) is the justification. It's just that you've offered none.
What makes clojure seem unlispy?
@kentpitman
I think that's kinda the point, what would it mean to be or not to be lisp, and @amszmidt is suggesting that rather than something nearly universal - conses, or the use of ~unsyntaxful sequences as logical elements of code (where did I see this definition of lisp) being a lisp could be understood as engagement in the varied previous lisp culture
Loop in clojure seems to be #'DO : https://clojuredocs.org/clojure.core/loop
Rather than being interlisp's FOR or the progression to CL's LOOP facility *err
@kentpitman @amszmidt
*actually maybe not similar to do either.
Actually i think CL's LOOP comes from Alan Bawden and Glenn Burke.
Edit: hmm. Maybe also Moon.
@kentpitman
In this Burke and Moon article you produced, they emphasise
CLISP's (conversational lisp's) FOR led to the related but incompatible development of ~zetalisp's LOOP (an interesting interpretation of the use of keyword arguments to create a "stylized english" facility).
And this emphasis on heritage from previous lisps would be one way of defining how lispy something is.
( @amszmidt 's original thread in this vane was "scheme is not a lisp, bite me" - scheme was kind of a breakaway)
@kentpitman As you say, it is light-heated, and defining what is or isn't a Lisp is really a yak shaving exercise. Nothing makes Clojure Un-Lispy, I think. I don't think it is very Lisp-y either, but that becomes a philosophical and personal discussion with no end. At the end ... it does not matter, I just get slightly annoyed when everything and anything becomes "A Lisp", when nobody goes around calling Javascript a C, despite syntax similarities, or semantics, or what have you.
@kentpitman It is a similar thing people like to harp about that DO or FOR are not "Lisp-y" -- despite Lisp having DO for ever. Or that mutation is unLispy.
FWIW, Strange to see #'FOR or #'DO -- they are not functions!
@amszmidt
oh, bizarre. It seems like sbcl fills #'loop and #'do and so forth with #<CLOSURE (:MACRO LOOP) {}> whereas ECL for example complains there's no such function.
@kentpitman
* #'do
debugger invoked on a UNDEFINED-FUNCTION in thread
#<THREAD "main thread" RUNNING {7008A20B03}>:
COMMON-LISP:DO is a macro, not a function.
I'd been quietly squirming at references to #'<macroname>. Macros exist in the function namespace but generally aren't functions and my vague recollection is we left it undefined whether their definition lives in that cell or not. It isn't meaningful to access it. Funcalling such objects, if it works at all, does not work portably.
mia culpa -_-
@screwtape @kentpitman Mea culpa if I may ...
@amszmidt
you know, it's after midnight where I am.
@kentpitman
@screwtape @kentpitman It is always after or before midnight -- possible a bit more or less in different places on this ball of mud and water. ;-)
@screwtape you've been ill; have a snack, brush your teeth and get to bed
@rat yeah, but after reading jns' epic phlog today (gopher.linkerror.com) I wanted to implement "rotated" fancy justification and it seems so close to succeeding
Hmmm. It's after midnight everywhere. Just a question of by how much. :)
But it's almost 5am here in Arizona. So this time I'll really try to sleep. So much to do with today's daylight, which fast approaches.
@kentpitman @screwtape Not even 1300 here, sunset in about 2 hours.
But there's a deeper point here. A lisp2, like CL, is designed around the idea that there are names that have more than one meaning which is resolved by context. When referring to DO or FOR, in a form, they would occur in the car of the form, so programmaticaly that would be be unambiguous. One doesn't write (#'LOOP ...) because (LOOP ...) is enough.
When referring to them in sentences, they are unlikely variable names, so I understand your urge to put the sharp quote in front of them, but technically the whole point of having names resolved by context is that you spend a lot less time worrying about the fact that they have multiple meanings and you just refer to them in the natural way, by name, just as no one talks about the noun apple fearing there might be a verb apple. They just talk about apples. Once in a while you must create disambiguation, but it's not that often.
Lisp1 fans seem to me to think the sky will fall in if context gets involved, but no human language doesn't routinely attach multiple meanings to nearly all words. We humans are nothing if not context resolvers. So, might as well use that brain wetware. Some say simplicity is about minimalism. I say, and at least some contexts, simplicity is about isomorphism to human brain function. Lisp1 fights/ignores how we think, and how we design human language. It's a thing you can do, but I challenge the right to claim that always makes things simpler. Simplicity is more complex than that. :)
I advocate designing languages that are not most minimal but most suited to human reasoning. And that extends to promoting conversations that are non nerdy, not adding spoken words you don't need. So, yes, CL is case sensitive, but it is also case translating, so in the common situation we do not call out case either, only when needed. We don't say "all-uppercase CAR" (or all-uppercase DO) because no one makes a competing one. The notations are there in case we need them, but I advocate normally just speaking to other humans in the simple way about CAR and DO because ... why not? We have brains. We figure it out.
That we want people to talk about language is why the spec contains pronunciation guides, by the way. Not to force anything, but to understand that there are norms, so people learning in isolation can feel included and not be embarrassed later.
But the interesting thing is not whether X is a Lisp but why anyone thinks it is or isn't. Think of the "ball of mud" metaphor for Lisp as a kind of Rorschach test. What do people see and value? That we all see and value different things is almost a given. It is what it is. But we learn through discussion new ways to see things and new things about our compatriots in community, what makes them efficient or inspired or puzzled or content.
@kentpitman I wouldn't even say that it is interesting to think why something is a Lisp or not since for that you need to define somewhat what Lisp is.
Rather, what can you create with a ball of mud ... the mud matters somewhat, but you can generally make a cup of anything.
I propose the "toe stub" test:
When trying to write code in a functional style, how often do you stub a toe on a given language?
So in a way, it is "how far is the current language away from my favorite lisp and how annoying does it feel to get anything done".
@hayley @kentpitman Objective-C? C++?
@hayley @kentpitman I would, without blinking .. Objective-C is even backward compatible with "standard" C(some version).