It's important because we have to distinguish between many dialects. If any of them are just Lisp, it starts to get confusing.
Despite what the CLers say, we all have an equal claim to the name.
Despite what the CLers say, we all have an equal claim to the name.
Agreed, but who cares? Is this what you want the Lisp community to spend our time on?
> It's important because we have to distinguish between many dialects. If any of them are just Lisp, it starts to get confusing.
I don't think it's important. I'm not confused, and if you understand what's going on enough to disagree with it, you aren't confused either.
More to the point, neither being confused about what dialect is being discussed nor arguing about semantics helps anyone, but at least confusion doesn't waste enormous amounts of time and energy, divide the community, and derail productive discussions.
Look at this thread. I'd like to talk about ORO memory management, which is pretty interesting, but instead we're talking about semantics. The top response is about terminology. Is this what you want?
Terminology issues consist of inter-language conflicts among definitions of technical terms like "list", "scope", "variable" or "macro" and such.
The proper noun that Lutz Mueller chooses to call his project is not a definition of a technical term.
To me, NewLisp is uninteresting. I already know how to avoid sharing issues in memory management in C programs by mallocing a copy of everything and duplicating it; that bores me. Lots of programs in POSIX environments do that with strings: strdup everything you receive, and cheerfully free it knowing that nobody else has that pointer. NewLisp is just doing "strdup for lists". It might as well work using strings, just like the "Lisp in sed" implementation: https://github.com/shinh/sedlisp . Why use objects, when pictures of objects provide a reasonable facsimile? I know how fexprs work, and they bore me also. Once you allow them, you can kiss goodbye the future prospect of having a compiler. As an implementor, if I want to introduce a new special operator in an interpreter (a decision not to take lightly), I can write it in the hosting language (such as C), and not as a fexpr. By writing such an operator, I get essentially the same development experience as if I wrote a fexpr, without inflicting harm on the language. If interpretation is a wart, then interpreted code being dispatched to interpret code is a tuft of hair growing out of wart.
And you have no evidence that that was Lutz's intent.
1. I see no reason to NewLisp was named to troll people. It only has the effect of trolling you because you have created a subset of the English language in your head which you view as "correct" without any basis in reality.
2. In the English language, "terminology" can be applied to the names of programming languages and people will know what you're talking about. It can also be applied to things like "list", "scope", etc.; generally people use context clues to figure out what you're talking about.
> To me, NewLisp is uninteresting. I already know how to avoid sharing issues in memory management in C programs by mallocing a copy of everything and duplicating it; that bores me.
Thank you for sharing. I'm sure you're very knowledgeable and smart and whatnot, have a cookie. Now can we who are interested and curious about this have a conversation without you butting in, please?
I'd like to know:
What are the performance implications of doing ORO universally? The tradeoff seems to be that copying takes time, but it also allows you to treat everything as stack-allocated, so it saves time on heap management. What's the average case performance like? In what cases is this a good tradeoff? In which cases is this a bad tradeoff?
Not as helpful as I'd like, but hope it helps nonetheless.
Judging by the root post, it appears I started this thread on the subject of the trollish behavior of the NewLisp project. You can collapse it and use another one.
> I see no reason to NewLisp was named to troll people.
I have visited the NewLisp website a couple of times in the last 15 years or so and found trollish content. Example:
https://web.archive.org/web/20041010181233/http://newlisp.or...
Quote: "Don't read books about LISP, if you want to learn newLISP, most deal with Common LISP or Scheme, two different older standards of LISP. These books teach you many concepts unnecessary to learn newLISP, which does some things in a very different way than the older standards. Try to understand newLISP on it's own terms."
There you go!
* Don't read books about Lisp.
* Lisp and Scheme are older standards (NewLisp is the new standard, hence the "New").
Newer version of last sentence:
https://web.archive.org/web/20080726054533/http://www.newlis...
"newLISP does things much differently from the older standards, in ways that are more applicable to today's programming tasks."
Thus, pre-existing Lisps are not applicable to today's programming very well; here is a new standard to fix it. We're bringing back dynamic-scope-only and frexps because today's programming once again requires a Lisp from 1960.
"More applicable" isn't trollish enough, so the webmaster added the text "and on a higher level closer to the problem at hand" sometime by 2012, which stands today. (The "old standards" are low-level languages, incapable of the same level of abstraction offered by NewLisp). At least the "don't read books" remark was removed, though.
I'd like to see talk about ORO memory managment which is not of the following form: "NewLisp isn't really Lisp because of its <expletive deleted> ORO memory management; you cannot replace real Lisp with that kind of cruft ..."
That is why I have tried to articulate what I suspect it is that actually bugs Lisp people about NewLisp. It's not the fexprs or the lists working differently and so on; trying to frame it technically is misguided.
If you have some problem with the trolling behavior of a project, but you try to frame it in technical terms, that's a waste of time.
My usual responses to each of these, respectively, are: come off it, even McCarthy says that was totally by chance, and may not have been the best idea; pretty much every implementation has really macros, and even the original lisp didn't have real macros; and finally, come on, Rainer, we've had this discussion like three times already.
Only actual Lisp dialects have a claim to the name.
That's why Scheme is called Scheme and not Lexical Lisp. That's why Logo is called Logo and not Simple Lisp. That's why Javascript is called Javascript and not WebScheme. That's why Racket is called Racket, and not NewScheme.
See for example Pitman, Lambda the ultimate political party
http://www.nhplace.com/kent/PS/Lambda.html
Published in Lisp Pointers (a regular Lisp magazine, published in the 80s/90s) in 1994.
> Lisp users are accustomed to being able to write programs that take program texts in different dialects (or older versions of the same dialect) and process them to bring them up to date. No single common linguistic feature supports this. And yet, Lisp users are accustomed to expecting that there will be some way to accommodate the needs of compatibility and translation.
That's is what makes Lisp, in my opinion. Sharing of code, implementations, libraries, books, tools, ...
A language spectrum serves a diverse community. It is not a dead body of abstract and vague principles. It grows out of sharing and communication.
Kent knows the Lisp and Scheme landscape very well. He worked as developer, in standardisation efforts (both Lisp and Scheme), as an implementor, editor, author, etc.
A language spectrum does indeed serve as a diverse commiunity. One us Schemers are a part of.
I know my history, I just disagree with you.
> Many of the same people were involved in the standardization effort, and the creation of both.
I doubt that this is the case for R7RS.
> The thing is, the Scheme community may not be able to share code directly, but we are able to, and often do, share ideas.
That's my point. There are few ideas shared and no code. Today the various spinoffs of Lisp have their own communities. I don't say that it is bad or good, it's just the way it is. That's not only the fate of a programming language family, it also happens in other areas, that domains are divided into groups which have problems to understand each other and which are not able to track or use the work of other groups. The groups have different preferences and their topic gets an independent life.
As for r7rs, Sussman, at the very least, was on the commitee. Several other Lispers as well, IIRC, but it would take too long to check.
All the Lisps have different communities. That's why the languages are different. There's some overlap, but if the communities were identical than all the languages would be the same.
But then, you could say the same of C, C++, and Java, which don't all share code, but are all in the same family.
Steele was on the commitee for many years, although not this one.
I'd give you a list of CLers on the commitee, but I honestly can't dig through 12 people's online profiles just to prove a point right now.
Now complaints about calling Racket Scheme, OTOH, I get. Scheme has a specification which Racket doesn't comply to: they changed the name for a reason when they started to deviate. Calling Racket Scheme is like seeing a language that's kind of similar to C and just calling it C.
Sorry, I don't have that argument.
Frankly, I don't give a fuck about anyone's "claim". If people can use a word to move an idea accurately from their brain to other people's brains, communication has occurred and I'm happy.
If I say "NewLisp" and my audience knows what interpreter I'm talking about, I have succeeded in my goal.